Claude Code 与 OpenCode 的 Token 开销实测：Claude Code 消耗高出数倍且缓存效率低下

概述

本次测量将 Claude Code 2.1.207 与 OpenCode 1.17.18 置于同一模型（Claude Sonnet 4.5，并选择性复测于 Fable 5）、同一任务和同等条件下，通过在编码代理与模型 API 端点之间插入日志代理，完整捕获每个请求的载荷与 API 返回的用量数据，精确量化了两种工具在 token 消耗上的差异。核心发现包括：

• 完成仅回复 “OK” 的最简任务时，Claude Code 固定开销（系统提示、工具架构、注入脚手架）约 33,000 tokens，OpenCode 约 7,000 tokens，前者是后者的 4.7 倍。
• 即使禁用全部工具，Claude Code 的系统提示（约 6,500 tokens）仍是 OpenCode（约 2,000 tokens）的 3 倍以上。
• OpenCode 请求前缀在整个会话中字节一致，缓存写入极少；Claude Code 却频繁改写前缀，同一任务下缓存写入量最高可达 OpenCode 的 54 倍，产生大量额外计费。
• 指令文件、MCP 服务器、子代理等配置会进一步放大开销，其中两个并行子代理使 token 消耗增长 4.2 倍。
• 多步骤任务中，Claude Code 通过并行工具调用批量完成工作，请求次数更少，总输入 token 数反而可能低于 OpenCode，但这是由任务结构与工具调用风格共同决定的。
• 质量方面，在正确完成的简单任务上，Claude Code 的额外 token 消耗并未带来更好结果，部分开销更是纯属浪费。

背景与问题

AI 编码代理在生产环境中部署时，token 开销同时影响成本、延迟和可用上下文窗口。每消耗一个 token 的系统指令或工具描述，就挤占了一个可用于代码理解与生成的 token。尤其在多轮对话中，基线载荷会被反复发送或从缓存读取，累积效应十分可观。欧盟《人工智能法案》第 12 条要求对系统行为进行记录与理解，而多数团队至今仍无法确切回答“上星期二到底向模型发送了什么”。此次测量正是以这一具体问题为驱动力，通过透明代理获取完整负载数据，取代传闻与猜测。

核心内容解析

测量方法与实验设置

在编码代理与模型端点之间搭建一个 Node.js 日志代理，捕获每个请求的完整 JSON 载荷（包含系统块、工具模式、消息）以及 API 返回的用量块（输入 token、缓存写入、缓存读取、输出 token）。载荷捕获是代理实际发送内容的客观记录，用量块则是实际计费的依据。所有实验在以下条件下进行：

• 代理版本：Claude Code 2.1.207 和 OpenCode 1.17.18，主要绑定模型为 Claude Sonnet 4.5，部分测试复用到 Fable 5。
• 基线隔离：全新配置目录，无 MCP 服务器、无用户设置、无记忆；空工作区，无指令文件；权限绕过。
• 任务：T1 要求仅回复 “OK”，用于测量固定开销；T2 读取并摘要一个文件；T3 写-运行-测试-修复循环（FizzBuzz）。每个任务在冷缓存条件下运行三次。
• 零工具变体：通过运行参数禁用所有工具调用能力，以分离系统提示与工具模式。
• 网关扣除：由于流量经过一个本地 LLM 网关，其信封占用约 6,200 tokens，已在所有计量数据中扣除。字符到 token 的转换比率基于每个代理自身的冷缓存锚点实测值（4.1–4.4 字符 / token），而非泛化估计。

固定开销（The Floor）

当任务仅为回复 “OK”（22 字符）时，两个代理首次请求的载荷构成如下：

差距主要源于工具定义：Claude Code 的 27 个工具包含编码核心及全套后台代理协调工具（Cron、Monitor、Task 系列等），工具模式占总开销约 24,000 tokens；OpenCode 仅有 10 个经典编码工具，对应约 4,800 tokens。即便完全禁用工具，Claude Code 的系统提示仍达 26,891 字符（约 6,500 tokens），是 OpenCode 8,811 字符（约 2,000 tokens）的 3.3 倍。剩余部分是行为准则、安全指引、任务管理指令等平台级“教义”。

缓存稳定性与效率

提示缓存在前缀保持稳定时才经济有效，但两个代理在该维度表现出根本性差异：

