聚合站上 Claude Code 烧 USDC 太快：排查是哪个后端、哪段提示词在作祟

先确认计费口径，别把单价当成根因

聚合站的计费逻辑通常是：按所调用模型的官方价乘以一个固定系数扣费。也就是说，同样的 token 量，用不同后端扣掉的 USDC 并不相同。感觉“烧得太快”时，先分清是单价差异还是用量失控。

排查前先确认三件事：

• 你的 key 调用的是哪些模型，是否存在默认模型被悄悄替换的情况。
• 扣费是按输入、输出分别计价，还是合并计算；缓存命中是否有单独口径。
• 近期是否改过 Claude Code 的配置、系统提示词或工具定义。

把这些作为基线，后面的归因才有意义。

第一步：拉取用量日志，按后端归因 token

聚合站一般会提供用量查询接口或控制台日志。目标是得到一张按“模型 / 时间 / token 数”聚合的表。

建议按以下维度拆：

• 按模型：分别统计每个后端的输入 token 与输出 token。先看哪个模型占了绝大部分消耗，而不是只看总额。
• 按时间：按小时或按天聚合，找出消耗陡增的时间段。
• 按 key / 会话：如果日志带请求 ID 或会话标识，把高消耗时段对应到具体会话。

一个常见现象是：你以为主要在用一个模型，日志里却是另一个后端在持续吃 token。Claude Code 这类工具会多次调用模型，配置里的模型名一旦写错或用了别名，实际路由到的后端可能和你以为的不同。

第二步：判断是“调用次数多”还是“单次 token 大”

同样是高消耗，原因分两类，处理方式完全不同：

• 调用次数多：单次 token 不大，但请求数很高。常见于工具调用循环、自动重试、agent 反复读文件。
• 单次 token 大：请求数正常，但每次输入都很长。常见于系统提示词过长、把大段文件或日志塞进上下文、对话历史没有裁剪。

用日志里的“请求数”和“平均每次 token”两个指标就能区分。平均输入 token 明显偏高，问题在提示词和上下文；请求数明显偏高，问题在调用逻辑。

第三步：定位失控的提示词

确认是单次 token 过大后，逐层检查进入上下文的内容：

• 系统提示词与工具定义：工具描述、schema、示例是否被反复塞入每次请求。工具越多，固定开销越大。
• 上下文注入：是否把整个目录、整份日志或大段文档直接拼进提示词。
• 对话历史：多轮对话是否无限累积，没有做摘要或截断。
• 输出长度：是否要求模型输出大段代码或长文，导致输出 token 偏高。

排查方法很直接：取一次高消耗请求的输入内容，看哪些部分是每次都会重复出现的固定文本，哪些是可变内容。固定部分越厚，单位请求的成本就越高。

第四步：定位失控的调用循环

如果请求数偏高，重点看 Claude Code 的 agent 行为：

• 工具调用是否陷入“读文件—失败—重试”的循环。
• 是否有自动重试配置，在报错时反复请求同一后端。
• 是否并行发起了大量子任务，每个子任务都独立计费。
• 是否在长任务里持续轮询，而不是一次性完成。

这类问题在日志里表现为同一会话内请求密集、输入内容高度相似。找到重复模式后，通常通过限制重试次数、收敛工具权限、拆小任务来解决。

第五步：在下一次充值前做收敛

定位到根因后，按优先级处理：

1. 固定开销瘦身：精简系统提示词和工具定义，去掉不用的工具。
2. 上下文管理：对大文件做检索式读取，对话历史做摘要，避免全量拼接。
3. 模型路由：确认每个任务实际调用的后端，简单任务不必用高单价模型。
4. 调用约束：设置重试上限、并发上限，避免循环放大。
5. 持续观察：保留按模型聚合的用量视图，充值后对比前后消耗曲线，验证收敛是否生效。

需要提醒的是，聚合站的系数决定了你相对官方价的固定溢价，这部分不会因为优化而消失；优化能改变的是 token 总量和模型选择。把这两件事分开看，排查才不会跑偏。

小结

消耗过快通常是三件事叠加：后端选错、提示词过厚、调用循环。按“确认计费口径 → 按后端归因 → 区分次数与单次大小 → 定位提示词或循环 → 收敛验证”的顺序走一遍，大多数失控点都能在下一次充值前被找出来。