Claude Code 在读取提示前发送 3.3 万 tokens；OpenCode 发送 7 千

原文 ↗ Hacker News 讨论 ↗

AI 编码助手（如 Anthropic 的 Claude Code）因在读取用户请求之前就发送数万“开销”tokens——系统提示、工具描述和 subagent 初始化——而受到批评，相比 OpenCode 或 Pi 等更轻量的 harness，这会显著抬高成本。评论者认为，这种 token 膨胀被工具和 subagent 的激进使用进一步放大，而且当模型提供方同时控制花费 tokens 的 agent 时，可能存在利益冲突。许多开发者正在通过自建轻量 agent、裁剪上下文，或切换到更透明、更可控且更具成本效益的替代 harness 和模型来应对。

Token 开销与 harness 设计

  • 许多人提到 Claude Code 的大型系统提示和工具描述（数以万计的 tokens）与 OpenCode 更小的负载形成对比；Pi 和一些极简 CLI 甚至更轻量。
  • 有人认为原始提示大小并不是合适的衡量标准：真正重要的是智能 × 成本 × 时间，以及整体任务完成情况。
  • 也有人反驳说，“tokenflation” 确实存在：看似简单的任务随着时间推移会消耗越来越多的 tokens。

Subagents 与失控成本

  • Subagents 一再被提及为最大的 token 黑洞：用户报告任务会生成数十甚至数百个 subagent，很快耗尽额度。
  • 一些人通过设置、权限或系统指令禁用或严格限制 subagent，发现顺序单代理工作流更便宜，而且质量往往并不更差。
  • 也有人选择性地使用 subagent（例如，用更便宜的模型做探索、用专门的审查器），并在精心编排时发现其价值。

缓存、裁剪与技术细节

  • 有人指出，大型静态前缀应该能命中提供方的 KV 缓存，并且计费更便宜，甚至在订阅中免费，从而在首次调用后降低实际成本。
  • 也有人提到缓存 TTL 很短（5 分钟到 1 小时）且行为不透明，因此节省效果很脆弱。
  • 上下文裁剪工具（例如 Dynamic Context Pruning / Sleev）引发怀疑：它们可能减少 tokens，但也有削弱能力并破坏缓存的风险；透明度不足也是一个担忧。

成本模型与激励

  • 关于激励的争论很激烈：
    • 一方声称 Anthropic 在“最大化 token”，尤其是将固定费用订阅与自己的 harness 绑定，并让 Claude Code 变得冗长。
    • 另一方认为，竞争和 GPU 稀缺会推动所有人追求效率；浪费行为可能会把用户推向更便宜的模型（DeepSeek、开源模型等）。
  • 有一些数据点：用户看到类似工作流的假设 API 成本在数月间上升，尽管工作量相近。

替代 harness 与自建方案

  • 许多人称赞 OpenCode、Pi、Codex 以及极简自定义 harness（简单 REPL 或 50–200 行代码的 agent）更便宜、更可控，而且往往同样有效，甚至更有效。
  • Pi 被视为有意保持极简且可插拔；有些人很喜欢这一点，另一些人则觉得它在实践中过于简陋且依赖过多。
  • 一些人建议使用本地模型加自定义 harness，以避免供应商锁定，并准确观察到底发送了什么。

质量、UX 与不透明性

  • 对 Claude Code 质量的反馈不一：有人说它仍然是复杂并行工作的最先进编排器；另一些人觉得 OpenCode 或 Codex 更快、更清晰，也不那么“过度设计”。
  • 对 Claude Code 变得越来越不透明的抱怨：隐藏的思考 tokens、对工具使用的可见性降低，以及更多用户并未明确要求的自动行为（测试、审查、subagent）。
  • 一个常见模式出现了：人们最终会添加明确指令（例如，不要 subagent、对简单改动不要跑测试、最小化系统提示），以重新获得成本和行为控制。