该文章对比了Claude Code与OpenCode的token消耗，发现Claude Code在系统提示、工具架构和缓存效率上远高于OpenCode，单次请求可达33,000 tokens，而OpenCode仅约7,000。配置文件、MCP服务器和子代理进一步增加了成本，实际工作配置在用户输入前已消耗75,000至85,000 tokens。

好的，这是根据您的要求，对原文主要内容进行的中文重述，已保留关键细节并删减了与核心主题无关的内容。

标题：Claude Code 比 OpenCode 更“吃”Token，我们精确测量了差距

核心发现：

我们将 Claude Code 和 OpenCode 置于相同的模型、机器和任务下进行测试，并监控了所有发送和接收的数据。结果发现，Claude Code 的 Token 消耗量远高于 OpenCode。

• 固定开销巨大： 当要求两个工具只回复一行字时，Claude Code 在用户输入到达前，就已消耗约 33,000 个 Token 用于系统提示、工具架构和注入的框架。而 OpenCode 仅消耗约 7,000 个。
• 缓存效率低下： OpenCode 的请求前缀在每次运行中都是完全相同的字节，因此只需为缓存付费一次，后续读取成本极低。而 Claude Code 会在会话中多次重写数万个缓存 Token，在相同任务下，其写入的缓存 Token 量最高可达 OpenCode 的 54 倍。缓存写入的计费更高，这解释了为何使用 Claude Code 时用量仪表盘会快速攀升。
• 配置文件增加负担： 一个生产仓库中 72KB 的指令文件（如 AGENTS.md 或 CLAUDE.md）会为每次请求额外增加约 20,000 个 Token。五个简单的 MCP 服务器又会增加 5,000 到 7,000 个 Token。因此，一个真实的工作配置在用户输入任何内容前，其首次请求的 Token 量就已达到 75,000 到 85,000。
• 子代理增加成本： 一个直接完成只需 121,000 Token 的小任务，如果分派给两个子代理，总消耗会飙升至 513,000 Token。这是因为每个子代理都有自身的启动成本，并且父代理还需要消耗其生成的对话记录。
• Claude Code 的一个优势： 在一个多步骤任务中，Claude Code 的总 Token 消耗低于 OpenCode。因为它能将多个工具调用批量合并到更少的请求中，而 OpenCode 则需为每次调用重复支付其较小的基础开销。初始成本虽高，但会话的进行方式决定了最终谁的总消耗更高。

测量方法：

我们在每个工具和模型端点之间插入了一个日志代理，用于记录每个请求的精确 JSON 载荷（包括系统块、工具架构和消息）以及 API 返回的用量数据（输入 Token、缓存写入/读取、输出 Token）。测试在受控条件下进行，包括使用相同的模型、干净的配置目录，并逐步添加变量（如指令文件、MCP 服务器等）。

缓存经济学分析：

提示缓存虽然能降低读取成本，但无法消除以下三种开销： 1. 缓存写入成本： 每次写入都需支付溢价，尤其是在会话暂停超过缓存有效期后重新写入时。 2. 读取次数成本： 请求次数越多，读取成本累积越高，子代理和串行工具循环会迅速放大这一成本。 3. 上下文窗口消耗： 这是缓存无法优化的。一个 85,000 Token 的启动负载会占据 200K 上下文窗口的 40% 以上，压缩了处理实际代码的空间。

缓存稳定性问题：

OpenCode 在所有请求和运行中都发出了字节完全一致的前缀，因此缓存写入极少。而 Claude Code 的会话中会出现多个不同的请求类别，每个都有不同的前缀和缓存条目，其系统字节和框架内容在不同运行间也会变化。这导致在相同任务下，Claude Code 的缓存写入量是 OpenCode 的 5.9 到 54 倍，而缓存写入是按溢价计费的。

结论：

• 工具本身决定了基础开销： Claude Code 的基础 Token 消耗远高于 OpenCode。
• 用户配置决定了最终账单： 指令文件、MCP 服务器、框架模板和子代理的使用会成倍放大 Token 消耗。
• 缓存并非万能： 缓存不稳定和上下文窗口的占用是 Claude Code 成本更高的关键原因。
• 测量方法比具体数字更重要： 由于工具版本和提示会频繁更新，本文提供的具体数字是 2026 年 7 月的快照，但其测量方法（在 API 边界进行日志记录）是更具持久价值的参考。

根据评论内容，总结如下：

主要观点与论据：

1. Claude Code 系统提示词过大（33k tokens）

   • 评论指出，Claude Code 在读取用户提示前就发送大量 tokens，远超其他工具（如 Pi 仅 1k tokens）。
   • 关键引用：
     • "Claude Code sending 33k tokens before reading the prompt is the AI equivalent of a consultant who bills you for the time spent reading your email before they even open it."（评论16）
     • "pi sends 1k (or less)"（评论8）

2. 成本与动机争议

   • 部分评论认为 Anthropic 通过高 token 消耗获利，并限制用户使用其他工具。
   • 关键引用：
     • "Anthropic wants to produce the best coding agent possible and doesn’t care (is even incentivized) about high costs."（评论3）
     • "My opinion is that claude code uses more tokens simply because Anthropic makes more money that way and forces people into their subscriptions."（评论11）

3. 工具调用过度与“Tokenflation”

   • 评论指出，即使是简单请求（如“Hey”），某些工具也会触发大量工具调用，导致 token 膨胀。
   • 关键引用：
     • "Tokenflation seems very real: the number of tokens consumed by simple tasks keeps increasing."（评论4）
     • "What really burns tokens is sub agents... it immediately launched 7 sub agents which burned through my budget."（评论18）

4. 替代方案与优化建议

   • 用户推荐使用更轻量的工具（如 Pi、OpenCode）或动态上下文剪枝来降低成本。
   • 关键引用：
     • "I recommend that Opencode users try Dynamic Context Pruning as well."（评论6）
     • "I am forced to use cloude code at work but a good solution is to just use --system-prompt '' and be done with it."（评论9）

5. 测试方法质疑

   • 部分评论质疑文章测试的严谨性，指出使用旧模型和自定义网关可能影响结果。
   • 关键引用：
     • "So not only is this article AI-written, but the testing was entirely done by AI, too?"（评论1）
     • "Why is your own gateway screwing with your testing?"（评论1）

平衡性总结：
- 支持方：认为 Claude Code 的高 token 消耗是设计选择或商业策略，但性能可能更优。
- 反对方：认为高成本不合理，且存在过度消耗 tokens 的动机，推荐更透明、轻量的替代工具。
- 中立观点：强调应关注任务完成质量而非单纯 token 数量，并建议优化测试方法。