Claude Code 比 OpenCode 多烧 4.7 倍 Token？实测数据告诉你真相
用 AI 编码 Agent 写代码时，你是不是也好奇过：Claude Code 和 OpenCode 在背后到底消耗了多少 Token？你的账单差异到底是代码量造成的，还是 Agent 框架本身的差异？
Systima 团队最近发布了一篇硬核实测文章，在 Hacker News 上获得了 701 分和 395 条评论。他们在同一个模型（Claude Sonnet 4.5）、同一台机器、同样的任务上，记录了 Claude Code 和 OpenCode 每一次 HTTP 请求的完整载荷。结论出人意料：Claude Code 发送的 Token 量是 OpenCode 的 4.7 倍，而且这个差距在特定场景下还会被放大到 54 倍。
下面我们直接看数据。
固定开销：只说一句 “OK” 就要多少 Token？
最简单的测试——让两个 Agent 回复”OK”（仅 22 个字符），看看它们各自发送了多少 Token。
| 项目 | Claude Code | OpenCode |
|---|---|---|
| 首次请求总 Token | ~33,000 | ~7,000 |
| 工具定义 (Tool Schema) | ~24,000 | ~4,800 |
| 系统提示词 | ~6,500 (26,891 字符) | ~2,000 (8,811 字符) |
| 内置工具数量 | 27 个 | 10 个 |
Claude Code 的 27 个工具涵盖编码核心 + 后台 Agent + 工作编排全家桶（从 CronCreate、Monitor 到 Task 系列、工作树管理、推送通知）。而 OpenCode 更精简，只有 10 个经典编码工具。
工具定义是最大开销项：Claude Code 的 ~24,000 Token 花在了工具 Schema 上，OpenCode 只需要 ~4,800。即使把工具全部禁用，Claude Code 的指令集仍有 OpenCode 的三倍以上。
Prompt 缓存：字节稳定 vs 频繁重写
缓存效率是决定 Token 账单的关键因素。
OpenCode 的表现：字节稳定。每次请求的指令前缀在所有运行中都完全相同，三个独立的 “OK” 测试产生了完全相同的工具字节、系统字节和消息字节。会话中只需写入一次缓存，后续全部命中读取，成本极低。
Claude Code 的表现：频繁重写。在一次文件摘要任务中，Claude Code 跨 5 次请求写了 53,839 个缓存 Token，包括一次完整的 ~43K 重写。而 OpenCode 只写了 1,003 个 Token。
最极端的情况下，Claude Code 的缓存写入量是 OpenCode 的 54 倍。缓存写入是按溢价计费的（5 分钟 TTL 为 1.25 倍，1 小时 TTL 为 2 倍），这意味着 Claude Code 不仅消耗多，还在按更高的单价计费。
配置文件的放大效应
在真实项目中，你往往会有一个 72KB 的 AGENTS.md 或 CLAUDE.md 指令文件。这个文件会为每次请求增加约 20,000 Token。此外，5 个中等规模的 MCP 服务器再增加 5,000 到 7,000 Token。
真实的生产环境配置下，Agent 发出的第一次请求就已经有 75,000～85,000 Token——在用户输入任何代码之前，上下文窗口已经用掉了三分之一到近一半。
Claude Code 还有一个坑：它的某个版本会忽略 AGENTS.md，只读取 CLAUDE.md。如果文件名没改对，配置文件的加载行为会完全不同。
多步骤任务：Claude Code 的翻盘机会
不是所有场景 Claude Code 都吃亏。在多步骤任务（写代码 → 运行测试 → 修复循环）中，情况反转了：
Claude Code 将工具调用合并到更少的请求中（3 次 HTTP 请求），总消耗比 OpenCode 更低。而 OpenCode 每次请求的基线虽小，但需要更多轮次（9 次请求），每次都要重新支付 ~7K 的基线成本。
“起点更高，但过程决定谁花得更多”——这是 Systima 团队的总结。单步骤任务 OpenCode 绝对领先，多步骤任务 Claude Code 有机会扳回一局。
子 Agent 的乘数效应
当你让 Agent 使用子 Agent 时，Token 消耗会急剧放大。一项需直接完成时消耗 121,000 Token 的任务，分配给两个子 Agent 后飙升至 513,000 Token，翻了 4.2 倍。
原因在于每个子 Agent 都是独立进程，在每次执行自己的步骤时都要重新读取自己的系统提示和工具集。主 Agent 只接收子 Agent 的返回结果，但每个子 Agent 的多轮交互累积了大量 Token 消耗。
OpenCode 的子 Agent 设计更精简（1,379 字符的系统提示 + 5 个工具），但实验中未能干净地跑完全程。
换模型后差距会缩小吗？
在 Claude Fable 5 上复测，差距确实缩小了。Claude Code 的系统提示从 Sonnet 的 27,787 字符缩减到 Fable 的 10,526 字符，工具 Schema 也从 99,778 字符压缩到 82,283 字符。同样 27 个工具，少了很多说教性指令。
结果：载荷差距从 4.7 倍缩小到 3.3 倍。但 Claude Code 的请求数从 3 次增加到 6 次，包括一次 85,686 Token 的缓存重写，总计消耗 ~298,000 Token，而 OpenCode 是 133,000 Token。差距依然显著，但模型相关性很明显。
综合基准测试
Systima 团队还做了一个更接近实战的测试：10 条独立的编码任务，每个任务都有预写的、哈希验证的测试套件，Agent 不能修改测试。双方都通过了 5/5。
| 指标 | Claude Code | OpenCode |
|---|---|---|
| 平均每次通过的 Token 消耗 | ~268,000 | ~72,000 |
| 耗时 | 4～8 分钟 | 1～2 分钟 |
| 倍率 | 3.7x | 基准 |
OpenCode 不仅在 Token 上更经济，完成速度也快了好几倍。
这对你意味着什么？
- 如果你在做简单的单步骤任务：OpenCode 的 7K 基线远低于 Claude Code 的 33K，Token 账单优势明显。
- 如果你在做复杂多步骤任务：Claude Code 的请求合并策略可能反而让总消耗更低，需要实际测试。
- 如果你的项目有大的指令文件或多 MCP 服务器：两者的基线都会被放大，但 OpenCode 的小基线优势仍然保留。
- 如果你关注缓存效率：OpenCode 的字节稳定策略是压倒性优势，尤其在反复迭代同一代码库时。
- 注意：这是 2026 年 7 月的快照。Agent 的提示词变化频繁，数据会随时间漂移。重要的是理解方法论——在 API 边界记录真实载荷，而不是凭感觉判断。
想了解更多细节和完整的测试方法论，可以阅读 Systima 的原文：Claude Code Is Way More Token-Hungry Than OpenCode. We Measured Exactly How Much
相关链接