聚合站 key 上的 Claude Code hooks 与子代理：哪类调用落到哪个后端

先理解 Claude Code 的调用链分层

Claude Code 的运行可以粗略分成三层：主对话循环、工具调用（含 hook 触发的动作）、以及子代理（subagent）派生出的独立会话。对聚合站来说，每一层最终都会变成一次或多次 HTTP 请求打到 /v1/messages 这类端点，区别在于请求头、模型名、上下文大小和调用时机各不相同。

把“哪个阶段产生请求”和“请求被路由到哪个后端”分开看，是排查账单与延迟问题的关键。

一次请求里决定路由的几样东西

聚合站通常按下面的信息决定把请求转发给哪个上游：

• 模型名（model 字段）：最直接的依据。请求里写 claude- 就落到 Anthropic 系后端，写 gpt- 就落到 OpenAI 系，写 deepseek-、qwen-、glm-、kimi- 同理。
• API key：同一个 key 可以调多个模型，所以 key 本身通常只做身份与额度校验，不绑定单一后端。
• 请求特征：如是否带工具定义、是否流式、上下文长度等，可能影响上游选择或降级策略（具体策略以站点文档为准）。

因此“哪类调用落到哪个后端”这个问题，答案基本由这次调用用的模型名决定，而不是由它是不是 hook 触发来决定。

hook 触发的调用：本质是一次普通的模型请求

Claude Code 的 hook 常见用途是格式化代码、跑测试、做前处理、注入额外上下文。这里要区分两种情况：

• 纯本地 hook：只执行 shell 命令，不产生任何 API 请求，聚合站完全看不到，自然也不计费。
• 需要模型参与的 hook：例如让模型生成提交信息、审查改动、补充说明。这类 hook 会额外发起一次（或多次）模型请求，请求所用的模型由 hook 配置或其调用的命令决定。

关键点：hook 不会自带一个“特殊后端”。它产生的请求和你手敲一条命令发起的请求走同一条路由逻辑，模型名写什么就落到哪里。如果你在 hook 里调用了某个小模型做格式化检查，那这笔消耗就记在那个小模型对应的后端上，而不是主对话的 Claude 后端。

排查方法很朴素：看 hook 脚本里实际拼的请求体，重点看 model 字段。

子代理调用：独立会话，独立模型

子代理（subagent）在 Claude Code 里表现为派生出一个独立的会话上下文，用来并行探索代码库、跑长任务或隔离上下文。它有几个特征值得注意：

• 上下文是独立的：子代理不会复用主对话的完整历史，因此 prompt token 往往重新计算，不能简单按主对话的消耗去估算。
• 模型可以不同：子代理通常可单独配置模型。很多团队会让子代理用更便宜或更快的模型，主对话继续用能力更强的模型。这时子代理的请求就落到子代理指定的那个后端上。
• 调用可能成倍：一个任务派生多个子代理，就是多路并发请求，聚合站的用量和并发都会相应上升。

所以在聚合站的后台里，你会看到主对话和子代理各自成条目，按模型分别统计。把它们混在一起看总量，容易误判是主模型变慢或变贵。

计费归属：按请求的模型算，不按“阶段”算

聚合站的计费逻辑很直接：每一次成功请求按它实际使用的模型进行计价，用户侧按官方价 ×1.3 扣费；贡献 key 的一方按官方价 ×1.1（优质 ×1.2）返 USDC。这里不存在“hook 价”或“子代理价”这种按调用来源区分的档位。

由此可以推出两条实用结论：

• 想降成本，动的应该是模型选择（例如让 hook 和子代理用便宜模型），而不是减少 hook 数量本身。
• 对账时应该按模型拆分用量，而不是按“主对话 / hook / 子代理”这种来源拆分。来源只用于理解行为，不用于解释金额。

一个可落地的排查流程

当发现账单或延迟异常时，可以按下面顺序过一遍：

1. 在聚合站后台按模型拉一段时间的用量，看增长集中在哪个模型上。
2. 对照 Claude Code 的配置，确认主对话、子代理、hook 各自指定的模型名。
3. 检查 hook 脚本是否在每次工具调用时都触发一次模型请求——高频触发是常见的隐性用量来源。
4. 检查子代理是否被大量并行派生，尤其是探索类任务。
5. 对确认不必要的模型调用，改用本地命令或更小的模型。

路由的稳定性与降级

聚合站做多上游聚合时，通常会有一层路由与重试逻辑。你需要知道的是：

• 同一个模型名在不同时段可能由不同上游实例承接，这对调用方透明，但会影响延迟表现。
• 失败重试如果发生在上游侧，理论上不应重复计费给你；但如果是客户端自己重试，就会真实产生多次调用。写 hook 和子代理的调用代码时，重试策略要收敛。

这些细节以站点的实际行为为准，建议在正式依赖前用小额调用实测一轮。

小结

把 Claude Code 的调用对应到聚合站后端，只需要记住一条主线：看模型名，不看调用来源。hook 和子代理只是产生请求的两种方式，它们各自指定什么模型，就落到什么后端、按该模型计价。理解这一点，用量拆分、成本控制和故障排查都会清晰很多。