• OpenCode 在所有会话中请求前缀字节完全一致。三次独立的 T1 会话产生相同的 tool definitions、相同系统块、相同消息块；重复运行写入零缓存 token，所有内容从缓存读取。其 9 请求 T3 会话全程维持单一稳定前缀。
• Claude Code 每个会话产生三种不同请求类别：热身探测、主会话、子代理调用，各自拥有独立前缀，因此需要独立的缓存条目。其系统字节随会话而异，首条消息的脚手架也随运行而变化。在同一文件摘要任务（T2，6 次请求）中，Claude Code 累计写入缓存 53,839 tokens，包括一次完整的 ~43k 前缀重写；OpenCode 仅写入 1,003 tokens。重写行为在重复实验中稳定出现，证实为代理内部机制而非网关驱逐。

下表对比了同一 T2 任务下的缓存行为：

缓存写入按 1.25 倍基本费率计费（5 分钟 TTL 层），1 小时层则为 2 倍。Claude Code 因此不仅在绝对负载上更重，还在缓存经济上严重劣化。

配置乘数

指令文件

将一个真实仓库的 72KB AGENTS.md（或 CLAUDE.md）放入工作区，两个代理的每个请求均增加约 20,000 tokens。OpenCode 的总 token 从 13,152 升至 33,336，Claude Code 从 39,005 升至 59,243。值得注意的是，Claude Code 2.1.207 忽略 AGENTS.md，仅接受 CLAUDE.md 文件名；而 OpenCode 两者均读取。这意味着忽略指令文件的风险在 Claude Code 上真实存在。

MCP 服务器

连接公开的、无凭据的 MCP 服务器，每个小型服务器约增加 1,000–1,400 tokens。5 个服务器分别给 Claude Code 和 OpenCode 带来 4,900 和 6,967 tokens 的额外输入，工具数从 27 增至 69，从 10 增至 52。生产环境的复杂 API 服务器会成倍放大这一开销。

子代理（Subagents）

将同一任务分发给两个并行子代理，Claude Code 产生 9 次模型请求（1 次主会话 + 5 次子代理调用），累积计量输入达 513,000 tokens，而直接完成仅需 121,000 tokens，乘数达 4.2 倍。原因在于每个子代理需自举完整的系统提示（3,554 字符）和 24 个工具，且其完整对话转录又会被父代理吸收。OpenCode 的子代理设计更精简（1,379 字符系统提示 + 5 工具），但本次未能完成计测。子代理是实测中最大的 token 乘数。

框架模板与扩展思考

叙事驱动的工作流框架（如 BMAD）将模板文本注入对话历史，其 token 成本约为模板大小乘以请求次数。扩展思考则额外产生输出 token（费率 5 倍于输入），且推理块会作为历史被重发，与其他乘数复合。

多步骤任务（写-运行-测试-修复）中的批处理逆转

T3 任务要求编写并运行 FizzBuzz 程序，经测试与修复。结果：

Claude Code 在一次并行工具调用中完成两次文件写入和两次脚本执行，而 OpenCode 每轮仅做一件事。大基线乘以低请求数量，与小基线乘以高请求数量几乎持平。此处 Claude Code 总输入略低于 OpenCode，但这一结果高度依赖任务能允许批量合并。此外 Claude Code 在后续轮次中注入额外的 <system-reminder> 块，脚手架随轮次增加，部分抵消了并行优势。

模型依赖性

在 Fable 5 上复测固定开销，发现 Claude Code 发送的系统提示从 27,787 字符大幅缩减至 10,526 字符，工具模式也从 99,778 减至 82,283 字符。因此固定开销比从 Sonnet 4.5 上的 4.7 倍缩小至约 3.3 倍。OpenCode 的载荷在两个模型上字节完全一致。这表明 Claude Code 的负载是模型条件性的，且尽管差距缩小，其绝对负载仍远超 OpenCode。

综合配置下的天花板

整合一个真实工作配置进行 T1 冷启请求：

• OpenCode：11 个 MCP 服务器（邮件、日历、任务管理等） + 72KB 指令文件，首请求冷缓存写入 90,817 tokens（179 个工具，277KB 模式），是基线的 12 倍以上。
• Claude Code：4 个 MCP 服务器 + 插件 + 同一指令文件，写入约 75,000 tokens（118 工具）。

此时，配置乘数对成本的贡献已经远超基础平台差异。

质量视角

本次任务中两个代理均正确完成所有要求，因而 token 差异直接对应纯粹的成本差别，不含质量溢价。三个观察结果独立于质量：① 中途重写缓存前缀全无代码质量收益；② 代理静默忽略的指令文件同样毫无价值；③ 额外的上层脚手架如果不在当前任务中发挥作用，则构成浪费。至于在更复杂的工程任务上额外 token 能否换取更高成功率，尚需专门基准测试验证。

