OpenCode 快取命中率實測

重點結論

• 正常值: 97.6%, 20 位使用者連續對話的中位數，中間一半在 97.1%–98.9%
• 全部請求: 95.1%, 含換帳號、過期、新對話等全部未命中
• 最大的未命中原因: 新對話, 占未命中的 34%
• 各形態之間: 相差 0.6 個點, 桌面應用程式、命令列

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

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

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

OpenCode 各形態的命中率

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

• 桌面應用程式: 98.0% (7)
• 命令列: 97.4% (6)

OpenCode 各版本的命中率

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

• 2.2.5: 97.5% (10)

每週中位數

• 2026-09-29: 96.5% (7 位使用者)
• 2026-10-06: 97.6% (8 位使用者)
• 2026-10-13: 98.8% (11 位使用者)
• 2026-10-20: 97.4% (10 位使用者)
• 2026-10-27: 96.4% (13 位使用者)
• 2026-11-03: 97.6% (20 位使用者)

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

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

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

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

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

每一輪新增的內容第一次出現時只能寫入、不能讀取，這部分無法避免；系統提示、工具清單變更或歷史被改寫時，前綴也會失效。

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

兩次請求之間隔了 5 分鐘以上，上一次寫入的快取可能已經過期。

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

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

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

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

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

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

命中率差幾個點，帳單差好幾倍

以 Claude Opus 5.5 官方價格計算，未命中部分按 5 分鐘快取寫入計，每百萬輸入 token 的實際成本：

• 本週中位數 97.6%: $0.32 (×1.0)
• 90%: $0.68 (×2.1)
• 80%: $1.16 (×3.7)
• 50%: $2.60 (×8.2)

用 Claude API 費用試算依自己的用量計算

如何查看 OpenCode 的快取命中率

• Anthropic 格式：cache_read_input_tokens ÷（input_tokens + cache_read_input_tokens + cache_creation_input_tokens）。
• OpenAI 格式：cached_tokens（在 prompt_tokens_details 或 input_tokens_details 裡）÷ prompt_tokens / input_tokens。
• 透過 Wokey 使用時，主控台的請求明細裡每筆請求都有快取讀取和快取寫入兩欄。

透過 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 使用者；不同使用者的使用習慣差別很大；全部請求的命中率包含閘道自身的路由損失（見「被路由到另一個上游帳號」一項）。

常見問題