Claude Code与OpenCode令牌实测：读取用户提示前差距近4.7倍

Systima 在相同电脑、相同模型和相同任务条件下，对 Claude Code 与 OpenCode 的 API 请求进行了逐项记录。测试关注的不是模型输出质量，而是智能体工具在用户提示词送达模型之前，会自动附加多少系统提示、工具结构和框架信息。

在 Claude Sonnet 4.5 上执行只需回复一行文字的简单任务时，Claude Code 的初始请求约包含 3.3 万个令牌，OpenCode 约为 7000 个，相差接近 4.7 倍。Claude Code 的约 3.3 万令牌中，工具定义占约 2.4 万；移除工具后，其系统提示本身约为 6500 个令牌，而 OpenCode 约为 2000 个。

换用较新的 Claude Fable 5 后，差距缩小到约 3.3 倍。原因是 Claude Code 会根据模型调整系统提示，发送给 Fable 的指令和工具结构比 Sonnet 更短。这也意味着开销倍数并非固定数字，而是会随着客户端版本、模型和配置变化。

在简单文件总结任务中，Claude Code 发出 6 次 HTTP 请求，累计计量输入约 19.9 万令牌；OpenCode 发出 4 次主要请求，累计约 4.1 万令牌，另外还有一次用于生成会话标题的小模型调用。缓存读取虽然价格较低，但这些令牌仍会占用上下文窗口。3.3 万令牌的基础负担，相当于在 20 万令牌窗口中先消耗约六分之一。

多步骤任务的结果出现变化。Claude Code 通过更积极的工具批处理，只用 3 次主要请求完成任务，累计约 12.1 万令牌；OpenCode 因为请求次数更多，反复携带较小的基础提示，累计约 13.2 万令牌。测试说明，单次请求的固定开销不等于整个任务的最终成本，请求数量和工具调度方式同样重要。

项目配置会继续放大开销。一份约 72KB 的 AGENTS.md 或 CLAUDE.md 指令文件，平均会为每次请求增加约 2 万令牌。五个中等规模的 MCP 服务还会增加约 5000 至 7000 个令牌，因为每个服务都需要把工具参数结构加入上下文。框架模板一旦进入对话历史，也会在之后的每次请求中重复携带。

子智能体是另一个明显放大器。同一个小型任务直接执行时使用约 12.1 万输入令牌，拆分给两个子智能体后累计达到约 51.3 万，是原来的 4.2 倍。每个子智能体都要加载自己的系统提示和工具，父智能体之后还需要重新读取子任务记录，因此并行并不一定节省成本。

缓存稳定性方面，OpenCode 在测试中持续发送字节完全一致的请求前缀，同一会话只需写入一次缓存，后续可以低价读取。Claude Code 则出现多种请求类型，系统提示和首条消息包装也会变化。在相同文件总结任务中，Claude Code 一次运行累计写入 53839 个缓存令牌，OpenCode只写入 1003 个。

研究者重复测试后仍观察到 Claude Code 在会话中重新写入完整前缀。根据缓存冷热状态不同，它在同一任务中的缓存写入量约为 OpenCode 的 5.9 至 54 倍。缓存写入通常按基础输入价格的 1.25 倍计费，使用更长缓存保留时间时价格还可能更高。

在接近真实生产配置的测试中，OpenCode 加载 11 个 MCP 服务和 72KB 指令文件后，首次请求达到 90817 个令牌，包含 179 个工具；Claude Code 加载 4 个 MCP 服务、插件和相同指令文件后，请求约为 7.5 万令牌，包含 118 个工具。由此可见，客户端决定基础开销，而用户安装的工具和规则决定开销最终扩大到什么程度。

两款工具都正确完成了用于计量的任务，因此这些数字反映的是取得相同结果时的上下文成本，而不是质量差异。测试没有评估 Claude Code 的后台智能体、技能系统和编排能力是否能在更复杂工程任务中带来更高成功率。

这组数据来自一台机器和少量实验，主要使用 2026 年 7 月的 Claude Code 2.1.207、OpenCode 1.17.18、Sonnet 4.5 与部分 Fable 5 测试。请求经过本地模型网关，研究者测量并扣除了约 6200 个令牌的固定网关包装。客户端提示和工具结构更新频繁，因此具体数值应视为当时快照，长期更有价值的是在 API 边界记录真实请求的方法。

对于生产智能体系统，优化重点不应只放在缩短用户提示词。指令文件规模、MCP 工具数量、框架模板、子智能体启动次数、请求轮数以及缓存前缀是否稳定，都会直接影响成本、延迟和可用上下文。持续记录实际发送给模型的 JSON 请求和返回的计量字段，才能准确判断令牌花在了哪里。