draft · 仅 crs13 预览环境显示，正式站不会发布

00 开场：一句“继续”，也可能消耗大量输入额度

我第一次认真看 Claude Code 的用量，是因为它贵得有点离谱。

明明只是让它“继续改”“再跑一下测试”“把刚才那个报错修掉”，输入框里就几个字。可消耗的额度还是让钱包有点受不了。

问题出在请求内容本身。

对 coding agent 来说，“继续”这两个字通常不会单独发送给模型。一次真实请求里，前面往往还有系统提示词、工具定义、项目规则、当前目录、历史对话、刚读过的文件、刚跑出来的测试结果，有时候还会带上一整套 MCP tool schema。

换到接口层看，用户新增输入只占最后一小段。真正占 token 的，常常是前面那批重复上下文。

如果这段重复输入命中缓存，后面几轮会便宜很多。比如 Claude 的 cache read，价格可以低到普通输入的十分之一。可如果没命中，每一轮都可能按普通输入重新计费。

这也是 LLM 缓存容易被低估的地方。

很多人把它当成厂商文档里的一个底层优化，或者 usage 里的几个字段。到了 Agent 场景，缓存命中率会直接改变成本结构。同样是十万 token 的上下文，一轮按 cached input 读取，另一轮按普通 input 计费，账单差异会非常明显。

这件事还很难只靠用户自己判断。

模型厂商有没有命中缓存，Agent 框架有没有在前缀里加入动态内容，中转站有没有把 cached input 按普通 input 收费，同一会话有没有被路由到不同 key、workspace 或 region，都会影响最后的调用成本。

如果只看模型单价，很容易漏掉真正影响长会话成本的部分。Claude、OpenAI、DeepSeek 的标价只能说明一层问题。每一轮输入里有多少重复内容、重复内容有没有命中缓存、命中之后有没有体现在账单里，才是 Agent 成本里更关键的部分。

这篇文章就从这笔账开始拆。

先讲缓存到底缓存了什么，再看 Claude、OpenAI、DeepSeek 的规则差异；然后回到 Claude Code、OpenCode、Hermes、OpenClaw 这些 Agent 工具，分析它们为什么容易出现缓存命中率波动；最后再看中转站和模型网关里更敏感的一层：缓存省下来的钱，最后有没有算给用户。