「缓存命中率」是个伪指标，应该看未命中的缓存

[heimoshuiyu]

命中率的问题很简单：它是一个百分比，分母是你的总 token 数。上下文越短、新输入越多、子 agent 开得越多，命中率自然就越低——但这跟 provider 的缓存质量没关系，是你自己用得多。一个百分比把「你怎么用」和「 provider 缓存好不好」混在一起，根本看不出问题出在哪。

换成绝对值就清晰了：

未命中 = 上一条的总 token 数 − 这一条从缓存读回的 token 数

就是这一轮有多少 token 被白白重新处理了。理想情况是 0 ，值越大浪费越多，用户在为这些 token 付钱。要是这个值突然飙上去，说明缓存挂了——可能是有问题的插件打断了缓存，或者 provider 的缓存过期了。

跑了下自己 16 万条消息，发现不同模型差异巨大：DeepSeek-v4 有 85% 的对话连上一轮的输出都能缓存住，GLM-4.7 有 63%，但 GPT-5.5 只有 0.3%。vLLM 和 SGLang 本来就支持输出侧 KV 复用，那些不支持的模型纯粹是没开这个能力，用户的钱就这么烧了。

把这个指标做成了可视化看板，点击某天还能下钻到具体会话，看每条消息的缓存命中细节：



直接读 OpenCode 的 SQLite ，本地一个二进制就能跑。

GitHub: https://github.com/heimoshuiyu/opencode-token-dashboard

如果你也在用 OpenCode ，可以看看自己的缓存未命中是多少。

[bbbblue]

虽然和使用场景相关
但是和不同的 provider 也还是有关系的吧 一些三方中转号池轮训导致的失效就不提了 毕竟他们是三方中转

一些提供开源模型算力厂本身的缓存策略也不一样（触发阈值 缓存时间 过期机制） 导致他们的缓存命中率就差的多 or 上同样 glm5.2 有些就是 80+ 一些连 10%都不到（还有 0%的压根没缓存 😂

[winnerczwx]

这是 cc switch 统计的, codex 下 gpt5.5 缓存命中率有 92.7%, 你这个 0.3% 也太离谱了, 难道是 opencode 对 gpt 支持的不好?

[codehz]

gpt-5.5 只有 0.3 应该是你供应商的问题吧。。。这个比例怎么看都不对，我这用起来不说 90%，那起码 80%还是有的，就算子代理开爆也不至于<1%

[heimoshuiyu]

@winnerczwx 我指 gpt5.5 0.3% 是输出侧 token 存在缓存的概率。一次 API 调用包括输入 + 输出两个部分，调用完成后，deepseek 会将输入 + 输出缓存起来，而 gpt 只缓存到输入。因此用户实际上为输出 token 多付了一份输入未命中的钱。

92.7% 这个数值很难说明什么。平时使用的平均会话上下文偏长，这个数值很容易就能刷高。这也是我建议不要使用「缓存命中率」的原因。另外，ccswitch 存在消息重排序破坏缓存的草台 bug github.com/farion1231/cc-switch/issues/3934

[GeruzoniAnsasu]

缓存命中率是给 agent 开发者看的…… honestly

[utodea]

cache hit 并不特别代表什么, 会话拉长、prompt token 适当多费点，很容易拉高。 比如我这个： https://github.com/usewhale/whale 。 优化的时候 agent 开发者可以参考它， 但过低多少有点猫腻。

115 turns · $0.0841 · 98.8% cache · last prompt 94.7K · $2.8607 cache saved

[JackalZhao]

本应缓存命中的部分，给你按照未命中算的话，你的账单不炸了？

我们关注缓存命中率，实质上是关注价格虚标，有没有把命中的部分按照未命中计费。

[heimoshuiyu]

@JackalZhao 我认为 “输出侧 tokens” 属于本应缓存命中的部分，而多数 provider 没缓存。关注缓存命中率的话你看不出这个问题，看未命中 tokens 就能发现这个问题，如我图所示，每一次请求的未命中 tokens 都大于上一次请求的输出 tokens 。

另外，假如某个 provider 缓存临时故障，缓存命中率只会下降几个点，被使用习惯的噪声淹没。而未命中缓存指标会有一个非常显眼的凸起