Claude Code 比 OpenCode 更加 token 饥渴。我们精确测量了差距
Systima | 2026年7月12日 | 15分钟阅读
目录
- 为什么要测量这个
- 方法
- 第一部分. 最低成本
- 说“OK”的固定开销
- 零工具，纯框架
- 一个工具的任务
- 多步骤任务，差距缩小
- 第二部分. 倍数因素
- 倍数1. 指令文件
- 倍数2. MCP 服务器
- 倍数3. 框架模板
- 倍数4. 子代理
- 倍数5. 扩展思考
- 综合数字
- 缓存经济学，实话实说
- 缓存稳定性，确凿证据
- 内部测试，或基准数据集作为审计日志
- 注意事项
- 复现方法
我们将 Claude Code 和 OpenCode 放在相同的模型、相同的机器和相同的任务上，然后检查了所有发送和接收的数据。
Claude Code 胃口大得多：
当我们要求两个框架仅回复一行时，Claude Code 在提示到达之前就消耗了大约 33,000 个 token（令牌），用于系统提示、工具模式和注入的框架。OpenCode 使用了大约 7,000 个。
Claude Code 的缓存效率低得多：
OpenCode 的请求前缀在我们捕获的每次运行中都是字节完全相同的；它在每次会话中只需缓存一次有效载荷，并以极低成本回读。
另一方面，Claude Code 在会话中途反复重写了数万个提示缓存令牌，而且在 相同任务上写入的缓存令牌比 OpenCode 多出 54 倍。
缓存写入当然要按高价计费，这解释了使用 Claude Code 时使用量面板为何会攀升。
配置进一步膨胀了提示：
一个生产仓库中 72KB 的指令文件（AGENTS.md 或 CLAUDE.md）会为每个请求额外增加（平均）20,000 个 token。五个适中的 MCP 服务器再增加 5,000 到 7,000 个。等到一个真实工作环境发出第一个请求时，用户还一个字都没打，就已经消耗了 75,000 到 85,000 个 token。
子代理增加了成本：
一个直接完成的小任务花费了 121,000 个 token，而如果分发给两个子代理，则花费了 513,000 个 token，因为每个子代理都有自己的启动成本，并且父代理会消耗其全部的转录信息。
我们发现了一个有利于 Claude Code 的结果：
在多步骤任务中，Claude Code 的整个任务总消耗量低于 OpenCode，因为它将工具调用批量化为更少的请求，而 OpenCode 则在每一轮中反复支付较小的基线开销。起始计费较高；会话的进展方式决定了谁的消耗更多。
本文的其余部分展示了我们如何在 API 边界处测量这一切，令牌的去向，以及提示缓存（prompt caching）能节省什么、不能节省什么。
为何要测量这个
令牌开销意味着成本、延迟和上下文预算。每一枚工具链负载（harness payload）的令牌，都是你无法用于代码的工作上下文中的一枚令牌，而基线会在每一轮中被重新发送，或从缓存中重新读取。
如果你在生产环境中运行代理式 AI（agentic AI），尤其是在欧盟《人工智能法案》（EU AI Act）下（第 12 条要求你记录并理解你的系统行为），那么“我的代理实际上发送了什么”是一个你应该能够用数据而非传言来回答的问题。
方法
我们在每个工具链与模型端点之间插入了一个日志代理（logging proxy）。
工具链（Claude Code / OpenCode）
→ 日志代理（捕获请求负载 + 响应使用信息）
→ 模型端点
该代理记录每个请求的两项内容。第一项是工具链发出的精确 JSON 负载，即系统块（system blocks）、工具架构（tool schemas）和消息（messages）。第二项是 API 返回的使用情况块（usage block），包含输入令牌、缓存写入、缓存读取和输出令牌。
负载捕获是工具链实际发送内容的真实依据。使用情况块是计量结果的真实依据。
我们在以下条件下进行了测试。