缓存命中率多少算正常：各 AI 编程客户端实测
按 2026-09-29 这一周的实测，用 Claude 模型时，主流 AI 编程客户端连续对话的缓存命中率都在 88%–97%，Codex 用 GPT 约 96%。客户端之间差别很小；你的命中率明显更低时，原因多半在换号、间隔超过 5 分钟和新对话。
数据周：2026-09-29 – 2026-10-05（UTC）
关键结论
- Claude 模型的正常值: 88%–97%, 7 个客户端连续对话的中位数
- Codex 用 GPT: 96.0%, 38 个用户的中位数
- 最常见的未命中原因: 换上游账号, Claude Code × Claude 未命中的 37%
- 已发布的组合: 10, 客户端 × 模型，每格至少 5 个达标用户
各客户端的缓存命中率多少算正常
连续对话命中率只看"同一对话、同一模型、同一上游账号、上一条结束后 5 分钟内"的请求，反映客户端本身能做到多好。全部请求的命中率还包括换号、过期和新对话，和你在账单上看到的接近。
| 客户端 × 模型 | 连续对话命中率 | 全部请求 | 达标用户 |
|---|---|---|---|
| Codex × Claude | 97.1% (93.3%–99.4%) | 92.8% | 7 |
| Claude Code × Claude | 96.8% (94.9%–98.1%) | 90.9% | 120 |
| Codex × Doubao | 96.6% (95.0%–96.8%) | 95.3% | 16 |
| OpenCode × Claude | 96.5% (94.4%–97.5%) | 90.3% | 7 |
| Magpie × Claude | 96.5% (72.3%–98.4%) | 61.6% | 8 |
| Codex × GPT | 96.0% (93.1%–97.2%) | 93.6% | 38 |
| DeepSeek Harness × Claude | 95.6% (93.2%–96.8%) | 87.7% | 7 |
| pi × Claude | 95.1% (93.1%–98.5%) | 82.0% | 9 |
| Z Code × Claude | 88.3% (31.7%–92.0%) | 77.2% | 5 |
| pi × GPT | 68.3% (55.5%–78.5%) | 68.3% | 7 |
采样中
- Claude Code × DeepSeek: 采样中：4/5 个达标用户（本周共 6 个用户）
- WorkBuddy × Claude: 采样中：4/5 个达标用户（本周共 5 个用户）
- Z Code × GPT: 采样中：4/5 个达标用户（本周共 4 个用户）
- Claude Code × GPT: 采样中：3/5 个达标用户（本周共 8 个用户）
- Codex × DeepSeek: 采样中：3/5 个达标用户（本周共 5 个用户）
- pi × DeepSeek: 采样中：3/5 个达标用户（本周共 5 个用户）
- DeepSeek Harness × GPT: 采样中：2/5 个达标用户（本周共 5 个用户）
- OpenCode × GPT: 采样中：1/5 个达标用户（本周共 4 个用户）
为什么缓存命中率低：各客户端的未命中原因
- Claude Code × Claude: 被路由到另一个上游账号或端点 37%, 连续对话里的新增内容和前缀变化 22%, 并行请求（上一条还没结束） 15%
- Codex × GPT: 连续对话里的新增内容和前缀变化 73%, 新对话，或闲置超过 1 小时 11%, 被路由到另一个上游账号或端点 10%
- Codex × Doubao: 连续对话里的新增内容和前缀变化 69%, 并行请求（上一条还没结束） 10%, 被路由到另一个上游账号或端点 10%
- pi × Claude: 连续对话里的新增内容和前缀变化 37%, 间隔超过 5 分钟，缓存已过期 26%, 被路由到另一个上游账号或端点 18%
通过中转站使用时，命中率为什么更低
- 换账号：缓存属于上游账号，下一条被发到另一个账号就要整段重写。这是中转站最常见的原因，直连官方不会有。
- 协议转换：把 Anthropic 格式和 OpenAI 格式互相转换时，可能改动前缀或丢掉 cache_control 断点。
- 旧版 Claude Code（v2.1.181 之前）通过自定义 Base URL 时，系统提示开头的署名块每次带不同的 token，按请求体做缓存的网关会全部打不中；升级，或设 CLAUDE_CODE_ATTRIBUTION_HEADER=0。
- 自测：连续发两条前缀相同、超过最小缓存长度的请求，第二条的缓存读取应接近前缀长度。
Wokey 优先把同一对话的后续请求发往同一上游账号。2026-10-04 至 2026-10-10，Wokey 普通用户在 Claude Opus 5.5 上全部请求的命中率为 92.8%，同期 OpenRouter 整体为 87.8%。
怎么测的
- 数据来自 Wokey 网关上真实用户的请求，每周一 05:00 UTC 统计上一周（周一至周日）。
- 客户端按请求的 User-Agent 识别。SDK、HTTP 库和下游中转发来的请求看不出真实客户端，不计入；企业客户不计入。
- 连续轮次：和同一对话的上一条请求同模型、同上游账号，且在其结束后 5 分钟内发出。每个用户的命中率 = 连续轮次的缓存读取 ÷ 输入（输入含缓存读写），取一周至少 20 个连续轮次的用户的中位数。
- 每格至少 5 个达标用户才发布；和上周相比变化超过 3 个百分点时，先人工核对再发布。
- 已知偏差：只覆盖 Wokey 用户；不同用户的使用习惯差别很大；全部请求的命中率里包含网关自身的路由损失（见"被路由到另一个上游账号"一项）。
常见问题
缓存命中率多少算正常？
用 Claude 模型的连续对话里，主流客户端的中位数在 88%–97%；把换号、过期、新对话都算上，全部请求的命中率通常比这低几个百分点。低于 90% 基本可以确定不是客户端本身的问题。
缓存命中是什么意思？缓存命中和缓存未命中有什么区别？
提示缓存会保存请求开头那段不变的内容（系统提示、工具定义、之前的对话）。下一条请求开头相同时，这一段直接从缓存读取，叫缓存命中，按输入价的一小部分计费；开头不同或缓存已过期，就要重新完整处理，叫缓存未命中，通常还会顺便写入缓存。
缓存命中率高好还是低好？
越高越好。命中的部分按输入价的 0.1 倍左右计费（部分新模型更低），首字也更快；用 Claude 订阅时，缓存读取几乎不占额度。
为什么我的缓存命中率很低？
最常见的原因依次是：请求被路由到另一个上游账号（中转站常见）、两次请求间隔超过 5 分钟导致缓存过期、子代理等并行请求、换模型，以及新对话。每个客户端页面按实测占比列出了原因和对应的做法。
不同客户端的缓存命中率差别大吗？
不大。同一模型下，Claude Code、pi、OpenCode 等客户端连续对话的命中率只差几个百分点。差别更多来自模型厂商：OpenAI 的缓存要求整个前缀一致，Codex 用 GPT 的命中率比 Claude 系客户端低几个点。
中转站的缓存命中率为什么低？
缓存属于上游账号。中转站把同一对话的请求分散到多个账号，或在协议转换时改动了前缀，缓存就会反复重写。可以连续发两条前缀相同的请求，看第二条的缓存读取是否接近前缀长度来自测。
缓存命中率低会更快用完 Claude 订阅额度吗？
会。按我们对 Claude 订阅额度的实测，缓存读取几乎不占额度，缓存写入和未缓存输入占用的额度差不多。同一段上下文命中时几乎不花额度，没命中就要整段重新计入。各档额度见 Claude 订阅额度实测页（/claude-usage-limits）。
缓存命中率怎么算？
缓存读取 token ÷ 输入 token，输入包括未缓存输入、缓存写入和缓存读取。Anthropic 格式看 cache_read_input_tokens，OpenAI 格式看 cached_tokens。
为什么 Cline、Roo Code、Cursor 等不在表里？
每格要有至少 5 个一周内连续轮次足够多的用户才发布。Cursor 的自带密钥请求从 Cursor 的服务器发出，网关看不到；SDK 和中转发来的请求也识别不出真实客户端。