待验证｜Systima 称 Claude Code 预提示开销约 3.3 万 tokens

一句话结论：这是一条值得记录但不能下定论的 Coding Agent 成本信号。Systima 7 月 12 日原文称，Claude Code 与 OpenCode 在读用户 prompt 前分别发送约 3.3 万 tokens 和 7000 tokens。原文已经恢复可读，但这仍是单源测试，尚缺第三方复现和原始 request 审计。

能确认的事实有三类。第一，HN Algolia 和 HN 讨论页都保留了同一个标题、作者和创建时间，item 创建于 2026-07-12T18:25:51Z。第二，HN 页面保留了作者自述：他们原本使用 OpenCode，后来因 Meridian 问题被迫使用 Claude Code，观察到使用量表增长更快，于是在 agentic coding tool 与 Anthropic endpoint 之间加日志，记录 requests 和返回的 usage blocks。第三，HN 评论里保留了方法质疑和作者回复，包括本地 LLM gateway、system prompt plus tool schemas、cache strategy、subagent、reproduction inputs/outputs 等关键词。

不能确认的部分更关键：Systima 正文披露了 Method、Caveats、cache economics 和 Reproducing it，但原始 request body、完整 usage blocks、tokenizer 复算脚本和第三方复现仍未进入本期材料。HN 评论引用原文称使用 Claude Code 2.1.207 与 OpenCode 1.17.18，并提到本地 Meridian gateway 的 envelope 约 6,200 tokens；这些仍然是讨论页层面的低置信材料，不是可审计的实验数据。

读者真正需要带走的不是“Claude Code 一定浪费 3.3 万 tokens”这个未证实结论，而是一个更可验证的问题：Coding Agent 的成本已经不只发生在用户 prompt 之后。预提示、工具说明、MCP/插件列表、项目记忆、权限策略、上下文快照、subagent 编排和缓存失效，都可能在用户还没输入有效任务前占掉上下文预算。

目前能核实到什么

HN Algolia 返回的 item 结构显示，故事作者是 systima，标题称 Claude Code 与 OpenCode 在读提示前分别发送约 3.3 万和 7000 tokens，链接指向 systima.ai/blog/claude-code-vs-opencode-token-overhead。HN 讨论页在抓取时显示 169 points 和 98 comments，但这种热度数字会变化，只能说明社区讨论规模，不能证明标题数字。

HN 页面里的 toptext 比标题多一点上下文：作者称他们通常使用 OpenCode，后来因 Meridian 相关问题转用 Claude Code，感到 usage meter 上升更快，于是做了一个小研究，记录 Claude Code 和 OpenCode 到 Anthropic endpoint 的请求以及返回 usage blocks，并声称 Claude Code 在 cache strategy 和 harness token usage 上更低效。这里的“更低效”仍然只是作者自述；没有原文表格时，不能判断它对应的是输入 tokens、cache creation tokens、cache read tokens、输出 tokens，还是 gateway 注入之后的总 payload。

评论区反而提供了这次低置信深挖最有价值的边界。一个评论引用原文片段，质疑“Claude Code 2.1.207 and OpenCode 1.17.18, both pinned to claude-sonnet-4-5”这一设置，也质疑作者自己的 gateway 为什么会影响测试。Systima 作者随后回复说，模型选择主要出于成本和稳定快照考虑，固定 harness payload 包含 system prompt plus tool schemas，因此 headline numbers 不应变化太大；他们还说愿意在 Fable 上重跑矩阵并发布 diff。另一个作者更新称，会补充更深入任务、质量对比，以及尽快复现 inputs 和 outputs。

这些 caveats 降低了标题数字的可外推性。因为如果本地 gateway 会把请求包装进自己的 envelope，且裸校准请求约 6200 tokens，那么“约 3.3 万 vs 7000 tokens”至少要拆成三段：工具本身注入了多少，gateway 注入了多少，provider cache 又按什么价格计费。任何把这组数字当成“Claude Code 官方默认开销”的写法都是过度外推。

隐性上下文成本如何拆账

把这条 HN 讨论翻译成工程问题，核心不是“哪个 agent 名声更差”，而是“用户 prompt 之前已经发生了哪些可计量成本”。一个可复核报告至少要把下面这些层分开，否则所有数字都会混在一起。

成本层	可验证口径	这次已确认/未确认	为什么影响约 3.3 万 vs 7000 tokens
预提示与系统规则	记录最终发送给模型的 system/developer/tool 前缀，并给出 tokenizer 版本	Systima 原文和 HN 作者回复均称 fixed payload 包含 system prompt 与 tool schemas	这是“读 prompt 前”的最大候选来源，必须和用户消息分开
工具说明与 tool schema	逐项列出 read/edit/bash/search/MCP 等工具 schema 的 token 数	HN 评论明确提到 tool schemas；OpenCode README 说明内置 agents	工具越多，schema 越长；禁用工具后数字应明显下降
项目记忆与规则文件	记录 CLAUDE.md、AGENTS.md、skills、memory files 是否进入首轮上下文	未见原文表格；HN 有用户提到 /context 分类	同一工具在不同 repo 的初始成本可能完全不同
Gateway envelope	无 gateway 与有 gateway 双路径各跑一次，报告 envelope baseline	HN 作者回复提到 Meridian envelope 约 6,200 tokens	如果不扣除 gateway，工具对比会被代理层污染
Cache 策略	报告 cache creation、cache read、cache miss，并说明价格口径	HN toptext 声称 cache strategy 更低效；没有原始 usage blocks	首轮约 3.3 万与后续缓存读成本不是同一件事
Subagent 编排	记录每个 subagent 是否复制系统提示、工具 schema 与 repo 快照	多条 HN 评论认为 subagent 会重复消耗上下文	并发 agent 可能把一次固定开销乘以 N
遥测与快照	区分 measurement usage blocks、上下文 snapshot、compact buffer 与实际 prompt	作者称记录 usage blocks；未见完整 request/response	telemetry 是观测口径，snapshot 才可能是真上下文成本

