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

要点

• 正常値: 97.6%, 20 人のユーザーの継続会話の中央値。中間の半数は 97.1%〜98.9%
• 全リクエスト: 95.1%, ルーティング、期限切れ、新しいチャットを含む
• 最大のミスの原因: 新しい会話, ミスの 34%
• 形態間の差: 0.6 ポイント差, デスクトップアプリ、CLI（ターミナル）

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

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

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

OpenCode の形態別ヒット率

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

• デスクトップアプリ: 98.0% (7)
• CLI（ターミナル）: 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 分キャッシュに書き込むとした場合の、入力 100 万トークンあたりの実質コスト：

• 今週の中央値 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 ブレークポイントが失われたりすることがあります。
• 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 ユーザーのみが対象です。利用習慣は人によって大きく異なります。全リクエストのヒット率には、ゲートウェイ自体のルーティング損失（「別の上流アカウントにルーティングされた」原因）が含まれます。

よくある質問