实测对比：Claude Code与OpenCode的Token开销

我们将Claude Code和OpenCode置于同一模型、同一设备和同一任务环境下，全程追踪所有收发数据，得到以下结论：

Claude Code的基础开销远超OpenCode 当要求两者以单行内容回复时，用户的实际指令尚未送达，Claude Code就已加载约33000个令牌的系统提示词、工具架构和内置框架代码；而OpenCode仅使用约7000个令牌。

Claude Code的缓存效率极低 OpenCode的请求前缀在所有测试中完全一致，只需在会话开始时缓存一次后续读取，成本微乎其微。反观Claude Code，会话期间每一次任务执行都会重写数万个缓存令牌，同一任务下的缓存写入量最高可达OpenCode的54倍。缓存写入本身按溢价计费，这正是使用Claude Code时用量面板持续攀升的原因。

配置进一步推高提示词规模 生产环境代码库中的72KB指令文件（AGENTS.md或CLAUDE.md）会为每一次请求平均增加约20000个令牌。若接入5台常规MCP服务器，还会额外增加5000至7000个令牌。实际业务场景中，用户尚未输入任何内容，首次请求的令牌量就已达到75000至85000个。

子代理大幅提升成本 某项直接执行仅需121000个令牌的小型任务，交由两个子代理处理时，令牌消耗飙升至513000个。原因在于每个子代理都有独立的启动开销，且主代理还需处理子代理的执行日志。

Claude Code唯一的优势 在多步骤任务中，Claude Code的总令牌消耗低于OpenCode。因为它能将工具调用批量整合到更少的请求中，而OpenCode则需在每一轮重复支付其较低的基础开销。初始门槛更高，但最终成本取决于会话的具体流程。

本文后续将详细说明我们如何在API层面完成这些测量、令牌的具体流向，以及提示词缓存的实际作用与局限。

为何要做这项测量

令牌开销直接关联成本、延迟和上下文容量。每一个用于工具框架的令牌，都意味着少一个可用于代码处理的工作上下文令牌；而且基础开销会在每一轮对话中重复发送或从缓存中读取。

如果您在生产环境中运行智能代理AI，尤其在欧盟《AI法案》框架下（第12条要求记录并理解系统行为），您必须能够用数据而非经验回答"我的代理实际向模型发送了什么"这一问题。

测量方法

我们在工具框架与模型端点之间接入日志代理：

工具框架（Claude Code / OpenCode）
→ 日志代理（捕获请求负载与响应用量）
→ 模型端点

代理为每一次请求记录两类数据：一是工具框架发出的完整JSON负载，包括系统块、工具架构和消息；二是API返回的用量统计，涵盖输入令牌、缓存写入、缓存读取和输出令牌。

捕获的负载是工具框架发送内容的真实依据，用量统计则是计费的真实依据。

测试在以下条件下进行：

工具框架版本：Claude Code 2.1.207和OpenCode 1.17.18，均绑定claude-sonnet-4-5模型（2026年7月版本）。
基线隔离：全新配置目录，无MCP服务器、无用户设置、无记忆功能；空工作区，无指令文件；权限已绕过。后续测试会逐一添加变量。
测试任务：T1要求"回复内容为：OK"，用于隔离固定开销（每个框架测试3次）；T2读取指定文件并生成摘要；T3针对FizzBuzz代码执行"编写-运行-测试-修复"循环，并调用检查脚本。
无工具变体：Claude Code使用--tools ""参数，OpenCode设置"tools": {"*": false}，以区分系统提示词与工具架构的开销。

数据说明：我们的流量通过本地LLM网关转发，网关会为请求添加固定封装，经校准测量约为6200个令牌，以下所有计费数据均已扣除该常量。负载层面的数据来自捕获的请求体，不受网关影响，为精确值。

组件令牌估算采用各框架自身的字符-令牌转换比率（每令牌对应4.1至4.4个字符），该比率由冷缓存锚点（计费写入量等于完整负载）推导而来，而非通用估算值。

第一部分：基础开销

回复"OK"的固定开销

任务本身仅22个字符，但各框架首次请求时发送的内容如下：

