正常なキャッシュヒット率は?AI コーディングクライアントの実測
2026-11-03 の週の実測では、Claude モデル使用時、主要な AI コーディングクライアントの継続会話のキャッシュヒット率は 95%–98%、GPT を使う Codex は約 95% でした。クライアント間の差は小さく、あなたのヒット率が明らかに低い場合、原因の多くはアカウント切り替え、5 分を超える間隔、新しい会話です。
データ週:2026-11-03 – 2026-11-09(UTC)
要点
- Claude モデルでの正常値: 95%–98%, 7 クライアントの継続会話の中央値
- GPT を使う Codex: 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 ブレークポイントが失われたりすることがあります。
- v2.1.181 より前の Claude Code は、カスタム Base URL 使用時にシステムプロンプト先頭の帰属ブロックへリクエストごとに異なるトークンを入れていたため、リクエスト本文でキャッシュするゲートウェイではヒットしません。アップデートするか、CLAUDE_CODE_ATTRIBUTION_HEADER=0 を設定してください。
- セルフテスト:最小キャッシュ長を超える同じプレフィックスのリクエストを 2 回送ります。2 回目のキャッシュ読み取りはプレフィックスの長さに近くなるはずです。
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 ユーザーのみが対象です。利用習慣は人によって大きく異なります。全リクエストのヒット率には、ゲートウェイ自体のルーティング損失(「別の上流アカウントにルーティングされた」原因)が含まれます。
よくある質問
正常なキャッシュヒット率はどのくらいですか?
Claude モデルでの継続会話では、主要クライアントのユーザー中央値は 95%–98% です。ルーティング、期限切れ、新しいチャットを含む全リクエストでは、通常これより数ポイント低くなります。90% を下回る場合、クライアント自体が原因であることはまれです。
キャッシュヒットとキャッシュミスとは?
プロンプトキャッシュは、リクエストの先頭にある変わらない部分(システムプロンプト、ツール定義、それまでのターン)を保存します。次のリクエストが同じ内容で始まると、その部分はキャッシュから読み取られ(ヒット)、入力価格のごく一部で課金されます。内容が異なるかキャッシュが期限切れの場合は全体が処理され(ミス)、通常は再びキャッシュに書き込まれます。
キャッシュヒット率は高いほど良いですか?
はい、高いほど良いです。キャッシュ済み入力は入力価格の約 0.1 倍(一部の新しいモデルではさらに低い)で課金され、最初のトークンも早く届きます。Claude のサブスクリプションでは、キャッシュ読み取りは使用制限にほとんどカウントされません。
キャッシュヒット率がこんなに低いのはなぜですか?
よくある原因は、リクエストが別の上流アカウントにルーティングされること(Relay でよくある)、5 分を超える間隔によるキャッシュの期限切れ、サブエージェントなどの並列リクエスト、モデル切り替え、新しい会話です。各クライアントのページでは、実測の割合順に原因と対処法を挙げています。
クライアントによってキャッシュヒット率は大きく違いますか?
それほど違いません。同じモデルなら、Claude Code、pi、OpenCode などの継続会話のヒット率は数ポイントしか違いません。影響が大きいのはベンダーで、OpenAI のキャッシュはプレフィックス全体の一致が必要なため、GPT を使う Codex は Claude 系クライアントより数ポイント低くなります。
Relay ではなぜキャッシュヒット率が低いのですか?
キャッシュは上流アカウントに属します。1 つの会話を複数のアカウントに分散させたり、形式変換でプレフィックスを変えたりする Relay では、キャッシュが何度も書き直されます。同じプレフィックスのリクエストを 2 回送り、2 回目がプレフィックスの長さ程度をキャッシュから読み取っているかを確認してテストできます。
キャッシュヒット率が低いと Claude プランの使用制限を早く使い切りますか?
はい。Claude プランの使用制限に関する当社の実測では、キャッシュ読み取りは制限をほとんど消費せず、キャッシュ書き込みはキャッシュなしの入力とほぼ同じようにカウントされます。キャッシュ済みのコンテキストはほぼ消費ゼロですが、ミスすると再び全量がカウントされます。プラン別の制限は Claude 使用制限ページ(/claude-usage-limits)をご覧ください。
キャッシュヒット率はどう計算しますか?
キャッシュ読み取りトークン ÷ 入力トークンです。入力にはキャッシュなしの入力、キャッシュ書き込み、キャッシュ読み取りが含まれます。Anthropic 形式では cache_read_input_tokens、OpenAI 形式では cached_tokens です。
Cline、Roo Code、Cursor が表にないのはなぜですか?
各セルには、週に十分な継続ターンがあるユーザーが 5 人以上必要です。Cursor の独自キーによるリクエストは Cursor のサーバーから送られるため、ゲートウェイからはクライアントが見えません。SDK や Relay 経由のリクエストもクライアントを特定できません。