快取命中率多少算正常：各 AI 程式設計用戶端實測
依 2026-11-03 這一週的實測，使用 Claude 模型時，主流 AI 程式設計用戶端連續對話的快取命中率都在 95%–98%，Codex 用 GPT 約 95%。用戶端之間差別很小；你的命中率明顯更低時，原因多半是換帳號、間隔超過 5 分鐘和新對話。
資料週：2026-11-03 – 2026-11-09（UTC）
重點結論
- Claude 模型的正常值: 95%–98%, 7 個用戶端連續對話的中位數
- Codex 用 GPT: 94.8%, 71 位使用者的中位數
- 最常見的未命中原因: 快取過期, Claude Code × Claude 未命中的 37%
- 已發布的組合: 20, 用戶端 × 模型，每格至少 5 位達標使用者
各用戶端的快取命中率多少算正常
連續對話命中率只計算「同一對話、同一模型、同一上游帳號、上一筆結束後 5 分鐘內」送出的請求，反映用戶端本身能做到多好。全部請求的命中率還包含換帳號、過期和新對話，和你在帳單上看到的比較接近。
| 用戶端 × 模型 | 連續對話命中率 | 全部請求 | 使用者 |
|---|---|---|---|
| Z Code × Claude | 98.5% (97.7%–99.0%) | 94.3% | 13 |
| Magpie × DeepSeek | 98.3% (95.6%–98.8%) | 91.4% | 7 |
| DeepSeek Harness × DeepSeek | 98.2% (96.6%–98.9%) | 94.8% | 27 |
| Magpie × Claude | 98.2% (97.0%–98.8%) | 93.6% | 25 |
| OpenCode × DeepSeek | 98.2% (92.2%–98.5%) | 97.7% | 8 |
| Claude Code × Claude | 98.1% (96.9%–98.8%) | 94.6% | 343 |
| WorkBuddy × Claude | 97.8% (96.6%–98.3%) | 88.2% | 20 |
| OpenCode × Claude | 97.6% (97.1%–98.9%) | 95.1% | 20 |
| Claude Code × DeepSeek | 97.5% (95.6%–98.8%) | 96.5% | 12 |
| DeepSeek Harness × Claude | 97.2% (93.6%–98.0%) | 92.0% | 38 |
| Codex × DeepSeek | 96.9% (95.4%–98.3%) | 97.2% | 12 |
| WorkBuddy × GPT | 96.4% (91.4%–97.4%) | 92.4% | 10 |
| DeepSeek Harness × Kimi | 96.4% (95.3%–97.4%) | 93.9% | 6 |
| Codex × GPT | 94.8% (91.2%–96.9%) | 91.8% | 71 |
| Codex × Claude | 94.7% (87.0%–97.8%) | 93.5% | 21 |
| OpenCode × GPT | 94.6% (90.8%–96.2%) | 90.8% | 11 |
| Magpie × GPT | 94.3% (91.5%–95.5%) | 87.0% | 7 |
| DeepSeek Harness × GPT | 93.9% (92.5%–96.3%) | 91.9% | 11 |
| DeepSeek Harness × Other | 90.3% (88.4%–94.2%) | 80.8% | 5 |
| Claude Code × GPT | 78.8% (78.6%–94.4%) | 77.4% | 5 |
採樣中
- OpenCode × Other: 採樣中：4/5 位達標使用者（本週共 9 位使用者）
- pi × Claude: 採樣中：4/5 位達標使用者（本週共 7 位使用者）
- Claude Code × GLM: 採樣中：4/5 位達標使用者（本週共 7 位使用者）
- Magpie × Kimi: 採樣中：4/5 位達標使用者（本週共 4 位使用者）
- WorkBuddy × Kimi: 採樣中：3/5 位達標使用者（本週共 4 位使用者）
- DeepSeek Harness × Grok: 採樣中：3/5 位達標使用者（本週共 3 位使用者）
- Claude Code × Other: 採樣中：2/5 位達標使用者（本週共 5 位使用者）
- WorkBuddy × DeepSeek: 採樣中：2/5 位達標使用者（本週共 5 位使用者）
為什麼快取命中率低：各用戶端的未命中原因
- Claude Code × Claude: 間隔超過 5 分鐘，快取已過期 37%, 連續對話中的新增內容與前綴變化 23%, 新對話，或閒置超過 1 小時 17%
- Codex × GPT: 連續對話中的新增內容與前綴變化 57%, 被路由到另一個上游帳號或端點 19%, 新對話，或閒置超過 1 小時 16%
- DeepSeek Harness × Claude: 連續對話中的新增內容與前綴變化 48%, 間隔超過 5 分鐘，快取已過期 32%, 新對話，或閒置超過 1 小時 16%
- DeepSeek Harness × DeepSeek: 被路由到另一個上游帳號或端點 44%, 連續對話中的新增內容與前綴變化 30%, 新對話，或閒置超過 1 小時 22%
透過 Relay 使用時，命中率為什麼較低
- 換帳號：快取屬於上游帳號，下一筆被送到另一個帳號就要整段重寫。這是 Relay 最常見的原因，直接連線官方不會有。
- 協定轉換：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 函式庫和下游 Relay 送來的請求看不出真實用戶端，不列入；企業客戶也不列入。
- 連續輪次：和同一對話的上一筆請求同模型、同上游帳號，且在其結束後 5 分鐘內送出。每位使用者的命中率 = 連續輪次的快取讀取 ÷ 輸入（輸入含快取讀寫），取一週至少 20 個連續輪次的使用者的中位數。
- 每格至少 5 位達標使用者才發布；和上週相比變化超過 3 個百分點時，先人工核對再發布。
- 已知偏差：只涵蓋 Wokey 使用者；不同使用者的使用習慣差別很大；全部請求的命中率包含閘道自身的路由損失（見「被路由到另一個上游帳號」一項）。
常見問題
快取命中率多少算正常？
使用 Claude 模型的連續對話裡，主流用戶端的使用者中位數在 95%–98%；把換帳號、過期、新對話都算上，全部請求的命中率通常比這低幾個百分點。低於 90% 時，原因很少是用戶端本身。
快取命中是什麼意思？快取命中和快取未命中有什麼差別？
提示快取會保存請求開頭那段不變的內容（系統提示、工具定義、之前的對話）。下一筆請求開頭相同時，這一段直接從快取讀取，稱為快取命中，按輸入價的一小部分計費；開頭不同或快取已過期，就要重新完整處理，稱為快取未命中，通常還會順便寫入快取。
快取命中率高比較好還是低比較好？
越高越好。命中的部分按輸入價的 0.1 倍左右計費（部分新模型更低），首字也更快；使用 Claude 訂閱時，快取讀取幾乎不占額度。
為什麼我的快取命中率很低？
最常見的原因依序是：請求被路由到另一個上游帳號（Relay 常見）、兩次請求間隔超過 5 分鐘導致快取過期、子代理等平行請求、換模型，以及新對話。每個用戶端頁面都依實測占比列出原因和對應的做法。
不同用戶端的快取命中率差別大嗎？
不大。同一模型下，Claude Code、pi、OpenCode 等用戶端連續對話的命中率只差幾個百分點。差別更多來自模型廠商：OpenAI 的快取要求整個前綴一致，Codex 用 GPT 的命中率比 Claude 系用戶端低幾個點。
Relay 的快取命中率為什麼比較低？
快取屬於上游帳號。Relay 把同一對話的請求分散到多個帳號，或在協定轉換時改動了前綴，快取就會反覆重寫。可以連續送出兩筆前綴相同的請求，看第二筆的快取讀取是否接近前綴長度來自我測試。
快取命中率低會更快用完 Claude 訂閱額度嗎？
會。依我們對 Claude 訂閱額度的實測，快取讀取幾乎不占額度，快取寫入則和未快取的輸入占用差不多。同一段上下文命中時幾乎不花額度，沒命中就要整段重新計入。各方案額度見 Claude 用量限制實測頁（/claude-usage-limits）。
快取命中率怎麼算？
快取讀取 token ÷ 輸入 token，輸入包含未快取輸入、快取寫入和快取讀取。Anthropic 格式看 cache_read_input_tokens，OpenAI 格式看 cached_tokens。
為什麼 Cline、Roo Code、Cursor 等不在表裡？
每格要有至少 5 位一週內連續輪次足夠多的使用者才發布。Cursor 自帶金鑰的請求從 Cursor 的伺服器送出，閘道看不到用戶端；SDK 和 Relay 送來的請求也辨識不出真實用戶端。