Codex キャッシュヒット率の実測

要点

• 正常値: 94.8%, 71 人のユーザーの継続会話の中央値。中間の半数は 91.2%〜96.9%
• 全リクエスト: 91.8%, ルーティング、期限切れ、新しいチャットを含む
• 最大のミスの原因: 進行中の会話の新規内容, ミスの 57%
• 形態間の差: 4.6 ポイント差, デスクトップアプリ、ターミナル UI、codex exec（非対話）

クライアントごとの正常なキャッシュヒット率

データ週：2026-11-03 – 2026-11-09（UTC）

• 継続会話のヒット率（ユーザー中央値）: 94.8%
• 中間の半数のユーザー: 91.2%–96.9%
• 対象ユーザー: 71 (週に継続ターンが 20 回以上)
• 全リクエストのヒット率: 91.8%

Codex の形態別ヒット率

同じクライアントの CLI、IDE 拡張機能、デスクトップアプリはほぼ同じリクエストを送るため、ヒット率も近い値になるはずです。

• デスクトップアプリ: 95.3% (55)
• ターミナル UI: 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 トークンからキャッシュされます。
• 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：reasoning effort の変更によるキャッシュミス

Codex のキャッシュヒット率を確認する方法

• Codex CLI は終了時にセッションのトークン使用量を表示します。"+ N cached" の部分がキャッシュから読み取った入力です（現行バージョンの動作で、ドキュメントには記載されていません）。
• API から：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 ブレークポイントが失われたりすることがあります。
• 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 ユーザーのみが対象です。利用習慣は人によって大きく異なります。全リクエストのヒット率には、ゲートウェイ自体のルーティング損失（「別の上流アカウントにルーティングされた」原因）が含まれます。

よくある質問