这张表说明了为什么“发送了多少 tokens”不是一个天然清楚的指标。对用户账单有意义的，是 provider 计费口径下的 input/cache/output；对系统优化有意义的，是 request payload 中每一段的归属；对产品比较有意义的，是同一任务成功率、延迟、用户干预次数和总成本的组合。只拿一个首轮输入 token 数字，很容易把“工具更笨”“工具更谨慎”“工具更完整”“cache 没命中”“gateway 太厚”混成一个结论。

官方来源只能证明产品形态

OpenCode 官方 README 把自己描述为 “The open source AI coding agent”，并说明有两个内置 agent：默认的 build agent 和只读的 plan agent，另有用于复杂搜索和多步任务的 general subagent。这个来源能证明 OpenCode 是一个带 agent 编排的开源编码工具，也能证明它不是一个只有 bare prompt 的极简 wrapper；但它不能证明 OpenCode 在 Systima 测试里只发送 7000 tokens。

Claude Code 官方文档 Overview 的页面描述则写得更直接：Claude Code 是一个 agentic coding tool，可以读取代码库、编辑文件、运行命令，并与开发工具集成，入口包括 terminal、IDE、desktop app 和 browser。npm 包 @anthropic-ai/claude-code 的 npm view 返回版本 2.1.207，描述为可以在终端使用 Claude、理解代码库、编辑文件、运行终端命令并处理 workflow。它们能证明 Claude Code 的产品形态确实比单次聊天复杂，但同样不能证明“发送约 3.3 万 tokens”这个数字。

这正是低置信写作的边界：官方文档确认“这类工具需要带工具、权限和工作流上下文”；HN 讨论确认“社区正在质疑这些上下文是否过厚”；Systima 原文已经恢复，但实验仍是单源材料。把这三层合起来，可以讨论“隐性上下文成本”这个趋势，不能直接宣判 Claude Code 与 OpenCode 的通用差距。

要怎样复现实验才算过关

一个足够干净的复现实验需要至少四组对照。第一组是 bare request：同一模型、同一 endpoint、没有 coding harness，只发一个空任务或固定短 prompt，确认 provider 与 gateway baseline。第二组是 harness 首轮 request：打开 Claude Code 或 OpenCode，但不让它读 repo、不启用 MCP、不启用自定义 memory，记录首轮 payload。第三组是真实 repo request：固定一个公开仓库、固定 task、固定工具权限，记录系统提示、工具 schema、repo snapshot、user prompt、assistant/tool messages。第四组是长程任务：允许 tool calls、subagents 和 compaction，报告总 input/cache/output 与成功率。

每一组都要同时给出三类材料：原始 request/response 的脱敏样本，provider usage block 的原文，和 tokenizer 复算脚本。只给 usage block 不够，因为不知道哪些 token 属于工具自身；只给 request body 不够，因为不知道 cache 如何计费；只给总价不够，因为不同模型价格和 subscription 规则会把同一个 token 数字映射到不同账单。

这里还有一个容易被忽略的质量维度。高上下文成本不一定是坏事：更多工具说明可能减少误操作，更多 repo snapshot 可能提高首次修复成功率，更多规则文件可能让 agent 更符合团队规范。低上下文成本也不一定是好事：极简 harness 可能便宜，但需要用户手动补上下文，或者在复杂任务上失败率更高。可比较的指标应该是“完成同一任务的总成本”，而不是“读 prompt 前第一包有多大”。

接下来看什么

第一，看 Systima 是否公开可复现材料。最重要的不是标题数字，而是 Claude Code 和 OpenCode 的具体版本、模型、任务、是否启用 extended thinking、是否启用 MCP、是否使用同一个 repo、gateway envelope 如何扣除、usage block 原文是什么。

第二，看作者是否兑现 HN 评论里的补充承诺。更深入任务、质量对比、inputs/outputs 复现材料，决定这篇文章能否从“成本吐槽”升级为“可复核 benchmark”。如果补充材料仍然只给总 token，不给任务成功率，这组数字的解释力仍然很弱。

第三，看是否出现独立复现。理想复现应同时覆盖无 gateway 与有 gateway 两条路径，并用同一模型、同一公开仓库、同一任务跑 Claude Code、OpenCode 和一个极简 harness。只有这样，才能分清预提示、工具说明、上下文快照、遥测/usage 口径和 agent 策略本身各自贡献了多少成本。

第四，看 Claude Code 与 OpenCode 是否在产品层面提供上下文预算 UI。HN 评论里有人提到 /context 能看到 system prompt、system tools、skills、compact buffer 等分类，这类可见性会变成用户信任的基础设施。未来 agent 工具如果只显示总 tokens，而不解释 tokens 从哪里来，成本争议会反复出现。

所以这条新闻的结论应保持克制：约 3.3 万 vs 7000 tokens 来自 Systima 单源测试，仍待独立复现。但“Coding Agent 在用户 prompt 前的隐性上下文成本需要被拆账”这个问题本身成立，而且值得持续跟踪。