组件	Claude Code	OpenCode
系统提示词	27344字符，3个模块	9324字符，1个模块
工具架构	27个工具，99778字符	10个工具，20856字符
初始消息框架	7997字符	无
实际请求内容	22字符	22字符

OpenCode的请求接近最小化配置：一个以"你是OpenCode，全球最佳代码代理"开头的系统模块、10个经典代码工具，加上用户的实际请求内容。

Claude Code的请求则是一套完整的平台启动流程：27个工具中除核心代码工具外，还包含全套后台代理与编排组件，从CronCreate、Monitor到Task系列工具，以及工作树管理和推送通知功能。

在用户请求之前，它的初始用户消息中包含三个注入的提醒模块：可委托的代理类型列表、可用技能列表和用户上下文信息。

工具架构是两者开销的主要构成：Claude Code约33000个令牌中，约24000个来自工具定义；OpenCode约6900个令牌中，约4800个来自工具定义。

无工具模式下的纯框架开销

移除工具后，系统提示词的开销得以单独体现：Claude Code为26891字符，约6500个令牌；OpenCode为8811字符，约2000个令牌。

禁用工具后，两者的提示词都会略有缩减。但即便完全无工具，Claude Code的指令集规模仍是OpenCode的三倍以上，剩余部分为行为准则，包括语气规则、安全指引、任务管理说明和环境描述。

单工具任务测试

T2任务要求读取文件并生成摘要，两者均完成了正确的摘要输出。

Claude Code发起6次HTTP请求，累计计费输入令牌约199000个；OpenCode发起4次请求，累计计费输入令牌约41000个，额外调用一次Haiku模型生成会话标题。

这些令牌中大部分是缓存读取，费用仅为输入令牌的十分之一。但有三项开销不受缓存影响：首次请求的缓存写入、每一轮的缓存读取，以及上下文窗口占用——这部分无法通过缓存折扣降低。

33000个令牌的基线意味着，在任何代码进入对话之前，每一轮对话就已占用200000令牌上下文窗口的六分之一。

多步骤任务：开销差距缩小

T3任务（编写-运行-测试-修复循环）的结果与基线测试的预期相反：

指标	Claude Code	OpenCode
模型请求次数	3次	9次（+1次标题调用）
工具调用方式	单次往返批量并行调用	每轮调用一个工具
累计计费输入令牌	~121000个	~132000个

Claude Code将整个任务（两次文件写入和两次脚本执行）整合为一次并行工具调用；OpenCode则每轮仅调用一个工具，共执行9轮。

由于基线开销会随每一次请求重复产生，请求次数直接放大基线成本：OpenCode的约7000令牌基线重复9次，Claude Code的约33000令牌基线重复3次，最终总开销趋于接近。

任务总输入令牌量约等于基线开销乘以请求次数，加上对话内容增长。基线开销大但调用批量处理的框架，与基线开销小但串行处理的框架，最终成本可能相当。

从负载数据中还发现两个结构细节：随着对话推进，Claude Code会注入额外的<system-reminder>模块，第一轮3个，首次工具调用时增至4个，即其框架开销随对话轮次增加；OpenCode每轮的边际负载约为400至2200字符，全部为对话内容。

第二部分：成本乘数

基础开销解释了简洁且短暂的会话情况，但实际业务会话并非如此。我们测量了实际使用场景中叠加的每一层开销。

乘数1：指令文件

我们将生产环境代码库中真实的72KBAGENTS.md文件放入工作区，重新运行T1任务。

影响显著且具有对称性：两个框架的每一次请求都增加了约20000个令牌。OpenCode的计费总量从13152增至33336，Claude Code则从39005增至59243。

两者的实现机制存在差异，这在实验中给我们带来了困扰：Claude Code 2.1.207完全忽略AGENTS.md，仅在文件重命名为CLAUDE.md时才会读取，并将其注入初始用户消息；OpenCode则可读取任一文件名，并将其注入系统提示词。

这带来两个实际启示：确认您使用的框架实际支持哪个文件名，因为被忽略的指令文件不会给出任何提示；沉重的指令文件几乎会将轻量框架的基线开销翻四倍，且该开销会伴随代码库中每一次会话的每一个请求。

乘数2：MCP服务器

