docs.x.ai/developers/advanced-api-usage/prompt-caching)に従っており、2026-08-19 に APIYI ゲートウェイ上で grok-4.6 を実地テストした結果に基づいています(124 回の呼び出しを、バックエンドの課金記録と1行ずつ照合済み)。
一言でいうと
リクエストの**冒頭部分(プレフィックス)**が最近のリクエストとバイト単位で一致すると、上流は冗長な処理をスキップします。一致した部分は 0.25× で課金されます。パラメータも、マーカーも不要です。 ほかの2つとの違いは次のとおりです。- Claude と比べると:
cache_controlマーカーはありません — 条件を満たすとそのまま発生します - OpenAI と比べると: 同じく自動で、同じく自由に記述できますが、Grok では
prompt_cache_key風のルーティング制御はできません
なぜ気にするのか — レート倍率を見てください
モデルの生の入力 token 価格を 1× とすると:
損益分岐点:2回目のリクエストです。 相殺すべき書き込み शुल्कはないため、プレフィックスが初めて再利用された時点で、節約できた分はすべて純粋な利益になります。
grok-4.6 のドル建て価格(1M tokens あたり、両方のコンテキスト階層):
他の Grok モデルの階層の境界とキャッシュ読み取りレートは、Grok の概要にある段階料金表をご覧ください。
適しているケース
- 1つの長い system prompt と tool 定義を、何度も呼び出す場合(エージェント、サポート bot)
- 1つの文書に対するバッチ処理(1つの契約書に対して 50 個の質問)
- 安定した文書チャンクが prompt の先頭に置かれる RAG
- マルチターン会話 — ただし Grok では、この実現方法の2通りの挙動がかなり異なる点に注意してください(下記参照)
適していないケース
- 毎回、最初の文字から異なるリクエスト
- 千 token 未満の prompt — テストでは、このようなリクエストを繰り返し呼び出しても、再利用可能なキャッシュは一度も構築されませんでした
両方のエンドポイント、ストリーミングと非ストリーミング、すべて照合済み
/v1/chat/completions と /v1/responses は、それぞれストリーミングと非ストリーミングについて、2026-08-19 にバックエンドの課金記録と4通りの組み合わせすべてを照合しました。その結果、キャッシュされた部分はどのケースでもキャッシュ料金で課金されていました。
ゲートウェイ側でクライアントの適応は不要です。 キャッシュの挙動は上流へそのまま引き継がれ、
cached_tokens は文字どおりそのまま返され、バックエンドの請求書にはキャッシュされた部分が「cache read」という個別の項目として記載されます。ヒットの条件
ヒットは128 Tokensに切り下げられる
cached_tokens は通常、安定したプレフィックスより少し小さくなります — これは想定どおりです。
追記のみ: 編集履歴で壊れます
同じプレフィックスを立て続けに送信し、1回だけ呼び出しを変更した場合:
実運用でこれが意味すること: 安定したコンテンツを先に、変動するコンテンツを最後に置くことです。
最小限の実行可能な例
同じ長いプレフィックスを異なる質問で2回送信します。1回目でキャッシュを書き込み、2回目でキャッシュヒットします。cached はシステム prompt の長さに近くなり(128 に切り捨て)、その部分は 0.25× で課金されます。
/v1/responses エンドポイントは自動的に同じように動作します。フィールドは usage.input_tokens_details.cached_tokens です。そのエンドポイントでは長い会話に追加のメリットがあります — 下の「長い会話はレスポンスのチェーンに置くべきです」を参照してください。ヒットとミスの見分け方 — usageフィールドを読む
その読み方: 小さい値はヒットではありません
「0より大きいか」だけを確認しないでください。cached_tokensを安定したプレフィックス長と比較してください:
テストでは、コールドな最初の呼び出しでも100〜200程度の値が返ることがあります。だまされないでください。それはプレフィックスがキャッシュされたことを意味しません。
突き合わせ: コンソールのキャッシュ課金詳細
単一の呼び出しに対するバックエンドログでは、キャッシュ読み取り token 数とその割引倍率が別行として記録され、レスポンス内のcached_tokensと照合できます。1回の呼び出しが正確にどのように課金されたかを知りたい場合は、それが正しい参照です。
3ステップの自己確認:
- 1000 tokenを超える安定したプレフィックスを用意し、2つのリクエストを続けて送信します
- 2つ目のレスポンスでは、
cached_tokensが明確に数千台で表示されるはずです - バックエンドのコールログでは、そのリクエストに「キャッシュ読み取り」の明細が表示され、1回目より入力コストが明らかに低くなっています
ヒット率を向上させる
安定したプレフィックスを設計する
- 長い指示、few-shot例、ツール定義は先頭に置き、ユーザー入力とタイムスタンプは最後に置きます
- ツール定義の順序とJSONシリアライゼーションは固定してください(シリアライザにキーを並べ替えさせないでください)
- 画像入力もプレフィックス一致の対象になります — 再利用するときはbase64 / URL とパラメータを同一に保ってください
- 同じプレフィックスを短時間にまとめて再利用し、呼び出しを分散させないでください
長い会話はResponsesチェーンに載せるべきです
これはGrokで見落としやすい違いです:
したがって、長い会話やマルチステップのエージェントでは、Responses APIチェーンを優先してください:
x-grok-conv-idについて
xAIのベストプラクティスでは、ヒット率を向上させるために、すべてのリクエストでx-grok-conv-idヘッダー(UUIDまたはセッションID)を送ることが推奨されています。APIYIで対称的なA/Bを実施しました。ヘッダーの有無で複数の独立したプレフィックスをそれぞれ複数回再利用し、2つのグループ間で観測可能な差は見られませんでした。送っても害はありませんが、ヒット率向上のために当てにしないでください。
ヒット率と期待すべきこと
もう一つ、はっきり言っておく価値があることがあります: キャッシュの価値は速度ではなく、コストです。 計測した time-to-first-token は、ヒット時とミス時で数百ミリ秒しか違いませんでした — キャッシュによって長いコンテキストのリクエストが速くなるとは期待しないでください。よくある落とし穴
他のチャネルとのクイック比較
プラットフォーム全体のキャッシング対応については、キャッシュ課金 FAQ をご覧ください。
このページの内容はすべて
grok-4.6 (2026-08-19) で測定しました。 xAI は、すべての Grok 言語モデルが prefix caching をサポートすると述べています。その他については一つずつベンチマークしていないため、ブロック粒度や短い prompt での挙動などの詳細は、ご自身のワークロードで確認する前提で扱ってください。ある prefix に対して表示される課金内容が、ここで説明している内容と明らかに一致しない場合は、レスポンスヘッダーの request-id を添えてサポートにお問い合わせください。要約
1. 完全自動
マーカーは不要、書き込み料金も不要です。条件を満たせばキャッシュされ、2回目以降の再利用は純粋な節約になります。
2. 追記のみ
一致判定はメッセージ先頭からバイト単位で行われます。編集履歴があると無効になり、ヒットは128 tokens単位に切り捨てられます。
3. 長い会話をつなぐ
マルチターンチャットでは元の静的プレフィックスのみが再利用されます。responses + previous_response_id により、ターンを重ねるごとにヒットが増えます。
4. ヒットを当てにしない
ヒットは保証されません。未キャッシュ時の価格で予算を見積もり、割引はおまけとして扱ってください。
関連リンク
- 同じグループ: Grok の概要 · チャットと推論 · Web と X 検索 · コード実行と MCP
- 他のチャネルでのキャッシュ: OpenAI キャッシュ課金 · Gemini キャッシュ課金 · Claude キャッシュ課金
- プラットフォーム全体の概要: キャッシュ課金 FAQ
- token を取得または管理する:
https://api.apiyi.com/token - xAI 公式ドキュメント:
docs.x.ai/developers/advanced-api-usage/prompt-caching