关键概念与机制

• Token 开销：每个请求中系统提示、工具模式、指令文件和其他非用户负载所占用的 token 数。直接增加 API 成本，并挤占可用上下文窗口。
• 提示缓存（Prompt Caching）：API 对请求前缀（系统提示、工具描述、早期消息）进行缓存，缓存写入按 1.25x 费率计费，读取按 0.1x 计费。仅当前缀在 5 分钟 TTL 内保持不变时，方可显著降低成本。
• 缓存稳定性：请求前缀在所有会话和请求中是否保持字节一致。OpenCode 具备高度稳定性，Claude Code 则会产生多类前缀且频繁变异，导致反复写入，直接推高计费。
• 子代理乘数：将任务委派给子代理时，每个子代理都需独立自举完整的系统提示和工具集，其转录又被父代吸收，导致总输入 token 数急剧上升。本次实验中 2 个子代理导致消耗放大至 4.2 倍。
• 批处理与请求次数：工具调用的并行化减少了请求轮次，从而减少基线重复发送次数。这是 Claude Code 在多步骤任务中得以控制总输入的主要原因，但效果取决于任务的可并行度。

优势、局限与适用场景

方法优势

• 边界测量：在代理与模型之间进行透明拦截，获取未经修改的负载和计费信息，数据可信。
• 可复现：测量工具仅需约 200 行 Node.js 代码，其他团队可以轻松采用。
• 审计完整性：所有记录通过 SHA-256 哈希链封存，符合审计追溯要求。

局限与注意

• 范围局限：仅测试了单一版本、有限任务类型（大部分为合成任务），样本量小（三次运行）。代理提示会频繁变动，测值仅代表 2026 年 7 月的快照，方法本身才是持久产物。
• 网关干扰：本地网关的模型替换和会话恢复影响了部分测试（如 Fable 路径的 Claude Code T3 被排除），表明在生产中若不进行边界日志，无法确知实际运行模型。
• 任务依赖性：Claude Code 在 T3 中总 token 较低是任务可高度批量化的结果；面对顺序依赖强的工作流，其请求次数上升将重新放大差距。
• 质量测量缺失：未评估在实际开发任务中额外 token 是否带来更高的正确率或效率，该结论不能直接推广到复杂场景。

适用场景推论

• 成本敏感型长期会话：若同一仓库中频繁使用代理且开启长对话，OpenCode 的稳定缓存可大幅降低成本；Claude Code 的高前缀变异导致缓存优势荡然无存。
• 高度并行任务：可批量工具调用的场景中，Claude Code 能通过减少轮次来抵消部分基线开销。
• 合规需求：对于需要审计日志的环境，边界代理方案同时满足 token 计量与合规记录要求。

关键要点总结

• Claude Code 固定开销约为 OpenCode 的 4.7 倍（Sonnet 4.5），即使用零工具模式仍有 3 倍以上系统提示差距。在 Fable 5 上差距缩小至 3.3 倍，因 Claude Code 对不同模型发送不同大小指令。
• 工具模式是固定开销的最大项：Claude Code 的 27 个工具占 ~24,000 tokens，OpenCode 的 10 个工具仅占 ~4,800 tokens。
• OpenCode 的请求前缀稳定，每个会话仅提交一次缓存写入，后续几乎全部命中；Claude Code 在同一任务中缓存写入量可达 5.9–54 倍，且包含大量中间重写。
• 配置乘数显著：72KB 指令文件为每个请求增加约 20,000 tokens；每个 MCP 服务器增加约 1,000–1,400 tokens；2 个子代理使 token 消耗放大 4.2 倍。
• 多步骤任务中，Claude Code 通过批量工具调用减少请求次数，可实现与 OpenCode 接近的总 token 消耗，但该结论依赖于任务结构。
• 缓存折扣无法解决全部问题：缓存写入的溢价、TTL 过期后的重写、上下文窗口的占用（85k 基线占用 200k 窗口的 42%）均不受缓存折扣影响。
• 在正确完成简单任务的前提下，Claude Code 的额外消耗未转化为质量增益，前缀重写和静默忽略指令文件属于明确的浪费。
• 建议团队使用边界日志审计代理的实际模型调用和 token 流，以便基于数据而非传闻做出优化决策。

参考资料

1. Claude Code Is Way More Token-Hungry Than OpenCode. We Measured Exactly How Much, Systima Blog, July 2026. （唯一源文献）