Claude Code 与 OpenCode 的 token 开销实测对比

Claude Code 比 OpenCode 更消耗 token。我们精确测量了差异。我们将 Claude Code 和 OpenCode 放在相同的模型、相同的机器和相同的任务上，然后检查了发送和接收的所有内容。

Claude Code 更耗 token：当我们要求两个工具回复一行内容时，Claude Code 在提示词到达之前就使用了大约 33,000 token 的系统提示、工具模式和注入的脚手架。

OpenCode 使用了大约 7,000 token。Claude Code 的缓存效率低得多：OpenCode 的请求前缀在我们捕获的每次运行中都是字节相同的；它只需为每个会话支付一次缓存其有效负载的费用，然后以极低成本读回。

而 Claude Code 在会话中途反复重写数万 token 的缓存，在同一任务上写入的缓存 token 比 OpenCode 多 54 倍。缓存写入当然按溢价计费，这导致使用 Claude Code 时用量仪表盘不断攀升。

配置进一步膨胀了提示词：一个生产仓库的 72KB 指令文件（AGENTS.md 或 CLAUDE.md）为每个请求额外增加平均 20,000 token。五个中等规模的 MCP 服务器再增加 5,000 到 7,000 token。

当真实工作配置发送第一个请求时，在用户输入任何内容之前，已经达到 75,000 到 85,000 token。

子智能体增加了成本：一个直接完成花费 121,000 token 的小任务，在分发给两个子智能体时花费了 513,000 token，因为每个子智能体都有自己的启动成本，然后父智能体还要消耗其转录。

我们发现一个有利于 Claude Code 的结果：在多步骤任务中，Claude Code 的整个任务总 token 数低于 OpenCode，因为它将工具调用批量处理为更少的请求，而 OpenCode 则一轮又一轮地支付其较小的基线。

起始值更高；会话的展开方式决定了谁花费更多。本文其余部分展示了我们如何在 API 边界测量所有这些、token 的去向，以及提示缓存能节省什么、不能节省什么。为什么要测量这个？Token 开销意味着成本、延迟和上下文预算。

工具负载的每个 token 都是你无法用于代码的工作上下文，并且基线在每一轮都会被重新发送或从缓存中重新读取。

如果你在生产环境中运行智能体 AI，特别是在欧盟 AI 法案下（第 12 条要求你记录并理解系统行为），"我的智能体实际发送了什么"是一个你应该能用数据而非传言回答的问题。方法：我们在每个工具和模型端点之间插入了一个日志代理。

工具（Claude Code / OpenCode）→ 日志代理（捕获请求负载 + 响应用量）→ 模型端点。该代理每个请求记录两件事。

第一是工具发出的确切 JSON 负载，包括系统块、工具模式和消息。第二是 API 返回的用量块，涵盖输入 token、缓存写入、缓存读取和输出 token。负载捕获是工具发送内容的真实依据。用量块是计量内容的真实依据。

我们在以下条件下进行了测试：- 工具：Claude Code 2.1.207 和 OpenCode 1.17.18，均固定使用 claude-sonnet-4-5（2026 年 7 月）。- 基线隔离：全新的配置目录，无 MCP 服务器、无用户设置、无记忆；

空工作空间，无指令文件；权限绕过。然后乘数通道一次添加一个变量。- 任务：T1 要求"准确回复：OK"，隔离固定开销（每个工具运行三次）。T2 读取一个种子文件并总结。T3 是一个针对 FizzBuzz 的写-运行-测试-修复循环，外加一个检查器脚本。

- 零工具变体：Claude Code 使用 --tools ""，OpenCode 使用 "tools": {"*": false}，将系统提示与工具模式权重分离。

在数据之前有一个诚实说明：我们的流量通过一个本地 LLM 网关，该网关将请求包装在自己的信封中，我们通过裸校准请求测量出这个常数约为 6,200 token，并从下面的每个计量数字中减去。负载级别的数字来自捕获的请求体，网关无法影响，因此是精确的。

组件估算的字符到 token 转换使用每个工具自身测量的比率，即每 token 4.1 到 4.4 个字符，该比率来自冷缓存锚点（其中计量写入等于完整负载），而非通用启发式。第一部分：地板说 OK 的固定开销该任务有 22 个字符。

以下是每个工具在第一次请求时发送的内容。OpenCode 的请求接近最小化：有一个系统块以"你是 OpenCode，地球上最好的编码智能体"开头，十个经典编码工具，以及你的提示词作为唯一的用户内容。

Claude Code 的请求是一个平台引导：27 个工具包括编码核心以及整个后台智能体和编排套件，从 CronCreate 和 Monitor 到 Task 系列、工作树管理和推送通知。

在你的提示词之前，它的第一条用户消息携带三个注入的提醒块：一个用于委托的智能体类型目录、一个可用技能目录和用户上下文。

工具模式是两者的主要部分：Claude Code 约 33,000 token 中约 24,000 是工具定义，而 OpenCode 约 6,900 token 中约 4,800 是工具定义。

零工具，纯工具剥离工具后隔离出系统提示本身。Claude Code 的系统提示为 26,891 字符，约 6.5k token。OpenCode 的为 8,811 字符，约 2.0k token。

当工具禁用时，两个工具都会略微调整其提示词。

即使完全没有工具，Claude Code 的指令集也是 OpenCode 的三倍多；剩余的是行为准则，即语气规则、安全指南、任务管理指令和环境描述。单工具任务T2 要求每个工具读取一个文件并总结。

两者都生成了正确的总结。Claude Code 用了 6 个 HTTP 请求和大约 199,000 个累计计量输入 token。OpenCode 用了 4 个请求和大约 41,000 个，外加一个用于会话标题的 Haiku 侧调用。

这些 token 中的大多数是按输入价格十分之一计费的缓存读取。有三件事与负载无关地缩放：第一轮缓存写入、每轮读取和上下文窗口消耗，这些不受缓存折扣影响。33k token 的基线意味着每一轮在 200k 窗口的六分之一处开始，然后任何代码才进入对话。

多步骤任务，差距缩小T3（写-运行-测试-修复循环）颠覆了基线设定的预期。Claude Code 将整个工作（两次文件写入和两次脚本执行）批量处理为单个并行工具往返。OpenCode 每轮只进行一次工具调用，共进行了九次。

由于基线在每次请求时重新发送，请求次数乘以基线。OpenCode 支付了其约 7k 基线九次，Claude Code 支付了其约 33k 基线三次，总数趋于一致。整个任务输入大致等于基线乘以请求次数，加上对话增长。

一个积极批量处理的大基线工具和一个串行化的小基线工具可能最终落在同一位置。从负载中出现了两个结构细节。Claude Code 随着对话进行注入额外的 <system-reminder> 块，第一轮三个，到第一次工具往返时四个，因此其脚手架随轮次增加而增长。

OpenCode 每轮的边际负载（约 400 到 2,200 字符）纯粹是对话内容。第二部分：乘数地板解释了一个开始精简且保持短暂的会话。真实会话两者都不是。我们测量了实际使用叠加的每一层。

乘数 1：指令文件我们将一个生产仓库中真实的 72KB AGENTS.md 放入工作空间并重新运行 T1。效果对称且巨大。两个工具每个请求都增加了略超过 20,000 token。OpenCode 的计量总数从 13,152 增加到 33,336。

Claude Code 从 39,005 增加到 59,243。不对称在于机制，这在我们后续测试中造成了影响。