Coding Agent 不要钱，模型要钱：Claude Code 的成本会计学
很久之前我分析过一次 Claude Code，没有发出来。这次把它升到 2.1.273，我在 VS Code 源码仓里跑了一个只读的分析任务，用 llm-interceptor 抓下了全程 120 对请求/响应。这篇文章不讲工具列表——那些跟着发布节奏看 changelog 就都知道了。我想回答一个别的问题：
coding agent 本身不要钱，模型要钱。那 Claude Code 这个 harness，到底花了多少力气在替用户省钱上？
先交代实验
一条命令：
1
2
3
lli run --label vscode-agent-window \
-- claude -p "分析本仓库中 agent sessions 功能的实现..." \
--allowedTools "Read,Glob,Grep"
375 秒，120 对请求/响应，任务本身只是「读代码然后总结」。我的 Claude Code 配了智谱的 Anthropic 兼容端点，请求体里的 model 是 glm-5.2——这不影响分析，因为提示词、工具定义、循环逻辑全是 CLI 侧注入的，跟哪家模型无关。这恰好也证明了本文要说的第一件事：coding agent 和模型是解耦的，agent 的好坏全在那个 prompt 里。
你说了一句话，它替你垫了两万 token
这个任务我的指令是 85 个 token。而 Claude Code 每一轮请求固定垫进去的是：
| 注入内容 | 约多少 token |
|---|---|
| 系统提示词（分两层） | 2,075 |
| 23 个工具的名称+描述 | 18,487 |
| system-reminder 环境快照 | 330 |
85 对 20,892，约 246 倍。 你还没开始干活，账上已经跑了两万 token 的固定开销。
工具定义是大头。23 个工具的平均描述长度接近两千字符——不是列表，是使用说明书：什么时候该用、什么时候不该用、和哪个工具冲突。这些描述本质上是 Anthropic 替模型写的行为守则，而用户为它们的每一次调用买单。
读文件之前，先数钱
120 轮里有 9 个请求很特别：打往 /v1/messages/count_tokens，单条消息塞一整个源文件，零工具调用。
这是 Claude Code 在读大文件前先问模型方：这一份要多少 token？然后才决定怎么读——整读、分段、还是摘要。没有任何一个请求是先读了再说的。
我把它叫做「先算账，再干活」。这个行为在 UI 里完全不可见，你只会看到进度条转了一圈。但它揭示了 harness 的一个基本姿态：上下文不是容量，是余额。 每一次读取都是消费，harness 有义务在消费前报价。
15 倍：缓存才是真正的地基
整个会话累计：真实 input 45.5 万 token，cache read 690 万，15.2 倍。请求体里出现了 333 处 cache_control。
agent 循环的形状决定了这个数字的宿命：每一轮都要重发全部历史。120 轮对话没有缓存的话，input 就是 690 万 token 按原价计费。有了缓存，那 690 万里绝大部分按 cache 价（通常是原价的 1/10）结算，真正原价支付的只有 45.5 万。
现在回看那两万 token 的固定垫资：正因为有缓存，这笔钱每一轮的实际成本趋近于零，Anthropic 才敢把系统提示词和工具描述写得这么长。缓存不是优化，是许可证——它许可了「大提示词常驻」这种在无缓存世界里自杀的设计。
count_tokens 和 cache_control 是同一个学科的两门课：前者管花之前记账，后者管重复花销打折。我把这套东西称为 harness 的成本会计学。
剩下的力气花在哪
会计学之外，本次抓包里值得记录的 harness 行为还有两处。
子 agent 是钱包隔离。 任务触发了 4 个并行 Explore agent，各自带裁剪过的 11 工具集、独立的只读铁律提示词，干完只把报告传回主对话。探索的绝大部分 token 开销发生在子 agent 的账本上，主对话只收结论。隔离同时服务两个目的：上下文清洁，和计费边界。
上下文管理在向运行时自适应演化。 提示词尾部挂着 <total_tokens>15000000 tokens left</total_tokens>——模型自己知道预算还剩多少。请求体里 thinking: adaptive、context_management 自动清除历史 thinking 块。上一代是「满了就 compact」的静态策略，这一代是模型参与记账。
这套方法，你可以自己跑
写这篇文章的真正目的：评估任何 coding agent，不需要信官方博客，抓一次包就够了。要看的是四个指标：
- 固定垫资比：第一条请求里（system + 工具定义）÷ 你的指令。这个数是 agent 替模型做的所有预设判断的总和
- 缓存比：cache read ÷ 真实 input。越高说明 harness 越在意你的账单
- 消费前报价：有没有 count_tokens 类行为，还是闷头读了再说
- 隔离度：子任务是在主账本上跑，还是被隔离到子账本
agent 本身没有好坏，它和模型交互的 prompt 长什么样，它就是什么样。下次你为一个 coding agent 付模型账单的时候，先抓个包，看看它的 harness 在会计上给你做了什么。