Coding Agent Token Overhead 横向对比
Codex 核验（2026-10-09）：表中 system prompt 数字与用户评论来自 7 月采样，受版本、工具、MCP 配置和统计口径影响，本次未复现实测。Claude 官方缓存文档说明缓存命中仍有读取费用；API 计费与订阅额度不能等同。Databricks的三分之一上下文结论限于其内部实验。
来源: HN 178pts | systima.ai 测量方法: mitmproxy 线路级分析
核心发现
Coding Agent 的初始 system prompt + tool schema 差异巨大：
| Agent | System Prompt | 备注 |
|---|---|---|
| Claude Code | ~33k tokens | 含大量工具定义、命令、MCP 配置 |
| OpenCode | ~7k tokens | 更精简，约 Claude Code 的 1/5 |
| Pi (earendil-works/pi) | ~1k tokens | 极简设计 |
| Maki | < 1k | 最轻量 |
一个用户实测 Claude Code 完整初始 JSON 载荷（含工具定义、MCP 配置）高达 162k tokens。
关键讨论点
1. 利益冲突
Anthropic 是 token 商人，有动机让 Claude Code 消耗更多 token。多位 HN 用户指出这是”咨询师 bill 你读邮件的时间”。
2. Sub-agent 爆炸
一个用户报告 Claude Code 对一个大任务启动了 7 个 sub-agent，每个 sub-agent 都发送相同的 ~30k system prompt，在开始工作前就烧掉了预算。 建议: 强制 sub-agent 使用 Haiku 等低成本模型。
3. Tokenflation
简单请求如 “Hey” 或 “commit” 触发 30+ 次工具调用。轻量 harness 对简单任务便宜一个数量级。
4. 缓存抵消争议
部分用户认为 prompt caching 可降低重复前缀成本；缓存命中仍计费，并且受前缀匹配、有效期和缓存写入影响。不能说 33k 只影响第一次调用，也不能据 API 单价推断订阅额度。
5. 解决方案
- 用
--system-prompt ""清空 Claude Code 默认 prompt - 换用 OpenCode/Pi/Hermes 等开放 harness
- Agent harness decoupling — 模型提供商不应同时控制 harness
对 Hermes 的启示
- 对比基准：Hermes 自己的 token 使用应对比这些 benchmark
- 上下文压缩：考虑为 coding agent lane 实现上下文压缩（类似 headroom）
- Sub-agent 低成本模型默认：Sub-agent 设计应默认使用低成本模型
- 参考基线：OpenCode 的 7k 是很好的参考基线
横向连接
- geohot 用 opencode + GLM-5.2 (colibri) 实现了本地免费运行
- Databricks 的内部实验报告 Pi 每轮上下文约为 Claude Code 的 1/3，未证明所有配置均有该比例
- 共同趋势：Agent harness decoupling + token 效率成为竞争焦点
优先级
🟡 P1 — 直接对比 Hermes 当前 token 开销并优化