cache_controlブロックを使用してプロンプトキャッシングを実装する方法の例を以下に示します。
cache_controlパラメータを使用してキャッシュされています。これにより、複数のAPI呼び出しでこの大きなテキストを再処理することなく再利用できます。ユーザーメッセージのみを変更することで、キャッシュされたコンテンツを利用しながら本についてさまざまな質問をすることができ、より高速な応答と効率の向上につながります。
プロンプトキャッシングの仕組み
キャッシングが有効なリクエストを送信すると、以下のことが起こります。- システムは、指定されたキャッシュブレークポイントまでのプロンプトプレフィックスが最近のクエリからすでにキャッシュされているかどうかを確認します。
- 見つかった場合は、キャッシュされたバージョンを使用して、処理時間とコストを削減します。
- それ以外の場合は、完全なプロンプトを処理し、応答が開始されたらプレフィックスをキャッシュします。
- 多くの例を含むプロンプト
- 大量のコンテキストまたは背景情報
- 一貫した指示を持つ反復的なタスク
- 長いマルチターン会話
tools、system、messages(この順序)の完全なプロンプトを参照し、cache_controlで指定されたブロックまでを含みます。価格設定
プロンプトキャッシングは新しい価格設定構造を導入しています。以下の表は、サポートされている各モデルのミリオントークンあたりの価格を示しています。| Model | Base Input Tokens | 5m Cache Writes | 1h Cache Writes | Cache Hits & Refreshes | Output Tokens |
|---|---|---|---|---|---|
| Claude Opus 4.1 | $15 / MTok | $18.75 / MTok | $30 / MTok | $1.50 / MTok | $75 / MTok |
| Claude Opus 4 | $15 / MTok | $18.75 / MTok | $30 / MTok | $1.50 / MTok | $75 / MTok |
| Claude Sonnet 4.5 | $3 / MTok | $3.75 / MTok | $6 / MTok | $0.30 / MTok | $15 / MTok |
| Claude Sonnet 4 | $3 / MTok | $3.75 / MTok | $6 / MTok | $0.30 / MTok | $15 / MTok |
| Claude Sonnet 3.7 | $3 / MTok | $3.75 / MTok | $6 / MTok | $0.30 / MTok | $15 / MTok |
| Claude Sonnet 3.5 (deprecated) | $3 / MTok | $3.75 / MTok | $6 / MTok | $0.30 / MTok | $15 / MTok |
| Claude Haiku 4.5 | $1 / MTok | $1.25 / MTok | $2 / MTok | $0.10 / MTok | $5 / MTok |
| Claude Haiku 3.5 | $0.80 / MTok | $1 / MTok | $1.6 / MTok | $0.08 / MTok | $4 / MTok |
| Claude Opus 3 (deprecated) | $15 / MTok | $18.75 / MTok | $30 / MTok | $1.50 / MTok | $75 / MTok |
| Claude Haiku 3 | $0.25 / MTok | $0.30 / MTok | $0.50 / MTok | $0.03 / MTok | $1.25 / MTok |
- 5分キャッシュ書き込みトークンは基本入力トークン価格の1.25倍
- 1時間キャッシュ書き込みトークンは基本入力トークン価格の2倍
- キャッシュ読み取りトークンは基本入力トークン価格の0.1倍
プロンプトキャッシングの実装方法
サポートされているモデル
プロンプトキャッシングは現在以下でサポートされています。- Claude Opus 4.1
- Claude Opus 4
- Claude Sonnet 4.5
- Claude Sonnet 4
- Claude Sonnet 3.7
- Claude Sonnet 3.5 (非推奨)
- Claude Haiku 4.5
- Claude Haiku 3.5
- Claude Haiku 3
- Claude Opus 3 (非推奨)
プロンプトの構造化
静的コンテンツ(ツール定義、システム指示、コンテキスト、例)をプロンプトの先頭に配置します。cache_controlパラメータを使用して、キャッシング用の再利用可能なコンテンツの終了をマークします。
キャッシュプレフィックスは次の順序で作成されます。tools、次にsystem、次にmessages。この順序は、各レベルが前のレベルの上に構築される階層を形成します。
自動プレフィックスチェックの仕組み
静的コンテンツの終わりに1つのキャッシュブレークポイントを使用でき、システムが自動的に最長一致プレフィックスを見つけます。 仕組みは以下の通りです。cache_controlブレークポイントを追加すると、システムは自動的に以前のコンテンツブロック境界でのキャッシュヒットをチェックします(明示的なブレークポイントの前の約20ブロックまで)- これらの以前の位置のいずれかが以前のリクエストからキャッシュされたコンテンツと一致する場合、システムは最長一致プレフィックスを使用します
- これは、キャッシングを有効にするために複数のブレークポイントが必要ないことを意味します。最後に1つあれば十分です
複数のブレークポイントを使用する場合
以下の場合は、最大4つのキャッシュブレークポイントを定義できます。- 異なる頻度で変更されるセクションをキャッシュする(例:ツールはめったに変更されませんが、コンテキストは毎日更新されます)
- キャッシュされる内容をより細かく制御する
- 最終的なブレークポイントの前の20ブロック以上前のコンテンツのキャッシングを確保する
キャッシュの制限
最小キャッシュ可能プロンプト長は以下の通りです。- Claude Opus 4.1、Claude Opus 4、Claude Sonnet 4.5、Claude Sonnet 4、Claude Sonnet 3.7、Claude Sonnet 3.5 (非推奨)、Claude Opus 3 (非推奨)の場合は1024トークン
- Claude Haiku 4.5の場合は4096トークン
- Claude Haiku 3.5およびClaude Haiku 3の場合は2048トークン
cache_controlでマークされていても、キャッシュできません。このトークン数未満をキャッシュするリクエストは、キャッシングなしで処理されます。プロンプトがキャッシュされたかどうかを確認するには、応答使用フィールドを参照してください。
同時リクエストの場合、キャッシュエントリは最初の応答が開始された後にのみ利用可能になることに注意してください。並列リクエストのキャッシュヒットが必要な場合は、最初の応答を待ってから後続のリクエストを送信してください。
現在、「ephemeral」が唯一サポートされているキャッシュタイプであり、デフォルトでは5分の有効期限があります。
キャッシュブレークポイントコストの理解
キャッシュブレークポイント自体はコストを追加しません。 以下の場合にのみ課金されます。- キャッシュ書き込み:新しいコンテンツがキャッシュに書き込まれる場合(5分TTLの場合、基本入力トークンより25%多い)
- キャッシュ読み取り:キャッシュされたコンテンツが使用される場合(基本入力トークン価格の10%)
- 通常の入力トークン:キャッシュされていないコンテンツの場合
cache_controlブレークポイントを追加しても、コストは増加しません。実際にキャッシュされて読み取られるコンテンツに基づいて同じ金額を支払います。ブレークポイントは、どのセクションを独立してキャッシュできるかを制御するだけです。
キャッシュできるもの
リクエスト内のほとんどのブロックは、cache_controlでキャッシング用に指定できます。これには以下が含まれます。
- ツール:
tools配列内のツール定義 - システムメッセージ:
system配列内のコンテンツブロック - テキストメッセージ:
messages.content配列内のコンテンツブロック(ユーターンとアシスタントターンの両方) - 画像とドキュメント:
messages.content配列内のコンテンツブロック(ユーターン内) - ツール使用とツール結果:
messages.content配列内のコンテンツブロック(ユーターンとアシスタントターンの両方)
cache_controlでマークして、リクエストのその部分のキャッシングを有効にできます。
キャッシュできないもの
ほとんどのリクエストブロックはキャッシュできますが、いくつかの例外があります。-
シンキングブロックは
cache_controlで直接キャッシュできません。ただし、シンキングブロックは、以前のアシスタントターンに表示される場合、他のコンテンツと一緒にキャッシュできます。この方法でキャッシュされると、キャッシュから読み取られるときに入力トークンとしてカウントされます。 - サブコンテンツブロック(引用など)自体は直接キャッシュできません。代わりに、トップレベルブロックをキャッシュしてください。 引用の場合、引用のソース資料として機能するトップレベルドキュメントコンテンツブロックはキャッシュできます。これにより、引用がキャッシュされたドキュメントを参照することで、引用を使用してプロンプトキャッシングを効果的に使用できます。
- 空のテキストブロックはキャッシュできません。
キャッシュを無効にするもの
キャッシュされたコンテンツへの変更は、キャッシュの一部またはすべてを無効にする可能性があります。 プロンプトの構造化で説明されているように、キャッシュは階層に従います。tools → system → messages。各レベルでの変更は、そのレベルとそれ以降のすべてのレベルを無効にします。
次の表は、異なるタイプの変更によってキャッシュのどの部分が無効になるかを示しています。✘はキャッシュが無効になることを示し、✓はキャッシュが有効なままであることを示します。
| 変更内容 | ツールキャッシュ | システムキャッシュ | メッセージキャッシュ | 影響 |
|---|---|---|---|---|
| ツール定義 | ✘ | ✘ | ✘ | ツール定義(名前、説明、パラメータ)を変更すると、キャッシュ全体が無効になります |
| ウェブ検索トグル | ✓ | ✘ | ✘ | ウェブ検索を有効/無効にするとシステムプロンプトが変更されます |
| 引用トグル | ✓ | ✘ | ✘ | 引用を有効/無効にするとシステムプロンプトが変更されます |
| ツール選択 | ✓ | ✓ | ✘ | tool_choiceパラメータへの変更はメッセージブロックにのみ影響します |
| 画像 | ✓ | ✓ | ✘ | プロンプト内の任意の場所に画像を追加/削除するとメッセージブロックに影響します |
| シンキングパラメータ | ✓ | ✓ | ✘ | 拡張シンキング設定(有効/無効、予算)への変更はメッセージブロックに影響します |
| 拡張シンキングリクエストに渡される非ツール結果 | ✓ | ✓ | ✘ | 拡張シンキングが有効な場合、非ツール結果がリクエストで渡されると、以前にキャッシュされたすべてのシンキングブロックがコンテキストから削除され、それらのシンキングブロックに続くコンテキスト内のメッセージはキャッシュから削除されます。詳細については、シンキングブロックでのキャッシングを参照してください。 |
キャッシュパフォーマンスの追跡
これらのAPIレスポンスフィールドを使用してキャッシュパフォーマンスを監視します。レスポンス内のusage内(またはストリーミングの場合はmessage_startイベント)。
cache_creation_input_tokens:新しいエントリを作成するときにキャッシュに書き込まれたトークン数。cache_read_input_tokens:このリクエストのキャッシュから取得されたトークン数。input_tokens:キャッシュから読み取られたり、キャッシュを作成するために使用されなかった入力トークン数。
効果的なキャッシングのベストプラクティス
プロンプトキャッシングパフォーマンスを最適化するには、以下のようにします。- システム指示、背景情報、大規模なコンテキスト、または頻繁なツール定義などの安定した再利用可能なコンテンツをキャッシュします。
- キャッシュされたコンテンツをプロンプトの先頭に配置して、最高のパフォーマンスを実現します。
- キャッシュブレークポイントを戦略的に使用して、異なるキャッシュ可能なプレフィックスセクションを分離します。
- キャッシュヒット率を定期的に分析し、必要に応じて戦略を調整します。
異なるユースケースに対する最適化
シナリオに合わせてプロンプトキャッシング戦略をカスタマイズします。- 会話型エージェント:長い指示またはアップロードされたドキュメントを含む拡張会話のコストとレイテンシを削減します。
- コーディングアシスタント:関連セクションまたはコードベースの要約版をプロンプトに保持することで、オートコンプリートとコードベースQ&Aを改善します。
- 大規模ドキュメント処理:画像を含む完全な長文資料をプロンプトに組み込み、応答レイテンシを増加させません。
- 詳細な指示セット:Claudeの応答を微調整するために、広範な指示、手順、例のリストを共有します。開発者は通常、プロンプトに1つか2つの例を含めますが、プロンプトキャッシングを使用すると、20以上の高品質な回答の多様な例を含めることでさらに優れたパフォーマンスを得ることができます。
- エージェンティックツール使用:複数のツール呼び出しと反復的なコード変更を含むシナリオのパフォーマンスを強化します。各ステップは通常、新しいAPI呼び出しが必要です。
- 本、論文、ドキュメント、ポッドキャストトランスクリプト、その他の長文コンテンツと対話する:ドキュメント全体をプロンプトに埋め込み、ユーザーに質問させることで、任意のナレッジベースを活性化します。
一般的な問題のトラブルシューティング
予期しない動作が発生している場合:- キャッシュされたセクションが同一であり、呼び出し全体で同じ場所に
cache_controlでマークされていることを確認します - 呼び出しがキャッシュ有効期限内(デフォルトでは5分)に行われていることを確認します
tool_choiceと画像の使用が呼び出し間で一貫していることを確認します- 最小トークン数以上をキャッシュしていることを確認します
- システムは自動的に以前のコンテンツブロック境界でキャッシュヒットをチェックします(ブレークポイントの前の約20ブロック)。20個以上のコンテンツブロックを持つプロンプトの場合、すべてのコンテンツがキャッシュされるようにするために、プロンプトの前の方に追加の
cache_controlパラメータが必要な場合があります tool_useコンテンツブロック内のキーが安定した順序を持つことを確認します。一部の言語(例:Swift、Go)はJSON変換中にキー順序をランダム化し、キャッシュを破壊します
tool_choiceへの変更またはプロンプト内の任意の場所での画像の有無への変更は、キャッシュを無効にし、新しいキャッシュエントリを作成する必要があります。キャッシュ無効化の詳細については、キャッシュを無効にするものを参照してください。シンキングブロックでのキャッシング
拡張シンキングをプロンプトキャッシングと一緒に使用する場合、シンキングブロックには特別な動作があります。 他のコンテンツと一緒に自動キャッシング:シンキングブロックはcache_controlで明示的にマークできませんが、ツール結果を使用して後続のAPI呼び出しを行うときに、リクエストコンテンツの一部としてキャッシュされます。これは通常、シンキングブロックを会話を続けるために戻すツール使用中に発生します。
入力トークンカウント:シンキングブロックがキャッシュから読み取られると、使用メトリクスで入力トークンとしてカウントされます。これはコスト計算とトークン予算に重要です。
キャッシュ無効化パターン:
- ツール結果のみがユーザーメッセージとして提供される場合、キャッシュは有効なままです
- 非ツール結果ユーザーコンテンツが追加されると、キャッシュが無効になり、すべての以前のシンキングブロックが削除されます
- このキャッシング動作は、明示的な
cache_controlマーカーなしでも発生します
キャッシュストレージと共有
- 組織の分離:キャッシュは組織間で分離されます。異なる組織は、同一のプロンプトを使用していても、キャッシュを共有しません。
- 完全一致:キャッシュヒットには、キャッシュコントロールでマークされたブロックまでを含む、すべてのテキストと画像を含む100%同一のプロンプトセグメントが必要です。
- 出力トークン生成:プロンプトキャッシングは出力トークン生成に影響しません。受け取るレスポンスは、プロンプトキャッシングが使用されていない場合と同じになります。
1時間キャッシュ期間
5分が短すぎる場合、Anthropicは追加コストで1時間のキャッシュ期間も提供しています。 拡張キャッシュを使用するには、cache_control定義にttlを含めます。以下のようにします。
cache_creation_input_tokensフィールドは、cache_creationオブジェクト内の値の合計に等しいことに注意してください。
1時間キャッシュを使用する場合
定期的なペースで使用されるプロンプト(つまり、5分ごとに1回以上の頻度で使用されるシステムプロンプト)がある場合は、5分キャッシュを引き続き使用してください。これは追加料金なしで引き続き更新されるためです。 1時間キャッシュは、以下のシナリオで最適に使用されます。- 5分未満の頻度で使用される可能性は低いが、1時間ごとに1回以上の頻度で使用されるプロンプトがある場合。例えば、エージェント側エージェントが5分以上かかる場合、またはユーザーとの長いチャット会話を保存していて、一般的にそのユーザーが次の5分以内に応答しないと予想される場合。
- レイテンシが重要で、フォローアッププロンプトが5分を超えて送信される可能性がある場合。
- レート制限の利用を改善したい場合。キャッシュヒットはレート制限に対して差し引かれません。
異なるTTLの混合
同じリクエストで1時間キャッシュと5分キャッシュコントロールの両方を使用できますが、重要な制約があります。より長いTTLを持つキャッシュエントリは、より短いTTLの前に表示される必要があります(つまり、1時間キャッシュエントリは5分キャッシュエントリの前に表示される必要があります)。 TTLを混合する場合、プロンプト内に3つの課金位置を決定します。- 位置
A:最高キャッシュヒットのトークンカウント(ヒットがない場合は0)。 - 位置
B:Aの後の最高1時間cache_controlブロックのトークンカウント(存在しない場合はAに等しい)。 - 位置
C:最後のcache_controlブロックのトークンカウント。
Bおよび/またはCがAより大きい場合、Aが最高キャッシュヒットであるため、必然的にキャッシュミスになります。- 位置
Aのキャッシュ読み取りトークン。 - 位置
(B - A)の1時間キャッシュ書き込みトークン。 - 位置
(C - B)の5分キャッシュ書き込みトークン。
プロンプトキャッシングの例
プロンプトキャッシングを開始するのに役立つように、詳細な例とベストプラクティスを含むプロンプトキャッシングクックブックを準備しました。 以下に、さまざまなプロンプトキャッシングパターンを紹介するいくつかのコードスニペットを含めました。これらの例は、異なるシナリオでキャッシングを実装する方法を示し、この機能の実用的なアプリケーションを理解するのに役立ちます。大規模コンテキストキャッシングの例
大規模コンテキストキャッシングの例
input_tokens:ユーザーメッセージのみのトークン数cache_creation_input_tokens:法的ドキュメントを含むシステムメッセージ全体のトークン数cache_read_input_tokens:0(最初のリクエストではキャッシュヒットなし)
input_tokens:ユーザーメッセージのみのトークン数cache_creation_input_tokens:0(新しいキャッシュ作成なし)cache_read_input_tokens:キャッシュされたシステムメッセージ全体のトークン数
ツール定義のキャッシング
ツール定義のキャッシング
cache_controlパラメータは最後のツール(get_time)に配置され、すべてのツールを静的プレフィックスの一部として指定します。これは、get_weatherおよびget_timeの前に定義された他のツールを含むすべてのツール定義が、単一のプレフィックスとしてキャッシュされることを意味します。このアプローチは、複数のリクエスト間で再利用したい一貫したツールセットがある場合に役立ちます。毎回再処理することなく。最初のリクエストの場合:input_tokens:ユーザーメッセージのトークン数cache_creation_input_tokens:すべてのツール定義とシステムプロンプトのトークン数cache_read_input_tokens:0(最初のリクエストではキャッシュヒットなし)
input_tokens:ユーザーメッセージのトークン数cache_creation_input_tokens:0(新しいキャッシュ作成なし)cache_read_input_tokens:すべてのキャッシュされたツール定義とシステムプロンプトのトークン数
マルチターン会話の継続
マルチターン会話の継続
cache_controlでマークして、会話を段階的にキャッシュできるようにします。システムは自動的に後続メッセージの最長の以前にキャッシュされたプレフィックスを検索して使用します。つまり、以前にcache_controlブロックでマークされたブロックは、後でcache_controlでマークされていませんが、5分以内にヒットした場合、キャッシュヒット(およびキャッシュリフレッシュ!)と見なされます。さらに、cache_controlパラメータはシステムメッセージに配置されることに注意してください。これは、キャッシュから削除された場合(5分以上使用されない場合)、次のリクエストでキャッシュに追加されるようにするためです。このアプローチは、繰り返し同じ情報を処理することなく、進行中の会話でコンテキストを維持するのに役立ちます。これが正しく設定されている場合、各リクエストの使用レスポンスで以下が表示されます。input_tokens:新しいユーザーメッセージのトークン数(最小限)cache_creation_input_tokens:新しいアシスタントとユーザーターンのトークン数cache_read_input_tokens:前のターンまでの会話のトークン数
すべてをまとめる:複数のキャッシュブレークポイント
すべてをまとめる:複数のキャッシュブレークポイント
-
ツールキャッシュ(キャッシュブレークポイント1):最後のツール定義の
cache_controlパラメータは、すべてのツール定義をキャッシュします。 - 再利用可能な指示キャッシュ(キャッシュブレークポイント2):システムプロンプト内の静的指示は個別にキャッシュされます。これらの指示はリクエスト間でめったに変更されません。
- RAGコンテキストキャッシュ(キャッシュブレークポイント3):ナレッジベースドキュメントは独立してキャッシュされ、ツールや指示キャッシュを無効にすることなくRAGドキュメントを更新できます。
-
会話履歴キャッシュ(キャッシュブレークポイント4):アシスタントのレスポンスは
cache_controlでマークされ、会話が進むにつれて会話の段階的なキャッシングを有効にします。
- 最後のユーザーメッセージのみを更新する場合、4つのキャッシュセグメントすべてが再利用されます
- RAGドキュメントを更新しても、同じツールと指示を保持する場合、最初の2つのキャッシュセグメントが再利用されます
- 会話を変更しても、同じツール、指示、ドキュメントを保持する場合、最初の3つのセグメントが再利用されます
- 各キャッシュブレークポイントは、アプリケーションで変更される内容に基づいて独立して無効にできます
input_tokens:最後のユーザーメッセージのトークン数cache_creation_input_tokens:すべてのキャッシュセグメント(ツール+指示+RAGドキュメント+会話履歴)のトークン数cache_read_input_tokens:0(キャッシュヒットなし)
input_tokens:新しいユーザーメッセージのみのトークン数cache_creation_input_tokens:会話履歴に追加された新しいトークンcache_read_input_tokens:すべての以前にキャッシュされたトークン(ツール+指示+RAGドキュメント+以前の会話)
- 大規模なドキュメントコンテキストを持つRAGアプリケーション
- 複数のツールを使用するエージェントシステム
- コンテキストを維持する必要がある長時間実行される会話
- プロンプトの異なる部分を独立して最適化する必要があるアプリケーション
FAQ
複数のキャッシュブレークポイントが必要ですか、それとも最後に1つで十分ですか?
複数のキャッシュブレークポイントが必要ですか、それとも最後に1つで十分ですか?
- 目的のキャッシュポイントの前に20個以上のコンテンツブロックがある
- 異なる頻度で更新されるセクションを独立してキャッシュしたい
- コスト最適化のためにキャッシュされるものを明示的に制御したい
キャッシュブレークポイントは追加コストを追加しますか?
キャッシュブレークポイントは追加コストを追加しますか?
- キャッシュへのコンテンツ書き込み(5分TTLの場合、基本入力トークンより25%多い)
- キャッシュからの読み取り(基本入力トークン価格の10%)
- キャッシュされていないコンテンツの通常の入力トークン
キャッシュの有効期限は何ですか?
キャッシュの有効期限は何ですか?
何個のキャッシュブレークポイントを使用できますか?
何個のキャッシュブレークポイントを使用できますか?
cache_controlパラメータを使用)を定義できます。プロンプトキャッシングはすべてのモデルで利用可能ですか?
プロンプトキャッシングはすべてのモデルで利用可能ですか?
拡張シンキングでプロンプトキャッシングはどのように機能しますか?
拡張シンキングでプロンプトキャッシングはどのように機能しますか?
プロンプトキャッシングを有効にするにはどうすればよいですか?
プロンプトキャッシングを有効にするにはどうすればよいですか?
cache_controlブレークポイントを含めます。プロンプトキャッシングを他のAPI機能と一緒に使用できますか?
プロンプトキャッシングを他のAPI機能と一緒に使用できますか?
プロンプトキャッシングは価格設定にどのように影響しますか?
プロンプトキャッシングは価格設定にどのように影響しますか?
キャッシュを手動でクリアできますか?
キャッシュを手動でクリアできますか?
キャッシング戦略の有効性を追跡するにはどうすればよいですか?
キャッシング戦略の有効性を追跡するにはどうすればよいですか?
cache_creation_input_tokensおよびcache_read_input_tokensフィールドを使用してキャッシュパフォーマンスを監視できます。キャッシュを破壊するものは何ですか?
キャッシュを破壊するものは何ですか?
プロンプトキャッシングはプライバシーとデータ分離をどのように処理しますか?
プロンプトキャッシングはプライバシーとデータ分離をどのように処理しますか?
- キャッシュキーは、キャッシュコントロールポイントまでのプロンプトの暗号ハッシュを使用して生成されます。これは、同一のプロンプトを持つリクエストのみが特定のキャッシュにアクセスできることを意味します。
- キャッシュは組織固有です。同じ組織内のユーザーが同一のプロンプトを使用する場合、同じキャッシュにアクセスできますが、キャッシュは異なる組織間では共有されません。同一のプロンプトであっても共有されません。
- キャッシング機構は、各ユニークな会話またはコンテキストの完全性とプライバシーを維持するように設計されています。
-
プロンプト内の任意の場所で
cache_controlを使用しても安全です。コスト効率のために、可変性の高い部分(例:ユーザーの任意の入力)をキャッシングから除外する方が良いです。
Batches APIでプロンプトキャッシングを使用できますか?
Batches APIでプロンプトキャッシングを使用できますか?
- 共有プレフィックスを持つメッセージリクエストのセットを収集します。
- この共有プレフィックスと1時間キャッシュブロックを持つ単一のリクエストのみを含むバッチリクエストを送信します。これは1時間キャッシュに書き込まれます。
- これが完了したら、残りのリクエストを送信します。完了時期を知るためにジョブを監視する必要があります。
Pythonで`AttributeError: 'Beta' object has no attribute 'prompt_caching'`エラーが表示されるのはなぜですか?
Pythonで`AttributeError: 'Beta' object has no attribute 'prompt_caching'`エラーが表示されるのはなぜですか?
TypeScriptで'TypeError: Cannot read properties of undefined (reading 'messages')'が表示されるのはなぜですか?
TypeScriptで'TypeError: Cannot read properties of undefined (reading 'messages')'が表示されるのはなぜですか?