Codex 快取命中率實測

重點結論

• 正常值: 94.8%, 71 位使用者連續對話的中位數，中間一半在 91.2%–96.9%
• 全部請求: 91.8%, 含換帳號、過期、新對話等全部未命中
• 最大的未命中原因: 連續對話中的新內容, 占未命中的 57%
• 各形態之間: 相差 4.6 個點, 桌面應用程式、終端介面、codex exec（非互動）

各用戶端的快取命中率多少算正常

資料週：2026-11-03 – 2026-11-09（UTC）

• 連續對話命中率（使用者中位數）: 94.8%
• 中間一半使用者: 91.2%–96.9%
• 達標使用者: 71 (一週至少 20 個連續輪次)
• 全部請求的命中率: 91.8%

Codex 各形態的命中率

同一用戶端的命令列、IDE 擴充功能和桌面應用程式送出的請求幾乎相同，命中率也應該接近。

• 桌面應用程式: 95.3% (55)
• 終端介面: 95.8% (11)
• codex exec（非互動）: 91.2% (9)

Codex 各版本的命中率

某個版本改動了請求前綴時，它的命中率會明顯低於其他版本；這張表在出問題的那一週就看得出來。

• 0.167.0-alpha.3.2: 95.0% (27)
• 0.167.0: 93.3% (6)
• 0.166.0-alpha.6: 95.6% (29)
• 0.166.0-alpha.5.1: 96.4% (28)
• 0.166.0: 96.6% (5)

每週中位數

• 2026-09-29: 96.0% (38 位使用者)
• 2026-10-06: 95.3% (54 位使用者)
• 2026-10-13: 95.4% (62 位使用者)
• 2026-10-20: 95.8% (49 位使用者)
• 2026-10-27: 95.1% (72 位使用者)
• 2026-11-03: 94.8% (71 位使用者)

為什麼 Codex 快取命中率低：未命中原因拆解

本週全部輸入裡有 8.2% 沒有從快取讀取。以下按原因拆開，每一類都列出可以做的事。

連續對話中的新增內容與前綴變化: 占未命中的 57%, 約占全部輸入 4.7%

OpenAI 的快取要求整個前綴一致。工作階段中途切換推理強度（reasoning effort）、工具、輸出格式，或 Codex 自動壓縮歷史（compaction），都會讓前綴改變。這是 Codex 未命中的最大來源。

被路由到另一個上游帳號或端點: 占未命中的 19%, 約占全部輸入 1.6%

提示快取存放在處理請求的那個上游帳號裡。Relay 或多帳號閘道把同一對話的下一筆請求送到另一個帳號時，整段上下文都要重新寫入。直接連線官方不會出現這一項。

新對話，或閒置超過 1 小時: 占未命中的 16%, 約占全部輸入 1.3%

新對話的第一筆請求，或閒置 1 小時後的請求，都只能重新寫入快取。

換了模型: 占未命中的 3%, 約占全部輸入 0.3%

每個模型有獨立的快取，換模型後的第一筆請求要重新讀入整段歷史。

間隔超過 5 分鐘，快取已過期: 占未命中的 3%, 約占全部輸入 0.2%

GPT-5.6 及之後的模型快取預設保留 30 分鐘，從最近一次寫入或重複使用算起；更早的模型通常閒置 5–10 分鐘後就會失效。

平行請求（上一筆還沒結束）: 占未命中的 2%, 約占全部輸入 0.2%

上一筆請求還沒結束就送出下一筆（子代理、平行工具呼叫），後一筆讀不到前一筆正在寫入的快取。

Codex 快取多久失效（TTL）、怎麼收費

• OpenAI 自動快取提示前綴，不需要用戶端設定斷點；GPT-5.6 及之後的模型從 1,024 token 起快取。
• GPT-5.6 及之後：預設保留 30 分鐘，從最近一次寫入或重複使用算起。更早的模型：記憶體快取通常在閒置 5–10 分鐘後失效，最長 1 小時；部分模型支援 24 小時保留。
• 快取讀取一般按輸入價的 0.1 倍計費，GPT-6.1 Sol 是 0.05 倍；GPT-5.6 及之後的模型對快取寫入收輸入價的 1.25 倍。
• Codex 把工作階段 ID 當作 prompt_cache_key 送出（以原始碼為準），同一工作階段的請求會被送往同一份快取。

OpenAI 提示快取文件 · OpenAI 快取未命中診斷 · Codex 原始碼（prompt_cache_key） · Codex issue #35416：切換推理強度導致未命中

如何查看 Codex 的快取命中率

• Codex CLI 結束時會印出本次工作階段的 token 用量，括號裡的 "+ N cached" 就是從快取讀取的輸入（目前版本的行為，官方文件未寫）。
• 自己算：usage.input_tokens_details.cached_tokens ÷ usage.input_tokens；GPT-5.6 及之後的模型還會回傳快取寫入數。
• OpenTelemetry 指標 turn.token_usage 裡有 cached_input 類型。
• 透過 Wokey 使用時，主控台的請求明細裡每筆請求都有快取讀取和快取寫入兩欄。

OpenAI 快取未命中診斷

透過 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%。

對比 OpenRouter 的快取命中率 · 即時資料：Wokey 公開快取命中率 API（近 7 天）

怎麼測的

• 資料來自 Wokey 閘道上真實使用者的請求，每週一 05:00 UTC 統計上一週（週一至週日）。
• 用戶端依請求的 User-Agent 辨識。SDK、HTTP 函式庫和下游 Relay 送來的請求看不出真實用戶端，不列入；企業客戶也不列入。
• 連續輪次：和同一對話的上一筆請求同模型、同上游帳號，且在其結束後 5 分鐘內送出。每位使用者的命中率 = 連續輪次的快取讀取 ÷ 輸入（輸入含快取讀寫），取一週至少 20 個連續輪次的使用者的中位數。
• 每格至少 5 位達標使用者才發布；和上週相比變化超過 3 個百分點時，先人工核對再發布。
• 已知偏差：只涵蓋 Wokey 使用者；不同使用者的使用習慣差別很大；全部請求的命中率包含閘道自身的路由損失（見「被路由到另一個上游帳號」一項）。

常見問題