Claude Code 读提示前发 3.3 万 tokens，OpenCode 仅 7 千

背景

在AI编程助手的实际使用中，token消耗直接转化为成本、延迟和上下文预算。每个工具框架（harness）的额外token都是用户无法用于代码的工作上下文，而且这些基准开销会在每次交互中重新发送或从缓存读取。对于在生产环境中运行代理式AI的团队，特别是需要遵守欧盟AI法案第12条（要求记录并理解系统行为）的企业而言，“我的代理实际发送了什么”是一个应该用数据而非传说来回答的问题。Hacker News上的一篇文章对两款主流编码助手——Anthropic的Claude Code和开源的OpenCode——在同一模型、同一机器、同一任务上进行了精确的Token消耗对比测量。

核心内容

研究者通过在两个框架与模型端点之间插入日志代理，捕获每个请求的精确JSON负载（包括系统块、工具模式和消息）以及API返回的用量信息（输入token、缓存写入、缓存读取、输出token），进行了三组任务测试。所有测试均使用 Claude Sonnet 4-5（2026年7月版本），并剥离了外部配置干扰。

Part I. 基准开销：说一句“OK”的成本

任务T1要求回复“OK”（22个字符）。在首次请求中：

• OpenCode：请求接近最小化。一个系统块（以"You are OpenCode, the best coding agent on the planet"开头）、10个经典编码工具，以及唯一用户内容（你的提示）。总计约6,900 token，其中工具定义约4,800 token。
• Claude Code：请求是一个平台级启动。27个工具涵盖编码核心、后台代理、编排套件（如CronCreate、Monitor、Task家族、工作树管理、推送通知）。在用户提示之前，第一条用户消息携带三个注入的提醒块、代理类型目录、可用技能目录和用户上下文。总计约33,000 token，其中工具定义约24,000 token。

移除所有工具（零工具模式）后：

• Claude Code的系统纯指令约26,891字符（~6.5k token），OpenCode约8,811字符（~2.0k token）。即使没有工具，Claude Code的指令集规模仍是OpenCode的三倍以上，剩余部分为行为准则（语气规则、安全指导、任务管理指令、环境描述）。

Part I. 多步骤任务：差距缩小

任务T3是写-运行-测试-修复循环。Claude Code将整个工作（两次文件写入、两次脚本执行）批处理为一次并行工具往返，仅用3次HTTP请求；OpenCode每次只做一个工具调用，用了9次请求。因为基准开销在每次请求中重新发送，请求次数乘数导致总输入令牌接近：

• Claude Code：约33k基准 × 3次 = 约99k + 对话增长
• OpenCode：约7k基准 × 9次 = 约63k + 对话增长

最终全任务总输入token：Claude Code约199,000（6次请求，含缓存读取），OpenCode约41,000（4次请求+1次Haiku侧调用用于会话标题）。但当计算整个任务总量时，Claude Code因批处理而总成本低于OpenCode（原文指出在一个多步骤任务中Claude Code全任务总量更低，因为OpenCode每次转交都要支付其较小的基准开销）。

Part II. 放大因子

1. 指令文件（Instruction File）
将一个生产仓库的72KB AGENTS.md文件放入工作区后重新运行T1。两个框架每请求都增加约20,000 token：

• OpenCode：总测token从13,152增至33,336
• Claude Code：从39,005增至59,243

2. MCP服务器与配置膨胀
五个中等规模的MCP服务器额外增加5,000至7,000 token。在实际工作配置中，第一次请求发送时（用户尚未输入任何内容）已经达到75,000至85,000 token的深度。

3. 子代理（Subagents）
一个直接完成花费121,000 token的小任务，当分派给两个子代理时总成本达到513,000 token，因为每个子代理有自己的启动成本，且父代理会消耗其转录文本。

缓存效率对比

OpenCode的请求前缀在每次运行中字节相同（byte-identical），因此可以在会话中一次性缓存其负载，后续读取成本极低。Claude Code则在会话中重写数万token的提示缓存，在相同任务上写入的缓存token比OpenCode多出最多54倍。缓存写入按高级别计费，这直接导致了使用Claude Code时消耗仪表板飙升。

一项有利于Claude Code的结果

在多步骤任务T3中，Claude Code的全任务总输入token低于OpenCode，因为它将工具调用批处理为更少的请求，而OpenCode每次转交都要重新支付其较小的基准开销。初始标杆高，但会话展开方式决定了谁最终花费更多。

关键要点

• 固定开销差异显著：在用户输入任何内容之前，Claude Code发送约33,000 token（含系统提示、工具模式、注入框架），OpenCode仅约7,000 token。工具定义是最大部分（Claude Code约24k vs OpenCode约4.8k）。
• 缓存效率相差巨大：OpenCode的请求前缀完全一致，一次写入缓存后多次低成本读取；Claude Code在会话中不断重写缓存token，同一任务写入量可达OpenCode的54倍，导致更高成本。
• 配置膨胀快速推高成本：一个72KB的AGENTS.md文件为每次请求增加约20k token；五个MCP服务器再增5-7k token；实际工作配置在用户输入前已达75k-85k token。
• 子代理成本倍增：任务分解为子代理后，总token成本可放大3-4倍（如121k → 513k），主要因每个子代理的启动成本和父代理的转录消耗。
• 批处理能力可缩小差距：在多步骤任务中，Claude Code通过批处理工具调用减少请求次数，使得高基准但低请求次数的策略与低基准但高请求次数的策略总成本趋同（甚至更低）。
• 基准开销影响整个上下文窗口：33k token的基准意味着每轮对话在200k窗口中已消耗六分之一，留给代码的空间更少。
• 测量方法透明：通过日志代理捕获真实JSON负载和API返回的用量信息，并修正了本地LLM网关的常量（约6,200 token），字符到token的转换基于各自框架实测比例（4.1-4.4字符/token）。

意义与影响

1. 成本控制：开发者需意识到Claude Code的“启动成本”远高于OpenCode，尤其是在短任务或频繁交互场景下。对于长期性、多步骤任务，Claude Code的批处理优势可能抵消其高基准，但缓存效率低下仍会推高缓存写入费用。
2. 上下文预算管理：高基准开销挤占了宝贵的上下文窗口，限制了单次对话中能处理的代码量。使用Claude Code时，更早地需要清理上下文或启用长上下文模型。
3. 合规与可观测性：欧盟AI法案第12条要求记录系统行为。文章直接指出“你的代理实际发送了什么”是应该用数据回答的问题。通过此方法，企业可以量化每个请求的token构成，实现可审计性。
4. 工具选择决策：如果项目追求低成本、高缓存效率、简单任务快速响应，OpenCode是更优选择；如果任务复杂、需要并行工具调用、愿意为批处理优势付费，Claude Code可能更合适。Pro提示：使用Claude Code时需注意指令文件大小和MCP服务器数量对成本的放大效应。
5. 模型与框架的匹配：测试使用了Claude Sonnet 4-5，但框架本身的行为差异（如工具模式数量、缓存策略）独立于模型。开发者应关注框架本身的架构设计，而非仅依赖模型价格。
6. 社区启示：该实验提供了可复现的方法论——在任何编码助手与模型之间插入日志代理来精确测量token分布，这对于优化提示工程和选择AI辅助工具具有普适参考价值。