拆解 Claude Code 真实任务：Token 究竟消耗在了哪里

使用 AI 编程工具时，开发者往往先关注模型单价，却容易忽略任务执行过程中不断增长的上下文和反复发生的模型调用。一次包含代码修改、测试与修复的 Claude Code 会话，正好提供了可观察的样本：Token 如何累积、缓存何时发挥作用，以及子 Agent 怎样改变整体消耗结构。

上一篇我提了个问题：

AI Coding 到底贵在哪里？

这次我没先去查模型价格，而是翻了一次自己真实的 Claude Code session，想看看 Token 究竟花在了哪。

这个 session 当时用的是 DeepSeek V4 Pro / Flash，通过 Anthropic API 兼容接口接入 Claude Code。

我想把一次真实的 Coding Agent 任务拆开看看：

一个任务从开始到结束，到底发生了多少次模型调用？Context 怎么变大的？Cache 又起了什么作用？

---

先看几个数字

这次任务是一次真实的代码重构，过程中包含代码修改、测试、修复和多轮验证。

整个 session 跑下来：

• 54 个真实 user turn
• 主 Agent：373 次模型调用
• 7 个 subagent：116 次模型调用
• 主 Agent：508 次 Tool Call
• subagent：235 次 Tool Call

合起来就是：

489 次 Model Call，743 次 Tool Call。

用户可能只是不断提出任务，但 Agent 背后实际上一直在：

理解 → 查代码 → 调工具 → 看结果 → 再判断 → 修改 → 测试 → 再判断……

---

Context 到底有多大？

我先看 Context。

我用：

input + cache_read + cache_creation

自己拼了一个 Context signal。

这个指标不是 Claude Code 官方定义的 Context 大小，也不是字段。

我只是想知道：

随着任务不断推进，模型每次需要处理的历史信息，大概膨胀到了什么程度？

任务刚开始的时候，这个指标大概是：

33.8K

然后一路增长，最高到了：

595,985。

工具结果、命令输出、模型回复、历史文件内容，一层层叠进去。

到任务后半段，已经接近 60 万。

这让我重新理解了一次模型调用。

我以前容易把“一次模型调用”理解成一次独立计算。

但 Coding Agent 不是这么工作的。

Agent 下一次调用模型时，并不是只把“新的问题”发过去。

它还需要带上前面任务过程中积累下来的大量上下文。

所以：

模型单价只是问题的一部分。

真正值得看的，是一个 Coding Agent 为了完成任务，究竟要处理多少 Context，又要处理多少轮。

---

一次任务为什么会出现 42 次 Model Call？

任务中段有一个阶段：

连续发生了 42 次 Model Call。

这一阶段一共发生了：

84 次 Tool Call。

前面先是大量代码和项目结构探索，然后进行批量修改，接着跑测试。

测试出现问题以后，又连续进行了多轮 e2e 测试、错误定位、修改和验证。

整个过程基本就是：

看结果 → 判断 → 修改 → 再跑 → 看结果 → 再修改 → 再测试……

所以这 42 次模型调用，本质上不是 42 个独立的问题。

它更像是一个持续运行的执行过程。

这也让我开始关注另一个指标：

完成同一个任务，Agent 到底需要调用多少次模型？

这和单纯比较“每百万 Token 多少钱”，其实是两个问题。

---

Cache 到底发生了什么？

这次还有一个地方让我印象很深。

任务中间，我退出了一段时间，之后重新接上这个 session。

重新接上以后，我发现出现了一次比较明显的 cold call。

按照我这次定义的标准，整个主 Agent session 里：

一共只有 2 次 cold call。

两次加起来产生了：

327,741 个 fresh input tokens。

这个数字占整个主 Agent input 的比例并不算小。

这让我重新去看 Cache 在 Coding Agent 里面的作用。

以前我会很简单地把 Cache 理解成：

能不能少付一点 Token 钱。

但真正把一个长时间运行的 Coding Agent session 拆开以后，我觉得这个理解太简单了。

更准确地说：

长 session 里，Cache 状态是否持续有效，会影响后续请求到底有多少输入能够命中缓存。

尤其是 session 被中断、重新连接之后，这种变化可能会非常明显。

当然，我不想直接把它说成：

“退出一段时间就损失了多少钱。”

