OpenRouter は、応答キャッシュ機能を発表しました。開発者はリクエストヘッダーを追加することで、完全に同一の API 呼び出しをキャッシュし、レイテンシとコストを大幅に削減できます。この機能はモデルプロバイダの前にキャッシュ層を配置し、リクエストがキャッシュを有効にすると、OpenRouter はリクエストボディ、モデル、API キー、ストリーミングモードをハッシュ化して一意のキャッシュキーを生成します。以前に同一のリクエストが行われ、有効期限が切れていない場合、キャッシュされた応答が即座に返され、プロバイダの呼び出しやトークン消費は発生しません。
キャッシュ機能はストリーミングと非ストリーミングの両方のリクエストをサポートします。ストリーミングキャッシュ応答は同じパイプラインを通じて再生されるため、クライアントコードの変更は不要です。テキスト、画像、音声、ドキュメント、ツール呼び出しはすべて正常にキャッシュされます。マルチモーダル入力（base64 画像、音声クリップ、ファイル添付など）もキャッシュキーハッシュに含まれます。ただし、内部で処理のためにオフロードされる非常に大きなマルチモーダルペイロードはキャッシュの対象外です。標準サイズのリクエストは問題なくキャッシュされます。
応答キャッシュはプロンプトキャッシュとは異なります。プロンプトキャッシュ（多くのプロバイダがネイティブでサポート）は、メッセージが共通のプレフィックスを共有する場合にプロンプト部分のコストを削減します。一方、応答キャッシュはプロバイダを完全にスキップし、OpenRouter のエッジキャッシュから完全な応答を返します。
キャッシュされた応答は通常 80～300 ミリ秒で返され、その大部分はシリアル化とネットワークにかかる時間です。キャッシュ検索自体は平均 4 ミリ秒です。比較として、典型的な非キャッシュリクエスト（Gemini 2.5 Flash は約 1.3 秒、Kimi K2.6 は 4.6 秒、GPT-5.5 は 9.1 秒）と比べて大幅に高速です。キャッシュヒット時の課金はゼロ：プロンプトトークンも完了トークンも一切請求されません。
有効化は簡単です。キャッシュしたい各 API 呼び出しに X-OpenRouter-Cache: true ヘッダーを追加するだけです。また、プリセット（Presets）を使用して、プリセット設定で cache_enabled: true を設定することで、そのプリセットを使用するすべてのリクエストでキャッシュを有効にすることもできます（個別のヘッダーは不要）。キャッシュの持続時間は X-OpenRouter-Cache-TTL で制御可能（1 秒～24 時間、デフォルトは 5 分）。最新の応答が必要な場合は、X-OpenRouter-Cache-Clear: true を送信して特定のリクエストのキャッシュをクリアできます。OpenRouter は応答ヘッダーでキャッシュステータスを返します：X-OpenRouter-Cache-Status は HIT または MISS を示し、X-OpenRouter-Cache-Age と X-OpenRouter-Cache-TTL でキャッシュのパフォーマンスを確認できます。
この機能は多くのシナリオで役立ちます。例えば、エージェントのリトライ：エージェントワークフローが途中で失敗した場合、最初から再試行できます。キャッシュされたステップは瞬時に無料で返されるため、新しい作業に対してのみ支払います。テストスイート：LLM を利用したテストを繰り返し実行してもトークンを消費しません。最初の実行でキャッシュが作成されると、後続の実行は決定論的かつ無料です。繰り返しコンテキスト処理：アプリが同じモデルに同じプロンプト（同じシステムプロンプト、同じユーザー入力、同じパラメーター）を送信する場合、最初の呼び出しのみがコストがかかります。
現在、応答キャッシュは /chat/completions、/responses、/messages、/embeddings の各エンドポイントで利用可能です。その他のエンドポイント（レガシー /completions、/audio/speech（TTS）、/audio/transcriptions（STT）、/rerank、動画生成）はまだサポートされていません。この機能は現在ベータ版であり、OpenRouter はパフォーマンスを監視した上で API サーフェスを確定する予定です。キャッシュヒットはプロバイダのレート制限にカウントされず（リクエストがプロバイダに到達しないため）、アクティビティログにキャッシュインジケーターが表示され、簡単に監視できます。詳細は公式ドキュメントをご覧ください。