命中率的问题很简单：它是一个百分比，分母是你的总 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 ，可以看看自己的缓存未命中是多少。
