プロンプトキャッシングを請求書から読む
プロンプトキャッシングの節約を監査する方法：すべてのリクエストにある 2 つのキャッシュ列、自分で計算できる命中率、そして節約を静かに殺す 3 つのパターン。
プロンプトキャッシングは割引として売られます。その割引が本物だと証明されるか、静かに失われるか——裁くのはあなたの請求書です。多くの解説は仕組みで止まりますが、この記事は自分の数字の読み方を教えます——検証できない節約は、より小さいのにやはり鵜呑みにする数字にすぎないからです。
最初に開示します：私は API ゲートウェイ Teapot Router を運営しています。ワークスペースではリクエスト毎の費用・トークン・キャッシュ列がエクスポート付きで見えます。以下の監査方法は、同じ数字を出すどのエンドポイントでも機能します。
2 つの列が割引を決める
キャッシングは 2 つの特殊なトークン数で課金されます。キャッシュ作成トークン：安定したプロンプトプレフィックスの最初の書き込みで、通常の入力よりやや高いプレミアム課金。キャッシュ読み取りトークン：同じプレフィックスの以降の再利用で、大幅割引で課金——通例、コールド入力より一桁安い。正確な倍率は事業者とモデルによりけりです。公表の価格表に載っていないなら、それ自体が発見です。
仕組みはプレフィックス再利用です：プロンプトの先頭に安定して置かれるもの——システムプロンプト、プロジェクトの文脈、それまでの会話——は 1 回だけ処理され、以降の毎ターンは安く再読み取りされます。割引はクーポンではありません。プロンプトの前部が変わらないことの算術的な帰結です。
計算する価値のある数字：命中率
1 週間の実際のリクエストを取り出し、ある比率を計算します：キャッシュ読み取りトークン ÷ 総入力トークン。絶対値は負荷次第——新しいチャットが多いユーザーと長時間セッションのエージェントでは違う場所に落ちます——なので、シグナルは普遍の目標値ではなく趨勢です。命中率が週をまたいでずるずる下向くなら、通常は価格より上流の何かが変わった兆候です：プロンプト、セッション形状、またはエンドポイント。
キャッシュを静かに殺す 3 つのパターン
趨勢が滑り始めたら、事業者のせいにする前に、まずこの 3 つを探してください：
- 不安定なプレフィックス。プロンプトの最前方にあるタイムスタンプ、入れ替わる指示、編集されたばかりのシステムプロンプトは、毎ターンキャッシュ済みプレフィックスを無効化します——書き込みプレミアムを払い直すばかりで、読み取り割引は一度も入りません。プロンプトの前部は退屈でなければなりません。
- 中盤のコンテキスト攪拌。ターン間に巨大で変わり続けるツール出力を貼るエージェントは、プレフィックスを動かし続けます。攪拌の場所次第で再利用は崩れます。古いツール出力の掃除は、整理であると同時にキャッシュ判断です。
- キャッシュより短いセッション。キャッシュの寿命は短い——日ではなく分です。ターン間の長い空きが時計をリセットし、細かく切られすぎたセッションは、書き込みプレミアムを償却するだけの再読み取りに届かないかもしれません。少なく・長く・安定したセッションの方がよくキャッシュされます。
監査可能性の問い
どのエンドポイントでも、3 つの質問がキャッシュ割引の本物さを決めます：リクエスト毎の明細はキャッシュ作成・読み取り・コールドを分けていますか？キャッシュ価格はブログ記事だけでなく機械可読の価格表にありますか？命中率の趨勢が見えるだけの履歴をエクスポートできますか？どれかが No なら、その節約は検証不能なマーケティング主張です——未検証の割引は、いつのまにか蒸発するものです。
ワークスペースの明細と公開価格エンドポイントは、私たちが自社サービスで同じ問いに答える方法です：全リクエストのキャッシュ列、エクスポート可、計算機が読むのと同じ JSON からの価格：https://teapotrouter.com/en/claude-code-cost-calculator
プロンプトキャッシングは有効にする機能ではなく、測定する挙動です。2 つの列を読み、命中率を計算し、趨勢を見張り、より良いレートを探す前にプレフィックスを直す。列を見せる事業者は自分の仕事をチェックさせています——見せない事業者は、目を閉じて自分の割引を採点させているのです。
よくある質問
プロンプトキャッシングは常に節約になりますか？
なりません。キャッシュ書き込みは通常の入力よりプレミアムがつくので、1 回しか使わないプレフィックスはむしろ少し高くつきます。節約は、何度も再読み取りされる安定したプレフィックス——長いセッション、大きな静的システムプロンプト、再利用されるドキュメント——から生まれます。
キャッシュ命中率の計算方法は？
リクエスト毎の明細から：1 週間の実仕事で、キャッシュ読み取りトークン ÷ 総入力トークン。1 リクエストではなく趨勢で判断します——命中率の下滑りは、価格より先にプロンプトやセッションの変化を指します。
キャッシュの節約が消えたのはなぜ？
たいてい 3 つのどれかです：プロンプトプレフィックスが安定しなくなった（前部の編集や変動する内容）、アイドル間隔がキャッシュ寿命を超えた、またはエンドポイントがキャッシュの勘定方式を変えた——それが見えるのは、明細が列を分けている場合だけです。