Claude Code sends 33k tokens before reading the prompt; OpenCode sends 7k
701 points
• 4 days ago
• Article
Link
Claude Code 与 OpenCode 的对比分析显示，两者在 token 消耗和缓存效率上存在显著差异，主要源于各自的 agentic harness 在管理 system prompts 、 tool schemas 和 operational scaffolding 时的不同。在 API 边界测量时，Claude Code 更像一个沉重的平台引导器（platform bootstrap）。即便是简单任务，它也会发送约 33,000 个 token 的基线，而 OpenCode 仅约 6,900 个。差异主要来自 Claude Code 更详尽的工具定义和注入的系统提醒，这些内容在处理用户 prompt 之前就已消耗掉可用上下文窗口的大部分。
当引入 instruction files 和 Model Context Protocol (MCP) servers 等实际配置时，成本差距进一步扩大。一个标准的 72KB instruction file 会为每次请求增加大约 20,000 个 token，连接多个 MCP servers 会使负载更臃肿。由于这些配置在会话的每一轮都被注入，它们相当于持续的使用税。 subagent delegation 是最极端的倍增器：每个 subagent 都会启动自己的 bootstrap 过程，parent agent 随后会消耗产生的 transcript，导致与直接执行任务相比，总计费 token 数量大幅上升。
不过，Claude Code 在多步任务中具备战略性优势——它能把多个 tool calls 批量合并到一次请求中。通过并行执行操作，它减少了往返次数，从而在一定程度上抵消其较高的基线成本。 OpenCode 则更偏向串行、每轮通常只调用一个 tool 。因此，尽管 Claude Code 的 token 底数更高，但在复杂任务下，累计成本有时会趋于一致，甚至在某些情况下优于 OpenCode，这取决于 agent 通过 batching 管理会话长度的效率。
在 Prompt Caching 的表现上，两者差别更为明显，尤其体现在稳定性和计费方面。 OpenCode 保持高度稳定的 request prefix，使其在整个会话中能有效利用 cache hits 。 Claude Code 则容易出现 prefix 不稳定，常在会话中期重写大量 system instructions 和 scaffolding 。这类 cache writes 的计费较高，测试中 Claude Code 在相同任务下写入的 cache tokens 是 OpenCode 的多达 54 倍。这种不稳定性显著推高总成本，因为在 Claude Code 的操作周期内，cache writes 更频繁且单次费用更高。
对于在生产环境运行 agentic AI 的组织而言，这些发现强调了在 API 边界进行审计的重要性。由于 token 使用受具体 harness 架构和配置的影响很大，仅监控模型本身不足以掌握全局。维护已捕获 payload 的审计日志——可通过 tamper-evident 、 hash-chained logging 实现——对于理解系统行为并满足合规性要求（例如 EU AI Act）至关重要。通过追踪发送到模型的内容，团队可以摒弃经验主义，基于数据对 AI 基础设施和成本优化策略做出决策。
A comparative analysis of Claude Code and OpenCode reveals significant differences in token consumption and cache efficiency, driven primarily by how each agentic harness manages its system prompts, tool schemas, and operational scaffolding. When measured at the API boundary, Claude Code acts as a heavy platform bootstrap. Even for a simple task, it sends a baseline of approximately 33,000 tokens, compared to just 6,900 for OpenCode. The majority of this discrepancy arises from Claude Code's more extensive tool definitions and injected system reminders, which consume a substantial portion of the available context window before the user prompt is even processed.
The cost disparity widens significantly when real-world configurations, such as instruction files and Model Context Protocol (MCP) servers, are introduced. A standard 72KB instruction file can add 20,000 tokens to every request, while attaching multiple MCP servers further bloats the payload. Because these configurations are injected into every turn of a session, they function as a continuous tax on usage. Subagent delegation represents the most extreme multiplier, as every subagent initiates its own bootstrap process and the parent agent subsequently consumes the resulting transcript, leading to a massive increase in total metered tokens compared to executing tasks directly.
However, Claude Code demonstrates a strategic advantage in multi-step tasks due to its ability to batch multiple tool calls into a single request. By performing operations in parallel, it reduces the number of round trips, which effectively mitigates the impact of its higher baseline cost. In contrast, OpenCode follows a more serialized, one-tool-per-turn approach. Consequently, while Claude Code starts with a much higher token floor, the cumulative cost of a complex task can sometimes converge or even favor Claude Code, depending on how effectively the agent manages its session length through batching.
Prompt caching dynamics further differentiate the two harnesses, particularly regarding stability and billing. OpenCode maintains a highly stable request prefix, allowing it to leverage cache hits effectively throughout a session. Claude Code, however, is prone to prefix instability, frequently rewriting large portions of its system instructions and scaffolding mid-session. These cache writes are billed at a premium, and in testing, Claude Code wrote up to 54 times more cache tokens than OpenCode for identical tasks. This instability significantly impacts the overall cost, as cache writes occur at a higher rate and are more frequent in Claude Code's operational cycle.
For organizations running agentic AI in production, these findings highlight the importance of auditing at the API boundary. Because token usage is heavily influenced by the specific harness architecture and configuration, simply monitoring the model itself is insufficient. Maintaining an audit log of captured payloads—which can be done via tamper-evident, hash-chained logging—is essential for understanding system behavior and meeting compliance requirements, such as those outlined in the EU AI Act. By tracking what is sent to the model, teams can move away from folklore and toward data-driven decisions regarding their AI infrastructure and cost optimization strategies.
392 comments • Comments Link
• 子代理架构常被批评为 token 使用效率低，因为它们经常产生多个冗余进程，重复读取代码库并重复嵌入大量系统提示，从而带来不必要的成本。
• 递归式子代理探索在规划或复杂调查中可能很有价值，但这些代理往往难以调优，偏向穷尽式搜索而不是采用简单的、迭代式的代码执行尝试。
• 商业化编码框架中的系统提示常常消耗大量 token 预算，有些配置在开始任何实际工作之前就已经超过 30k tokens 。
• 当前行业朝向"tokenflation"（即代理为琐碎任务发起过多工具调用或过度后台验证，如静态检查和测试）的趋势，对关注成本效率的用户来说，正成为日益严重的摩擦点。
• 采用替代的、轻量级的编码框架或自建的定制代理，通常能显著节省成本，因为这些方案允许最小化系统提示，并对模型行为和工具使用进行更细粒度的控制。
• 关于 AI 实验室的潜在激励机制存在争议，一些人认为专有的编码框架可能被用来推动更高的 token 消耗，并将用户引向更昂贵的订阅层级。
• 框架之间的性能差距通常与底层模型智能关系不大，更大程度上取决于"包装层"的开销——包括其如何高效利用 KV 缓存以及管理上下文窗口。
• 降低成本的策略包括精简不必要的系统指令，使用更小的"mini"模型来协调子任务，以及采用动态上下文裁剪来防止冗余数据处理。
• 社区正越来越倾向于"vibe coding"或构建自定义的极简框架，认为当前的商业工具往往充斥着过多依赖项和不透明的逻辑。
• 在编码框架之间进行比较仍然复杂，因为网关代理、不同的工具 schema 和缓存失效模式使得建立真正标准化的性能基准变得困难。
这场讨论反映了集成式编码代理带来的便利与其底层架构所产生的财务与性能成本之间日益紧张的矛盾。许多用户主张采用比商业"黑箱"框架更透明、更轻量且可定制的替代方案，指出过度的 token 浪费和不必要的后台任务是主要缺陷。尽管有人认为代理的复杂性是提高生产力所必须付出的权衡，但相当一部分社区正转向构建或采用更精简的解决方案，以重新掌控开发环境和支出。 • Sub-agent architectures are frequently criticized for token inefficiency, as they often spawn multiple redundant processes that re-read codebases and duplicate system prompts, leading to unnecessary costs.
• Recursive sub-agent exploration can be valuable for planning or complex investigation, but these agents are often poorly tuned, favoring exhaustive searching over simple, iterative attempts at code execution.
• System prompts in commercial coding harnesses often consume significant token budgets, with some configurations reaching over 30k tokens before a single line of actual work is performed.
• The current industry trend toward "tokenflation"—where agents perform excessive tool calls or background verification (like linting and testing) for trivial tasks—is a growing point of friction for users focused on cost-efficiency.
• Using alternative, lightweight coding harnesses or custom, self-built agents often yields substantial savings, as these allow for minimized system prompts and more granular control over model behavior and tool usage.
• There is a debate regarding the underlying incentives of AI labs, where some view proprietary coding harnesses as mechanisms to drive higher token consumption and push users toward more expensive subscription tiers.
• Performance gaps between harnesses are often less about the intelligence of the underlying model and more about the overhead of the "wrapper," including how effectively it utilizes KV caching and manages context windows.
• Strategies to mitigate costs include stripping unnecessary system instructions, utilizing smaller "mini" models for sub-task orchestration, and employing dynamic context pruning to prevent redundant data processing.
• The community is increasingly moving toward "vibe coding" or building custom, minimal harnesses, arguing that current commercial tools are often bloated with excessive dependencies and opaque logic.
• Comparison metrics between coding harnesses remain complex, as gateway proxies, differing tool schemas, and cache invalidation patterns make it difficult to achieve truly standardized performance benchmarks.
The discussion reflects a growing tension between the convenience of integrated coding agents and the financial/performance costs imposed by their underlying architectures. Many users advocate for more transparent, lightweight, and customizable alternatives to commercial "black box" harnesses, citing excessive token waste and unnecessary background tasks as primary drawbacks. While some see the complexity of these agents as a necessary trade-off for productivity, a significant portion of the community is shifting toward building or adopting leaner solutions to regain control over their development environment and expenditures.