Claude Code vs OpenCode：惊人4.7倍Token浪费背后

核心发现：令人震惊的Token开销差异

近日，技术博客《Systima》发布了一篇针对两款热门AI编程助手——Claude Code和OpenCode的硬核对比测试。测试结果显示，在读取用户的任何提示词之前，Claude Code就会先行发送大约33,000个Token的系统提示、工具架构和“支架”信息；而OpenCode仅发送约7,000个Token。这意味着，Claude Code的开场成本是OpenCode的4.7倍（此数据基于Claude Sonnet 4.5模型）。即便切换到更新的Claude Fable 5模型，这一倍数差距缩小至3.3倍，但Claude Code的消耗依然远高于对手。

第一部分：“起步价”——纯固定成本的冲击

为了得出最精准的“起步价”，工程师们设计了一个最简单的测试任务：让两个助手回复一个字“OK”。

• Token消耗对比：在此任务中，Claude Code的首个HTTP请求包含了约32,800个Token，而OpenCode仅为6,900个。
• 工具架构是主要负担：在Claude Code发送的Token中，有大约24,000个Token是27个工具的定义（包括Cron、监控、协调等后台工具），而OpenCode仅有10个核心编码工具，消耗约4,800个Token。
• 固有系统提示：如果剔除工具架构，Claude Code的纯系统提示仍有6,500个Token，几乎是OpenCode（2,000个Token）的三倍多。这部分内容是行为准则、安全指导和任务管理设定。

第二部分：多步骤任务——差距缩小的逆转

当测试变得复杂（如一个“编写-运行-测试-修复”的多轮循环任务）时，情况发生了逆转：

• Claude Code：通过批量处理工具调用，仅用3个HTTP请求和总计121,000个Token就完成了任务。
• OpenCode：由于每次调用一个工具，加载了9次它的“小基线”，最终消耗了132,000个Token。

这说明：如果Claude Code能够坚持“少请求、高批量”的策略，其高昂的起步成本被分摊后，总开销甚至可能低于频繁刷新的OpenCode。 但这场胜利是有条件的，Claude Code在每次请求中还会动态增加“系统提醒”块（初始3块，后续膨胀到4块），这导致了其对话历史的大小会逐步侵蚀宝贵的上下文窗口。

第三部分：多重“加倍器”——现实环境下的残酷叠加

博客进一步分析了实际开发环境中，那些无法避免的额外成本是如何堆积的：

• 指令文件（如AGENTS.md/CLAUDE.md）：一个72KB的指令文件会为每个请求额外增加约20,000个Token。双方增加量相近，但Claude Code只识别CLAUDE.md，OpenCode则两者都支持。
• MCP服务器：附加5个小型的MCP服务器会引入约5,000至7,000个Token的工具架构，使工具总数从27/10激增到69/52。
• 故事框架（如BMAD）：这类工作流工具会将一个简短的指令扩展成包含角色、协议和检查表的长篇模板（约8,405字符）。该模板每次会话都会被重新发送，乘以请求次数后，开销急剧膨胀。
• 子代理：这是最昂贵的部分。仅仅将一项任务分配给两个平行子代理，Claude Code的总Token消耗就从12.1万激增至51.3万（4.2倍增长）。因为每个子代理都要支付自己的全套引导成本，父代理随后还需要消耗所有子代理的汇报内容。

结论：Token基线决定一切

文章最终强调，对于在生产环境中使用AI智能体的开发者来说，“我的AI助手真正发送了什么”是必须用数据回答的问题。Claude Code和OpenCode的设计哲学差异巨大：前者倾向于“一次性发放大额信用卡（大基线、高批量）”，而后者则信奉“精准支付小额零钱（小基线、多步骤）”。

对于开发者而言，了解这一点至关重要：

• 对于简单的一次性任务，OpenCode的成本优势明显。
• 对于复杂、需要连续多步骤推理的任务，如果Claude Code能成功批量操作，其总成本可能更低。
• 当项目规模扩大（产生大指令文件、多个MCP服务器、使用子代理）时，双方的成本都会骤增。公司必须在选用工具前，精确审计其Token消耗模式，否则昂贵的API账单和上下文窗口的无效占用将导致用户体验和成本的全面失控。

原标题：Claude Code sends 33k tokens before reading the prompt; OpenCode sends 7k。 HN 原始发布时间：2026年7月13日星期一。当前记录为 475 分、266 条评论。

阅读原文 · 查看 HN 讨论