两天烧掉95% AI编程额度：日志揭示token真相

一位开发者每天使用 Claude Code 构建 SaaS 产品，某周还没到周三，用量表就已冲到 95%。他本以为写下了海量代码，结果并非如此。

由于每个请求都在本地留有日志，他把三天的数据汇总起来，看到了这样的数字：

• 65,000 次请求
• 126 亿 token 被处理
• 1,400 万 token 是实际输出

也就是说，99.9% 的 token 根本不是代码。它们全都花在了模型反复阅读它已经知道的内容上。

真正的成本是上下文，不是代码

数据显示，97.6% 的 token 都是缓存读取。每一轮对话，智能体都会把此前的完整对话重新发送一遍：读过的文件、工具返回的结果、早先做出的决策——统统再读一次。

当上下文已经累积到 20 万 token 时，哪怕只回复一行字，也要付出 20 万 token 的读取代价。

更惊人的是分布：三分之二的 token 量来自那些上下文超过 20 万 token 的请求，而低于 5 万 token 的请求只贡献了 2.5%。

一个长会话成本高，不是因为它做了更多事，而是因为每一轮新对话都比上一轮更贵。

什么是缓存读取（cache read）？ 在 Anthropic 的 API 计费体系中，提示词缓存（prompt caching）允许开发者把一段稳定的前缀（如系统提示、历史对话、已读文件）标记为缓存内容。之后如果再次发送相同前缀，服务端不需要重新计算其注意力，而是直接复用缓存中的键值（KV），这部分 token 就记为「缓存读取」。它的单价通常只有全新输入 token 的约十分之一，因此账单上看似便宜，但计入限额时往往按等价权重折算，这就是为什么 97.6% 的缓存读取仍能迅速吃光配额。换句话说，缓存降低的是费用，而不是上下文规模本身；模型每轮依旧要「感知」那 20 万 token，只是感知得更便宜。理解这一点，才能明白「省钱」和「省额度」是两回事。

子智能体是倍增器

这位开发者的工作流把任务拆得很细。每个任务由一个子智能体实现，两个子智能体审查——一个检查是否符合规格，另一个把关代码质量。这样确实能产出干净的结果。

但它也贡献了 78% 的请求量和 53% 的 token 消耗。

每个子智能体启动时都带着全新但依然庞大的上下文，执行大量工具调用，而每一次调用都会重新读取那份上下文。一个任务就这样变成了几十个请求。

子智能体（subagent）与上下文隔离 子智能体是主智能体派生出的独立执行单元，它有自己的对话历史和上下文窗口。设计初衷是隔离任务、避免主会话被中间结果污染，但代价是：每个子智能体启动时并不能共享主会话已经建立的缓存，它需要重新读取自己那份上下文。当主智能体把任务连同相关文件、规格一并交给子智能体时，这份「起始上下文」本身就可能很大，而子智能体内部的每一次工具调用又都会重新发送它。于是扇出（fan-out）越大，重复读取的总量呈乘法级增长：一个任务拆成 N 个子智能体，就可能意味着 N 份庞大的上下文被反复读取。这也是为什么减少并行子智能体、只保留一轮审查，往往能直接砍掉可观用量。

五个会话吃掉了全周 75% 的量

在总共 46 个会话中，有五个会话占去了四分之三的总用量。它们是持续数小时的长跑，上下文不断膨胀，而开发者从未重启。其中一个会话平均每次请求的上下文接近 40 万 token。

模型层面的分布同样值得注意：

模型	token 占比
Sonnet	82%
Opus	14%
Fable（高级档）	3.6%，几乎集中在一天内

上下文窗口与「长会话税」 主流模型的上下文窗口在 20 万到 100 万 token 之间，窗口越大，看起来越能装。但真正的成本曲线不是线性的：第 1 轮请求只发送 1 份内容，第 10 轮要发送前面 9 轮的全部累积，第 100 轮则要发送 99 轮的累积。如果每轮新增量大致恒定，那么总消耗随轮数呈平方级增长。这就是「长会话税」——会话跑得越久，单次请求越贵，而其中绝大部分内容模型早已处理过。主动在 15 万 token 前后压缩或重置会话，本质上是在平方曲线还平缓的时候切断它。把长任务拆成若干独立会话，每次从干净且精简的上下文出发，比一路续聊到 40 万 token 要省得多。

正在做出的改变

针对日志暴露的问题，这位开发者列出了五项调整：

1. 按任务块划分会话：在上下文到达 15 万 token 之前就主动清理或压缩。
2. 减少并行子智能体：常规工作只做一轮审查，而不是两轮。
3. 常规子智能体换用更小的模型，比如审查和探索类任务。
4. 高级模型只用于规划和困难决策。
5. 写一个本地小脚本，每天早上汇总日志，在用量表报警之前先看到曲线。

关于数字的一点说明

这些是原始 token 计数。缓存读取的计费和限额方式与全新 token 不同，所以这组数据解释的是用量规模，而不是用量表上显示的确切百分比。真正有意义的是背后的模式。

核心结论

如果你的 AI 编程额度消失得比产出快得多，先看看上下文大小和子智能体的扇出规模，再怪模型不迟。

Token 不是花在答案上，而是花在记住问题上。

你平时怎么追踪智能体的用量？是会主动重置会话，还是等到出问题才不得不重启？