我们分别接入1台和5台公开免密的MCP服务器。由于架构相同，两者的开销增长几乎一致：每台小型服务器每一次请求增加约1000至1400个令牌。接入5台服务器后，Claude Code的负载增加4900个令牌，OpenCode的计费增加6967个令牌，工具数量分别从27增至69、从10增至52。

小型公开服务器是开销较小的情况，生产环境中拥有丰富API的服务器，其架构开销会数倍于此，这正是后文"全配置测量"的结果。

操作提示：在打印模式下，Claude Code会默认忽略项目级别的.mcp.json配置，需显式传入--mcp-config参数才会生效。若您假设已接入服务器，请在边界处进行验证。

乘数3：框架模板

BMAD等故事驱动的工作流框架，会将一条斜杠命令扩展为包含角色、协议和检查清单的大型提示词模板。

我们使用一个8405字符的典型模板作为T3任务的请求内容。模板本身仅约2100个令牌，但它会进入对话历史，并在会话的每一次后续请求中被重复携带。一个包含9次请求的会话会重复发送模板9次。

框架开销等于模板大小乘以请求次数，且会叠加在上述所有开销之上。

乘数4：子代理

我们要求两个框架将任务分发至两个并行子代理处理，此时总开销急剧上升。

Claude Code通过9次模型请求完成任务，分为三类：主会话携带完整的约33000令牌基线；5次子代理调用各携带独立的启动开销——3554字符的代理系统提示词，加上27个工具中的24个。

累计计费输入令牌达到513000个，而直接执行仅需121000个，单次适度分发就带来4.2倍的开销乘数。原因在于每个子代理都需支付自身的启动成本，且其执行日志还会被主代理读取。

OpenCode在此处的设计明显更简洁：其子代理请求仅携带精简的配置——1379字符的系统提示词和5个工具。由于网关兼容性问题，其子代理任务未完整执行，因此我们仅报告捕获的负载中的设计差异，不提供具体数值。

如果您发现复杂会话的开销异常，首先应检查是否使用了子代理。委托功能强大且有时十分必要，但也是我们测量到的最大令牌开销乘数。

乘数5：扩展思考模式

思考输出按输出令牌费率计费，是输入费率的5倍，且推理模块会被保留在对话历史中。

我们尝试在两个框架中切换扩展思考模式，但决定不公布相关数据。因为我们的网关会应用自身的思考策略，两个框架的切换设置均未生效，任何数据都将是无效噪声。

但其机制是明确的：在推理密集型任务中，思考模块会与上述所有乘数叠加，因为思考模块会加入需重复发送的对话历史。

全配置开销

最后是贴近实际的测量：我们在真实工作配置下重新运行T1任务。

OpenCode接入了11台MCP服务器（涵盖邮件、日历、任务管理、参考管理、产品分析等），加上72KB的指令文件。首次请求在冷缓存写入时计费90817个令牌，包含179个工具和277KB的架构，此时用户尚未输入任何内容。

Claude Code接入4台MCP服务器、已安装插件和同一指令文件，生成了311KB的负载，约75000个令牌，包含118个工具。

扣除网关封装后，OpenCode的配置开销是其约7000令牌基线的12倍。框架设定基础门槛，而您的配置决定最终账单。

缓存的实际经济效益

提示词缓存改变了计费单位，但并未改变核心结论。

两个框架都正确设置了缓存断点：负载仅写入一次，5分钟TTL（生存时间）的写入费率为基础费率的1.25倍，后续读取费率仅为基础费率的十分之一。

但有三项成本无法通过缓存折扣降低：

缓存写入本身：若会话暂停超过TTL，就需重新支付写入成本。5分钟的思考、一场会议、一次午餐，都会导致整个堆栈以写入费率重新加载。
缓存读取乘以请求次数：子代理分发和串行工具循环会迅速放大这一成本。
上下文窗口占用：完全不受缓存影响。85000个令牌的启动开销，在每一次请求中都会占用200000令牌上下文窗口的40%以上，在触发压缩（需额外消耗令牌生成摘要）前，留给实际代码处理的空间已大幅缩小。

缓存稳定性：关键差异

只有当请求前缀保持稳定时，缓存才具有经济价值。因此我们对数据集中每一次请求的工具数组和系统模块进行了哈希运算。

