10 怎么判断自己有没有被缓存坑到

前面讲了很多机制。真正落到使用上，不要一上来就问“它有没有缓存”。这个问题太粗。

更准确的问法是三层：有没有产生缓存字段，缓存字段有没有进入账单，账单有没有按缓存价格计算。

第一步，看接口返回。

具体字段前面已经讲过，这里不用再背一遍。关键是看它有没有把普通输入、缓存写入、缓存读取分开。

如果接口只返回一个总 input token，这条链路就已经少了一半信息。它可能真的没缓存，也可能缓存了但没透传。光靠总 token，判断不出来。

第二步，看账单口径。

接口里有缓存字段，不代表账单也按缓存算。很多平台会在 API 返回里保留 usage，但后台计费仍然只按总输入乘单价。

这时候要看账单有没有区分普通输入、缓存写入、缓存读取，或者至少有没有说明 cached input 的计费方式。

如果账单只写“输入 token 多少，单价多少”，那缓存收益到底给了谁，用户还是看不出来。

第三步，看连续会话里的比例。

不要拿完全不同的请求去比。缓存本来就依赖前缀复用。比较有意义的场景，是同一个项目、同一个任务、同一个会话里，前面大段上下文基本不变，只在最后追加新问题。

这时再看缓存字段的变化。

正常情况下，第二轮、第三轮应该逐渐出现更多缓存读取，普通输入占比下降。如果每一轮都是大量普通输入，缓存读取几乎没有，就要怀疑前缀被打断了。

但这里要注意，不能把一次测试看得太死。

不同供应商的缓存 TTL、最小 token 门槛、写入时机都不同。DeepSeek 还有缓存构建延迟。中转站也可能有账单刷新延迟。一次没命中，不等于一定有问题；连续多轮都看不到缓存痕迹，才值得追。

这里还要留一个后面统一处理的点：有些 Agent 工具为了维持 5 分钟缓存，可能会产生很小的保活请求。如果后台请求记录里能看到这类请求，它也要算进成本。这个问题和 TTL 选择、Claude Code 行为更相关，后面顺稿时放回前面的 TTL 或 Claude Code 章节，不在这里展开。

第四步，看动态内容有没有打断前缀。

如果你在用 Agent 工具，先别急着怪模型。很多缓存失效来自请求组织方式。

比如每轮都把当前时间、git 状态、任务进度放在很前面；每轮都重新生成 tool schema；MCP 工具列表顺序不稳定；测试日志、网页正文、搜索结果长期挂在历史里。这些都会影响前缀复用。

这类问题在 Claude Code、OpenCode、Hermes、OpenClaw 里都可能出现，只是暴露程度不同。

第五步，看中转站有没有改写或打散请求。

同一个 base url、同一个 key、同一个模型名，不代表上游缓存位置稳定。中转站可能在多个账号、workspace、region 或备用渠道之间调度。它也可能插入自己的 system prompt，或者为了兼容格式重排 messages。

如果用户侧请求稳定，但 usage 里长期看不到缓存收益，就要把中转站也纳入排查，不能只盯着模型本身。

第六步，别只看总价。

总价便宜，有可能是模型本来便宜；总价贵，也可能是输出 token 多。缓存主要影响输入侧，尤其是重复长前缀。判断缓存问题，要看输入里的普通部分和缓存部分，不能只看最终花了多少钱。

对个人用户来说，最有用的是三类信息：接口 usage、平台账单、请求间隔。

对团队来说，还要再加几类：key、项目、用户、模型、base url、workspace、region。如果平台不能导出这些维度，后面排查会很难。

所以判断自己有没有被缓存坑到，不能指望一个测试一次说清。

更靠谱的做法，是把每一轮请求当成一条账本记录：用了哪个模型，走了哪条链路，输入里多少是普通输入，多少是缓存输入，账单又按什么口径收钱。

只要这条账本断了，用户就只能看平台给出的总价。总价本身解释不了缓存。