因为我观察到的是 Claude Code 本地 session 里的 Token usage，而不是这次调用的最终。

所以这次实验我更愿意得出一个谨慎的结论：

Session 的连续性和 Cache 状态，可能会直接影响 Coding Agent 的实际 Token 开销。

这个问题还值得继续测。

---

Subagent 也很有意思

这次 Claude Code 一共启动了 7 个 subagent。

它们加起来：

• 116 次 Model Call
• 220,295 input tokens
• 138,511 output tokens
• 4.83M cache read tokens
• 235 次 Tool Call

116 次模型调用，占整个 session 模型调用量的：

23.7%。

但我并不想简单地下结论：

subagent 很浪费。

因为它的设计本身就是把一部分工作交给独立 Agent 去做。

这些模型调用发生在独立 Context 里，主 Agent 不需要把所有中间过程都自己背下来。

所以这里反而有一个挺有意思的现象：

增加模型调用，不一定等于增加主 Agent 的 Context 压力。

Agent 的架构设计，本身就会改变 Token 到底花在哪里。

---

再看完整的 Token 数据

重新按照真实的 model message 来统计以后，主 Agent：

• 373 次模型调用
• 682,824 input tokens
• 488,973 output tokens
• 142,388,224 cache read tokens

subagent：

• 116 次模型调用
• 220,295 input tokens
• 138,511 output tokens
• 4,829,312 cache read tokens

合起来：

489 次模型调用。

这里最容易产生一个误解：

147M cache read，是不是意味着真的花了 147M Token 的钱？

不能这么直接算。

DeepSeek 官方确实区分 cache hit、cache miss 等输入计价方式。

但 Claude Code 本地记录里的 input_tokens、cache_read_input_tokens、cache_creation_input_tokens 等字段，首先是一次 API 调用返回的 usage 数据。

要把它转换成准确的实际，还需要把每次请求对应的模型、时间段、cache hit/miss、cache creation 等数据完整对应起来。

所以这篇文章里，我先不拿这些数字硬算一个实际费用。

这篇文章先研究 Token 怎么消耗。

---

Token 成本这个词，可能太粗了

以前我会这样想：

模型 A 每百万 Token 多少钱。
模型 B 每百万 Token 多少钱。

然后选便宜的。

但一次真实 Coding Agent 任务跑下来，我发现至少还有几个变量：

Context 有多大？

模型调用了多少次？

多少输入命中了 Cache？

Cache 有没有中途发生变化？

有没有大量重复的工具结果？

有没有测试失败之后不断重新修改？

有没有 subagent？

一个任务到底需要多少轮 Agent Execution？

这些东西最后都会影响整个任务的 Token 消耗。

所以现在如果让我重新定义问题，我不会再问：

哪个模型最便宜？

我会问：

哪个 Coding Agent，能够用更少的有效模型调用，把同一个任务完成？

---

我现在有一个还很粗糙的思考框架

目前我脑子里比较接近这样：

Agent Execution Economics ≈ Context × Model Calls × Cache State

这当然不是一个真正的成本公式。

甚至连一个经过验证的数学模型都算不上。

它只是我目前用来观察 Coding Agent 的一个框架。

同样的 Context：

少跑几轮，和跑几十轮，规模完全不同。

同样的模型调用次数：

Context 是 100K，还是 500K，也完全不同。

同样的 Context 和调用次数：

Cache 稳定命中，和频繁出现 cold call，也可能完全不同。

所以我现在越来越觉得：

AI Coding 的成本，真正值得研究的不是“某一次模型调用多少钱”，而是整个 Agent Execution 到底是怎么完成任务的。

---

这也是为什么我最近开始认真记录 Claude Code 的 session。

我想继续拿真实任务做实验：

• 不同模型跑同一个任务
• 不同 Coding Agent 跑同一个任务
• 有无 subagent
• 不同 Context 管理方式
• Cache 连续和中断后的差异
• 测试失败之后，Token 是怎么增长的
• 同一个任务，能不能通过减少模型调用来降低整体开销

然后再看看：

Context × Calls × Cache

这个框架，到底只是我现在的一个直觉，还是最后真的能解释一部分 Coding Agent 的执行成本。

目前我还没有答案。

但至少这一次把真实 session 拆开之后，我终于开始知道：

Token 到底是怎么花掉的。