OpenCode在所有请求和测试中都输出完全相同的前缀：三次独立的T1会话生成的工具字节、系统字节和消息字节完全一致；重复测试时缓存写入量为零，全部读取自缓存。其包含9次请求的T3会话全程保持一个稳定前缀。

Claude Code在每个会话中输出三类不同的请求：预热探测、主对话和子代理调用，每类都有独立的前缀，因此对应独立的缓存条目。同一工作区的不同会话之间，其系统字节也存在差异；不同测试之间，初始消息框架也有所不同。

这一差异直接体现在缓存写入数据中：在完全相同的文件摘要任务中，Claude Code在5次请求中写入53839个缓存令牌，包括一次任务中途对约43000令牌前缀的完整重写；而OpenCode仅写入1003个令牌。

我们重复测试以确认是否为偶然现象，结果并非如此：大规模中途重写现象再次出现，第一次测试为43342个令牌，第二次为36899个令牌；仅在缓存已预热的第三次测试中写入量几乎为零。而OpenCode在所有可准确测量的会话中，均未出现中途重写。

根据缓存状态，Claude Code在同一任务中的缓存写入量是OpenCode的5.9至54倍，且缓存写入按溢价计费：5分钟层级为基础费率的1.25倍，1小时层级为2倍。

需说明的一点：任务中途的缓存缺失理论上可能由网关驱逐导致，但多次测试重复出现该现象，表明更可能是框架的系统性行为；且前缀不稳定本身是框架层面的问题，在网关介入前的捕获字节中即可观察到。

如果您发现使用Claude Code时用量面板急剧攀升，而使用OpenCode搭配同一模型时用量保持平稳，最可能的原因就在于此：更大的前缀、每个会话更多的独立前缀、更频繁的重写，再乘以子代理分发的乘数效应。

内部测试：基准数据集作为审计日志

本次实验的核心原则是"信任捕获的负载"，因此我们采用向客户推荐的生产推理日志处理方式来管理数据集：

所有150条捕获的请求/响应记录，均使用我们的开源库@systima/aiact-audit-log写入防篡改的SHA-256哈希链式审计追踪，且整个链条可端到端验证：

链条验证通过：150条记录
未发现断裂
哈希链条完整性：有效

这正是该库为欧盟《AI法案》第12条日志要求提供的机制：结构化记录、可提交给第三方验证的完整性，以及对收发内容的精准还原。

令牌基准测试是该机制的低风险应用场景，而信贷决策代理等场景则完全不同。

局限性说明

单一设备、单一版本组合、单一模型系列、样本量小（T1测试3次、T2测试3次、每个乘数场景测试1次）。框架提示词会频繁更新，因此本文数据仅为2026年7月的快照，测量方法才是具有长期价值的成果。
测量路径中存在本地网关。组件层面的数据来自捕获的负载，不受网关影响；计费数据为扣除网关常量后的冷缓存锚点数据，热运行计费数据无法明确归因，因此仅引用冷缓存锚点。此外网关还静默替换了我们指定的模型版本，这本身也是一个教训：若未在API边界处记录，您无法知晓实际运行的是哪个模型。
T3任务的开销趋同仅为单个任务形态的观测结果。严格串行的任务会增加Claude Code的请求次数，从而推高总开销。OpenCode的无工具和子代理场景因网关兼容性问题返回了格式错误的流，因此仅报告捕获的负载大小。
全配置数据描述的是某一位从业者的具体设置，仅提供规模和数量信息。您的配置会有所不同，但测量方法具有通用性。

复现方法

测量工具约200行Node.js代码，是一个HTTP代理，可转发请求至您的模型端点，将每个请求体和响应用量块写入磁盘，并将每一组记录追加至审计链条。

将ANTHROPIC_BASE_URL指向该代理。为框架提供全新的配置目录和空工作区以测量基础开销，然后逐一添加您的指令文件、MCP服务器和工作流，观察边界处的变化。

如果您的流量通过网关转发，先用空请求测量网关封装的开销，并确认实际响应的模型版本。

如果您在生产环境中运行智能代理系统，但无法回答"上周二我们向模型发送了什么具体内容"，这正是您需要首先解决的问题。令牌统计会随之迎刃而解。