コストとインテリジェンスの最適化

ワークロードがプロトタイプから本番環境へ移行すると、コストは第一級の設計上の制約になります。最も高性能なモデルは大規模運用では高価すぎる場合があり、最も安価なモデルは品質面で不足する場合があります。コストをうまく管理するということは、各コストレバーが出力品質にどう影響するかを理解することを意味します。品質とトレードオフになるレバーもあれば、そうでないレバーもあるからです。Claude Platformでは、そのトレードオフを直接制御できます。リクエストごとにモデル、エフォートレベル、アーキテクチャを選択できるため、ワークロードをコスト対インテリジェンスのフロンティア上のほぼどこにでも配置できます。

コストとインテリジェンスは通常、一方で他方を買うフロンティアとして描かれます。このページの最初のグループのレバーは、品質に触れずにコストを削減することでワークロードをそのフロンティアに近づけます。フロンティアに沿って移動するのは2番目のグループだけです。

レバーには2種類あります。

• 無償の改善（Free wins） は品質に触れずに支出を削減します。「prompt caching」（プロンプトキャッシング）、トークンの衛生管理、実行中のモデルに対するプロンプト監査、最大24時間待てる作業向けの50%割引のバッチ処理、そして最後の防衛線としてのワークスペースの支出制限です。
• トレードオフ（Tradeoffs） はコストとインテリジェンスを交換します。モデル選択、エフォート、出力上限とタスク予算、マルチモデルアーキテクチャです。

各レバーには測定結果と、それが効果を発揮する条件のルールが付いています。Anthropicの測定では、プロンプトキャッシングが群を抜いて最大のレバーでした。このガイドのベンチマークではエージェントループのコストを2.7分の1から5.3分の1に削減し、小規模なトリアージエージェントの請求額を83%、入力のトリミングを加えると88%削減しました。マルチモデルのレバーはより限定的で、2つ目のモデルが効果を発揮したのはアドバイザーとオーケストレーターという2つの形でした。

ここから始める

自分の状況に合う行を見つけてください。

これらの結果はAnthropic社内のもの（参照ベンチマーク）であり、方向性を示すもので保証ではありません。4ステップの方法で自分のワークロードで測定してください。

品質を落とさずに支出を削減する

プロンプトキャッシング、トークンの衛生管理、バッチ処理、現在のモデルに対するプロンプト監査は、いずれも出力品質を下げずに支払額を下げます。注意点が2つあります。バッチ処理は割引と引き換えにレイテンシを犠牲にします。また、トークン衛生のレバーであるコンテキスト編集は、このセクションで測定した実行では節約額よりもコストのほうが大きくなりました。

繰り返されるコンテキストをキャッシュする

キャッシングが最優先である理由

他のどのレバーよりも先にプロンプトキャッシングを有効にしてください。エージェントタスクの各ターンは、増え続ける会話全体、つまりシステムプロンプト、ツール定義、過去のすべてのターンを再送信するからです。40ターンのタスクは最初のターンを40回送信するため、タスクのコストはターン数のほぼ2乗で増加します。キャッシングは再送信を止めるわけではありませんが、各再送信のコストは約10分の1になり、処理も速くなります。プレフィックスは入力価格の10分の1であるキャッシュ読み取り料金で課金され、各ターンは新しい部分についてのみ1.25倍のキャッシュ書き込み料金を支払います。

良い状態の目安。 実際のトラフィックの丸1日分で、エージェントループは入力の中央値84%をキャッシュから読み取り、コーディングかどうかを問わず上位10%のハーネスは94%以上を読み取っていました¹⁷。タスクの深い段階では、よく構築されたループが正規料金を支払うのは入力の1%未満です。約80%を下回る場合は、キャッシュを壊している何かを探してください（キャッシュを壊すものを参照）。

Anthropicが測定した実行全体で、キャッシュ読み取りは常にタスクコストの単一最大の構成要素であり、キャッシングはほとんどのモデル選択の判断よりも価値があります。AnthropicはDeepResearch Bench II⁷の実行をキャッシングありとなしで価格評価しました。

キャッシュのデフォルトの有効期間は5分で、エージェントループのターンは数秒間隔なので、割引は毎ターンほとんどのトークンに適用されます。キャッシングのチャートの実行では、入力トークンの79%から90%をキャッシュから読み取っていました。短いループは再読み取りが少ないため、節約額はエピソードの深さによって変わりますが、測定したすべてのモデルとベンチマークでキャッシングは単一最大のレバーであり続けました。

キャッシュ期間を選ぶ

ループがターンの間に人を待つ場合は、1時間のキャッシュ期間を使用してください。書き込みコストは高くなります（入力価格の1.25倍ではなく2倍）。どちらの期間でもミスするとプレフィックス全体が読み取り価格ではなく書き込み価格で課金されるため、セッションあたり数ターンが5分から1時間の休止の後に続くようになれば、長い期間のほうが得になります。

判断するには、会話内の連続するリクエスト間の間隔を数えます。

• 約20回に1回を超える間隔が5分から1時間の範囲にあり、1時間を超える間隔がまれな場合：1時間の期間を使用します。
• ターンが数秒間隔で届く場合：5分のデフォルトのままにします。休止がまったくない場合、Claude Sonnet 5では1時間設定より15%、Claude Opus 5では11%安くなりました。
• 1時間を超える間隔が多い場合：デフォルトのままにします。1時間を超える間隔はどちらの期間も期限切れにし、1時間設定はその後プレフィックスをより高い書き込み価格で再書き込みするため、そうした間隔のたびに損をします。5分を超える休止のうち、約60%以上が1時間も超える場合はデフォルトのままにしてください。1時間の期間が得になるのは、長い休止の少なくとも約40%が1時間以内に終わる場合だけです。

Anthropicは、入力とコンテキストのトークンを削るのトリアージジョブを、人の遅延をシミュレートするために一部のターンの前に休止を挿入して測定しました¹⁶。測定した両モデルで、約30ターンに1回が休止の後に続くようになると1時間キャッシュのほうが安い設定になったため、20回に1回のルールには余裕があります。また、5分設定では休止後のターンごとにプレフィックス全体を再書き込みするため、交差点を過ぎると差は急速に広がります。現行のすべてのモデルは同じキャッシュ書き込み倍率を使用し、Claude Fable 5.1とClaude Mythos 5.1を除くすべてのモデルは同じ読み取り価格を使用するため、他のモデルでも交差点は同じ範囲にあります。Fable 5.1は次に扱うケースです。精度はすべてのセルで実行間のノイズの範囲内に収まりました。休止後のターンは、1時間設定ではウォームキャッシュ時のレイテンシを維持しました。次のチャートは、Claude Sonnet 5における休止後ターンの割合に対するセッションあたりのコストをプロットしたものです。

Anthropicは、5分キャッシュをウォームに保つ追加リクエストも測定しました。Claude Sonnet 5とClaude Opus 5では、休止後ターンのどの割合でも1時間の期間に対して測定可能な節約はなく、毎ターンの前に休止がある場合はコストが高くなったため、代わりに期間を使用してください。

Claude Fable 5.1では最も安い設定が異なります。そのキャッシュ読み取りは入力価格の0.025倍（100万トークンあたり$0.25）である一方、キャッシュ書き込みは標準の倍率のままなので、プレフィックスを再読み取りするキープアライブリクエストは安く、1時間の期間の書き込みプレミアムのほうが大きな請求になります。AnthropicはClaude Fable 5.1で同じ3つの設定を使ってトリアージジョブを測定しました¹⁹。休止が数分である限り、5分キャッシュをウォームに保つほうが1時間キャッシュよりセッションあたり13%から20%安くなりました。休止が45分近くになった場合にのみ1時間キャッシュが勝ち、その差はセッションあたり約12セントでした。Claude Fable 5.1では、人が数分間離れている間は5分キャッシュをウォームに保ち、休止が1時間に近づく場合は1時間の期間を購入してください。

キャッシュをウォームに保つには、前のリクエストの開始から4分以内に、そしてその後4分ごとに、max_tokensを0に設定して前のリクエストを再送信します。streamが設定されていた場合は外してください。レスポンスの終了ではなくリクエストの開始から数えてください。キャッシュの5分の有効期間は、エントリを書き込んだまたは更新したリクエストの開始から計測されるため、レスポンスの生成に費やした時間もそこに含まれます。これが事前ウォーミングリクエストです。キャッシュの有効期間を更新し、何も生成せず、キャッシュ読み取りのみが課金されます。プレフィックスは1バイトも変更しないでください。また、理由もなくトークンをサンプリングするmax_tokens: 1は使わないでください。リクエストのボディだけでなくヘッダーも再送信してください。リクエストにanthropic-betaヘッダー（たとえばタスク予算用）が付いている場合、キープアライブリクエストにも同じヘッダーが必要です。そうしないと、再送されたボディ内のベータ限定フィールドが拒否されます。max_tokens: 0のリクエストは、リクエストがthinking.type: "enabled"（Claude Fable 5.1のデフォルトの適応型思考は問題ありません）、構造化出力、または強制的なツール選択を設定している場合は拒否されます（その制限事項）。そうしたワークロードでは、代わりに1時間の期間を購入してください。

# 最後のリクエスト開始から4分以内に(生成に費やした時間もキャッシュの
# 有効期間に含まれます)、max_tokensを0に設定してそのリクエストを再送信し、
# streamは削除します(max_tokens: 0のリクエストはストリーミングできません)。
# anthropic-betaヘッダーを含め、元のリクエストと同じヘッダーを送信します。
jq '.max_tokens = 0 | del(.stream)' last_request.json | \
  curl https://api.anthropic.com/v1/messages \
    -H "x-api-key: $ANTHROPIC_API_KEY" \
    -H "anthropic-version: 2023-06-01" \
    -H "content-type: application/json" \
    --data-binary @-

キャッシングを有効にする

セットアップにはほとんど手間がかかりません。自動キャッシングがブレークポイントを配置してくれます。そうでなければ、Claude Codeに同梱されているClaude APIスキルが、1つのプロンプトから既存の統合にキャッシングを追加できます。次の抜粋は、これらの測定を行ったハーネスにスキルがキャッシングを追加している様子です。

$ claude
> /claude-api add prompt caching to this integration

Done. Prompt caching is now wired into the harness. Two changes:

- build_system() now adds cache_control: {"type": "ephemeral"} to the
  system block. Since the API renders tools -> system -> messages, this
  one breakpoint caches the entire static prefix -- the full tool array
  plus the system prompt.
- apply_moving_cache_breakpoints() strips any stale markers, then marks
  the last content block of the two most recent user turns. The older
  marker is the read point matching the prefix the previous request
  cached; the newer one extends the cache for the next request.

That's 3 breakpoints total, under the limit of 4.
...

これらのブレークポイントの配置は、明示的なキャッシュブレークポイントの標準パターンに従っています。

キャッシュを壊すもの

タスク中にキャッシュを壊しうるものはいくつかあります。タイムスタンプやキューの位置など、リクエストごとに変わるものを安定したプレフィックスの前に置くと、すべてのリクエストが完全なキャッシュ書き込みになります。入力とコンテキストのトークンを削るのトリアージ実行では、システムプロンプトの先頭にある25トークンのステータス行のせいで、実行あたり$0.59ではなく$4.24かかり、キャッシングをオフにした場合よりも高くなりました。リクエストごとのテキストは最新のユーザーターンに置いてください。

キャッシュはリクエストを順番に（ツール、次にシステムプロンプト、次にメッセージ）バイト単位で完全一致させるプレフィックスマッチなので、どこかに変更があるとそれ以降のすべてが無効になります。リクエスト間でeffortや思考の設定を変更すると、その時点以降のキャッシュが無効になり、一部のモデルではその前にあるツールとシステムプロンプトも無効になります。システムプロンプトを編集すると、その時点以降のキャッシュが無効になります。出力フォーマットを設定または変更すると、会話全体のキャッシュが無効になります。ツール定義を追加、削除、または並べ替えると、すべてが無効になります。プロンプトキャッシングのページにこれらのケースが一覧されています。ただし出力フォーマットについては構造化出力で扱っています。最新のモデルでは、トップレベルのsystemフィールドを編集する代わりに、会話途中のシステムメッセージ、つまりmessagesに追加する{"role": "system"}メッセージで指示を変更してください。キャッシュされたプレフィックスはそのまま保たれます。どのモデルが対応しているかはそのページで確認してください。対応しているモデルでは、メッセージごとのエフォート変更もキャッシュされたプレフィックスをそのまま保ちます。影響が最も大きいのはClaude Fable 5.1とClaude Mythos 5.1です。キャッシュが壊れると、プレフィックスを入力価格の0.025倍で読み取る代わりに1.25倍で再書き込みするため、100,000トークンのプレフィックスでは壊れた1ターンが$0.03ではなく$1.25、つまり読み取りの50倍かかります。Claude Opus 5では12.5倍（$0.05ではなく$0.63）です。

Anthropicはこれをトリアージエージェントの長いセッションで測定しました¹⁸。セッション途中で行ったエフォート変更とツール追加は、39,000トークンと60,000トークンのキャッシュを再書き込みし、それらのセッションはセッションあたり$0.95かかりました。同じ2つの変更をコンパクション後の最初のリクエストで行うと$0.75、コンパクションをトリガーしたリクエストで行うと$0.92でした。後者では、コンパクションの要約パスが81,000トークンのコンテキストをキャッシュ書き込み価格で再処理したためです。その要約パスは$0.21かかりましたが、同じ変更を1リクエスト後に行った場合は$0.04でした。精度はすべてのアームで実行間のノイズの範囲内でした。

タスク予算を途中で変更すると、予算値を含むキャッシュ済みプレフィックスがすべて無効になるため、最初のリクエストで一度だけ設定してください。コンテキスト編集のパスは毎回、クリアした時点からプレフィックスを無効にし、次のリクエストがそれ以降のすべてを再キャッシュする費用を支払うため、小さなバッチを何度も行うのではなく、少数の大きなバッチでクリアしてください。Claude Fable 5.1とClaude Mythos 5.1では、これらはいずれもトークンあたり読み取り価格の50倍かかるため、そこで最も重要になります。キャッシュを無効にする変更はすべて自然な区切りで行い、その後キャッシュ読み取りが減っていないことを確認してください。減っている場合は、キャッシュ診断でプレフィックスがどこで分岐したかがわかります。

入力とコンテキストのトークンを削る

ほとんどのエージェントリクエストには、回答にまったく影響しないトークンが含まれています。それらを削っても出力品質が損なわれることはめったにありませんが、ここで挙げるすべてのレバーが測定時に費用を節約したわけではありません。見るべき場所は2つあります。

• 入力のトリミング。 Webフェッチツールの動的フィルタリングは取得したページからボイラープレートを除外し、画像のリサイズはビジョン入力を適切なサイズにし、遅延読み込み付きのツール検索は必要なときにだけツール定義を読み込みます（このセクションの後半で測定）。プログラムによるツール呼び出しでは、Claudeがコードから複数のツール呼び出しを実行できるため、フィルタリングされた結果だけがコンテキストに入ります。そのドキュメントでは、エージェント検索ベンチマークで入力トークンが24%減り、スコアが上がったと報告されています。ツールコンテキストの管理では、ツール検索、プログラムによるツール呼び出し、プロンプトキャッシング、コンテキスト編集を比較しています。
• コンテキストのライフサイクル。 コンテキスト編集は古くなったツール結果をクリアし、しきい値付きの自動コンパクションは長いループが履歴全体を持ち越すのを防ぎます。

これらのレバーはキャッシュとも互いとも相互作用するため、正味の効果で判断し、キャッシュ診断を使って各変更後もキャッシュ済みプレフィックスが維持されていることを確認してください。Anthropicは、公開リポジトリのスクリーンショット付きの実際のバグ報告20件を処理するイシュートリアージエージェントと、トークン数が2.6倍の同じジョブの長いバリアントでこれらを測定しました。キャッシングをオンにした状態で、入力のトリミング（画像のリサイズとツール検索）により、短い実行ではさらに26%、長い実行では21%削減されました。

使わないツール定義を遅延させる

リクエストに添付されたすべてのツール定義は毎ターンの入力になり、いくつかのMCPサーバーを合わせると数百に達します。Anthropicは、トリアージエージェント自身の2つのツールに加えて、公開MCPサーバーからの実際のツール定義のカタログを付け、合計最大502ツールで実行しました。すべてを読み込む場合と、追加分をツール検索の背後でdefer_loadingとマークする場合です。

すべての定義を読み込むと、カタログが大きくなるにつれて実行コストはほぼ2倍になり、各リクエストのスキーマトークンに追従しました。ツール検索ではどのカタログサイズでも横ばいで、502ツールでは45%安くなりました。精度はどちらの場合もすべてのセルで20件中15から18件で、モデルが間違ったツールを呼び出すことは一度もなかったため、この規模ではカタログが損なうのは正確性ではなくお金です。MCPコネクタ経由のツールでも同じことが言えます。公開GitHub MCPサーバーを接続した状態で、そのツールセットを遅延させる（default_config: {defer_loading: true}）と、同じ精度で実行コストが20%削減されました。

データファイルをプロンプトに入れない

モデルが表に対して計算を行う必要がある場合は、貼り付けるのではなく、Files APIでアップロードし、コード実行でモデルにクエリさせてください。Anthropicは、1,862行の公開CSVに対して25の集計質問¹⁵（合計、フィルタ付きカウント、グループ化、日付フィルタ）を行い、正解はpandasで計算しました。

プロンプトに貼り付けると、表は毎リクエスト約91,000入力トークンになり、Claude Sonnet 5は25問中6問に正解しました。アップロードしてコード実行を使うと25問すべてに正解し、実行コストは約12分の1でした。Claude Opus 5も同じパターンを示しました。

コンテキストのライフサイクルを管理する

コンテキストのレバーは、それを必要とするほど長いセッションでのみ効果があります。

20イシューの実行では何も節約されず、コンテキスト編集は74%高くなりました。長い実行ではプルーニングが39%、コンパクションが32%節約し、コンテキスト編集は何も変えませんでした。プルーニングは自分で書く数行のコードです。各タスクの境界で、大きな古いツール結果を1行の抜粋に置き換えます。編集が会話の末尾、つまり次のタスクがどうせ新しいコンテンツを追加する場所にあるため、キャッシュとの相性が良く、境界後の最初のリクエストで89%、境界間のリクエストで81%のキャッシュ読み取りでした。実行全体では、プルーニングとコンテキスト編集のキャッシュ効率はほぼ同等です。プルーニングのほうが安いのは、プルーニングが削除するコンテンツをコンテキスト編集はタスク途中で再書き込みするため（差の約3分の2）、そしてコンテキストを約半分のサイズに保つため（残りの3分の1）です。コンテキスト編集を使う場合は、少数の大きなバッチでクリアしてください。ハーネスから抜粋したプルーニングは次のとおりです。

import re

PRUNED = "[pruned at issue boundary]"


def prune_task_boundary(messages, tool_name_by_id, threshold=2000):
    """Call once per task boundary. Replaces large, stale search results with a one-line extract."""
    for message in messages:
        if message["role"] != "user" or not isinstance(message["content"], list):
            continue
        for block in message["content"]:
            if not (isinstance(block, dict) and block.get("type") == "tool_result"):
                continue
            if tool_name_by_id.get(block.get("tool_use_id")) != "search_issues":
                continue
            result_text = block.get("content")
            if not isinstance(result_text, str) or len(result_text) <= threshold:
                continue
            if result_text.startswith(PRUNED):
                continue  # already pruned on an earlier boundary
            # 抽出結果を短く保つため、単一行の結果に上限を設ける
            first_line = result_text.split("\n", 1)[0].strip()[:200]
            refs = re.findall(r"#(\d+)", result_text)[:5]
            extract = f"{PRUNED} {first_line}"
            if refs:
                extract += " kept refs: " + " ".join("#" + r for r in refs)
            block["content"] = extract

待てる作業をバッチ処理する

Batch APIは、結果が24時間以内のいつかに届くことと引き換えに、キャッシュ済みのものを含むリクエストのすべてのトークンを50%割引します。誰も待っていないリクエストはすべてバッチ経由にし、残りはインタラクティブな経路に残してください。バッチ処理は、無人のエージェント作業、つまり評価実行、バックフィル、トークントリミングの測定のイシュートリアージエージェントの定期実行のようなスケジュールジョブにとって、キャッシングに次いで2番目に大きな無償のレバーです。このページのインタラクティブ性以外のすべてと組み合わせられますが、設計上インタラクティブであるClaude Managed Agentsのセッションでは利用できません（Claude Managed Agentsの料金を参照）。

現在のモデルに対してプロンプトを監査する

モデルの世代ごとにプロンプトへの反応は異なるため、プロンプトにはもう使っていないモデル向けに書かれたテキストが蓄積していきます。よくあるのは、古いモデルを補うために追加された過度に具体的な指示です。「2回検証せよ」「最大限徹底的に」、必須のステップバイステップ手順、手作りの推論用スクラッチパッドなどです。新しいモデルはこれらを文字どおりに従い、余分なツールラウンドと余分な記述を生み出すため、精度の向上なしに請求額が上がります。今実行しているモデルに対してプロンプトを監査し、モデルを変更するたびに再度監査することは、無償の改善です。

監査はコマンド1つです。Claude Codeに同梱されているClaude APIスキルにはprompt-auditコマンドがあり、プロジェクトのプロンプトとリクエストコードを読み、別のモデル向けに書かれたものを報告します。この短縮した抜粋は、それらのパターンを含むサポートデスクのプロンプトとリクエストコードに対して実行した様子です。

$ claude
> /claude-api prompt-audit

10 findings. The three that matter most:

1. budget_tokens returns a 400 on Opus 5 (support_agent.py:10). This code
   does not run against its own target model. Everything else here is
   quality; this one is an outage.
2. The prompt contains two live contradictions. Line 15 says confirm before
   every refund, line 17 says process every eligible refund immediately.
   Line 19 asks for a complete recap *and* a three-sentence maximum.
3. The reasoning scaffold and the 6-step script fight the model rather than
   steer it. <scratchpad> + "reason step by step" is now a request
   parameter, not prose; the mandatory 6-step procedure plus "investigate
   fully even when the ticket looks simple" forces four tool calls on a
   "where's my package" ticket.
...
-After any refund or escalation, verify twice before submitting: re-fetch
-the order, re-check every figure in your reply against the fresh lookup,
-and review the reply a second time for errors.
+Before submitting a refund or an escalation, re-fetch the order and confirm
+every figure in your reply matches the fresh lookup.

コマンドはその後、編集案をdiffとして提示し（1つのハンクを表示）、意図的に手を付けなかったもの、つまり返金期間、トーンの要件、品質基準を一覧します。レビューするのは書き直しではなくパッチです。

効果は測定可能です。サポートデスクの評価¹⁴では、Claude Opus 4.8向けに書かれたプロンプトはClaude Opus 5でチケットあたり36%高くなり、精度は変わりませんでした。同じプロンプトに監査を実行すると、Opus 5は監査前のバージョンより安く（14%）、かつ精度も高く（チケットの97%、92%から上昇、ノイズの範囲外の向上）なりました。Claude Sonnet 4.6からClaude Sonnet 5への移行では、監査により同じ精度で14%削減されました。

2種類の古いテキストはコストの種類が異なります。新しいモデルが文字どおりに従いすぎる指示はお金がかかります。「2回検証せよ」を削除するとOpus 5のチケットあたりコストが3分の1減り、「最大限徹底的に」を削除してもほぼ同程度でした。モデルに合わなくなったテキストは代わりに精度を損ないます。廃止済みの思考設定、矛盾するルール、モデル自身の思考と衝突する手作りのスクラッチパッドは、削除するとそれぞれOpus 5で7から11ポイントを回復しました。

同じパターンはツールの説明やスキルにも現れがちで、それらも監査する価値があります。

コストとインテリジェンスをトレードオフする

これらのレバーは、単一のモデルがコストとインテリジェンスの間のどこに位置するかを決めます。モデル選択、エフォート、より高い設定での失敗の再実行、そしてその中で動作する予算と上限です。まず現在のモデルでエフォートのスイープから始めてください（エフォートを調整する）。コストと能力の低い順に、現行モデルはClaude Haiku 4.5、Claude Sonnet 5、Claude Opus 5、Claude Fable 5.1（フロンティアモデル）です。全ラインナップと価格はモデル概要にあります。

タスクあたりのコストでモデルを比較する

価格表はトークンあたりで書かれており、トークンあたりではフロンティアモデルは高価に見えます。Claude Fable 5.1のトークンあたり価格はClaude Sonnet 5の数倍です。しかし支払うのは完了したタスクに対してなので、完了タスクあたりのコストでモデルを比較してください。より高性能なモデルはより少ない作業でタスクを終えます。ターンが少なく、検索が少なく、自身のコンテキストの再読み取りが少なく、後戻りが少なくなります。トークンあたりのプレミアムは、あらゆることを少なく済ませることでしばしば打ち消されます。

AnthropicはこれをSWE-bench Pro³のサブセットで、顧客への課金どおりに価格評価して測定しました。

lowエフォートのClaude Fable 5.1は解決済みタスクあたり$0.54でタスクの88.6%を解決し、デフォルトのClaude Sonnet 5は$0.84で77.4%でした。トークンあたり価格が5倍高いにもかかわらず、11ポイント多く、解決済みタスクあたり35%安くなりました。ただし常に勝つわけではありません。両モデルがほぼ飽和しており、スコアが公開リーダーボードと比較できない同じサブセットで、Claude Opus 5単体はデフォルトでClaude Fable 5.1単体に並び（91.7%対92.1%、実行間のノイズの範囲内）、解決済みタスクあたり約15%安く（$1.01対$1.19）、lowのOpus 5は$0.25で84.0%を解決しました。また、長いリサーチループではフロンティアモデルは作業が少なくなるのではなく多くなります。DeepResearch Bench II⁷では、lowのFable 5.1はSonnet 5より10ポイント高いスコア（66%対56%）でしたが、より大きなコンテキストでより長いリサーチループを実行するため、タスクあたりのコストは約4倍（$4.66対$1.20）でした。デフォルトのClaude Opus 5は同じ基準でタスクあたり$6.71で71%のスコアで、デフォルトのFable 5.1（$7.12で65%）を上回ったため、リサーチでもFable 5.1がその価格に見合うのはlowのときだけです。

ほとんどのエージェントワークロードでは、lowエフォートのClaude Fable 5.1から始め、取りこぼすところでエフォートを上げてください。トークンあたりでは、キャッシュされていない入力でClaude Opus 5の2倍かかりますが、キャッシュ済み入力では半分（100万あたり$0.25対$0.50）で、エージェントループではキャッシュ済み入力が最大の項です。アドバイザー戦略のコーディングベンチマークでは、mediumのFable 5.1がデフォルトのOpus 5に試行あたり約3分の1のコスト（$2.91対$8.50）で並びました。チャート読み取りベンチマークのChartography¹³では、lowのFable 5.1がチャートあたり$0.15で62.5のスコアで、lowのOpus 5は$0.38で49でした。SWE-bench Proのサブセットでは、前述のとおり、デフォルトのClaude Opus 5が最高スコアへのより安い道であり続けます。反対の端では、Claude Haiku 4.5はGPQA Diamond⁹の質問にOpus 5の質問あたりコストの約10分の1で回答し、精度はOpusの92%に対して63%で、長いコーディングタスクではさらに大きく後れを取りました。長いエージェントループではなく、出力を検証できる大量の作業に向いています。

順位はワークロードによって逆転し、どの価格表もどちらに転ぶかは教えてくれません。Claude Opus 5とエフォートを下げたフロンティアモデルを含め、すべての候補を自分のトラフィックで完了タスクあたりのコストで価格評価してください。

中央値ではなくワークロードのテールを価格評価してください。典型的なタスクではなく、最も難しい10分の1のタスクでモデルを比較します。典型的なタスクではどのモデルも似たように見え、最も安いものが最良に見えますが、請求額は安いモデルが失敗するタスクで決まります。失敗したタスクもトークンが課金され、次に再試行が、そして失敗が下流で引き起こすコストが課金されるからです。何も失敗しない場合でも、お金が流れるのはテールです。20問のWideSearch¹の実行では、2問が支出の43%を占めました。

マルチモデル戦略は、残りにフロンティア料金を払うことなく、そのテールにフロンティアのインテリジェンスを費やすために存在します。

モデルをアップグレードする

1つか2つ前のモデルを使っている場合、最も安いレバーはモデル文字列です。Anthropicは最近のClaude Opus、Claude Sonnet、Claude Fableの各モデルを、それぞれ出荷時のデフォルトで定価で価格評価し、SWE-bench Pro³のサブセットで同じハーネスにかけ、OpusのラインをTerminal-Bench 3²⁰でも再度実行しました。

AnthropicはOpusのラインをバージョン間でトークンあたり同一価格にしているため、差はすべて各モデルがタスクあたりどれだけ作業するかから生じます。顧客への課金どおりに価格評価すると、Claude Opus 4.8はClaude Opus 4.7と同じ割合のタスクを解決済みタスクあたり14%安く解決し、Claude Opus 5はさらに12ポイント多くのタスクを解決済みタスクあたり21%高く解決します。lowエフォートのClaude Opus 5は、このベンチマークでOpus 4.8のデフォルトを解決済みタスクあたりコストの約30%で上回るため、最も安いアップグレードは新しいモデルを低い設定で使うことです。Sonnet 5の節約はトークンあたり価格の低さから来ており、Sonnet 4.6と比べてタスクあたりに使う追加トークンを十分に相殺します。5ポイント多く、解決済みタスクあたり15%安くなります。フロンティアティアも同じように向上しました。Claude Fable 5.1はClaude Fable 5のスコアに解決済みタスクあたり43%安く並び、その大部分はキャッシュ読み取り価格の低さによるものです。この方向は保証されていません。DeepResearch Bench II⁷では、同じアップグレードは、すべてのアームでクリーンなタスク（参照7）での2から3ポイントの上乗せに対して、highでタスクあたり41%高く（lowでは79%高く）なります。新しいモデルがそこではタスクあたりより多くの作業をするためです。入力と出力の価格は同じでキャッシュ読み取りは4倍安いので、節約になると決めつける前に自分のワークロードでアップグレードを測定してください。

より難しい作業では差が広がります。タスクが十分に難しく、トークンではなく合格率が請求額を決めるTerminal-Bench 3²⁰では、Claude Opus 4.7、Opus 4.8、Opus 5はそれぞれタスクあたり$8から$15を費やしますが、タスクの7%、15%、41%を解決するため、解決済みタスクあたりのコストはラダーを上がるにつれて$183から$63、$28へと下がります。飽和したコーディングサブセットでClaude Opus 5がOpus 4.8に対して持つ21%のプレミアムは、古いモデルがほとんど失敗するTerminal-Bench 3では56%の節約になります。ワークロードが古いモデルを打ち負かすほど、アップグレードは結果あたりでより多く節約します。

トークンあたりではなく解決済みタスクあたりのコストで比較してください。同じテキストはClaude Opus 4.7以降では約30%多くのトークンになるため、トークンあたりの比較では構造的に新しいモデルのほうが高価に見えます。

エフォートを調整する

「effort」（エフォート）は、モデルをタスクに合わせて調整する最も直接的な手段です。effortパラメータは、モデルが行う思考、ツール呼び出し、自己検証の量を制御し、デフォルト（high）は要求の厳しいタスクに適しています。コストはそうした活動すべてに応じて増加しますが、精度が向上するのはタスクが必要とする部分に対してのみです。モデルの能力上限を下回る領域では、最も高いエフォートレベルは、タスクが決して使わない深さに対して料金を支払うことになります。

リサーチおよびナレッジワークのベンチマーク（WideSearch¹、DeepWideSearch⁶、BrowseComp⁴、GDPval²、いずれもClaude Fable 5を使用）では、コストに対する精度の曲線はほぼ平坦です。lowはタスクあたりのコストを3分の1から半分削減する代わりに1〜3ポイントを失い、mediumはデフォルトの約70%〜87%のコストでデフォルトと同等の精度を達成し、デフォルトは4つのいずれにおいてもmediumに対して測定可能な上積みを何ももたらしませんでした。DeepWideSearchでは、lowはClaude Sonnet 5ワーカーを使ったオーケストレーターにも29%低いコストで並びました。つまり、エフォートを下げることがアーキテクチャの変更に勝ったのです。

低いエフォート設定は多くの場合より高速でもあり、これは「latency」（レイテンシ）が制約となる場合に重要です。これらの実行では、DeepWideSearchにおいてlowは1問あたり4.5分かかったのに対し、デフォルトでは7.9分でした。入力がどの単一の「context window」（コンテキストウィンドウ）にも収まらないコーパスベンチマークでは、Fable 5.1はlow、medium、highでそれぞれ1エピソードあたり15.2時間、17.5時間、19.9時間かかりました。

長期的なコーディングこそ、エフォートが本当に精度を買える領域です。SWE-bench Pro³では、Claude Opus 5はmediumで半分のコストと引き換えに約2ポイント、lowで4分の1のコストと引き換えに約8ポイントを失いました。これは本物のトレードオフであり、失敗したタスクをより高いエフォートで再実行することで再び節約に変えられます。次のチャートは、リサーチおよびナレッジワークのベンチマークとSWE-bench Proについて、コストに対する精度をプロットしたものです。

ここから2つの帰結が導かれます。第一に、2つ目のモデルを追加する前に、自分のワークロードでこの曲線を描いてください。これらの社内測定では、デフォルトの単一モデルより安く見えたマルチモデル構成は、同じモデルを低いエフォートで使う場合よりも高くつきました。第二に、この曲線はあらゆるマルチモデル戦略が上回らなければならない単一モデルのベースラインであり、そのため自分のワークロードで測定する手順のステップ2ではエフォートレベル全体にわたってベースラインを取ります。

難しい作業が自動的に高いエフォートを必要とするわけではありません。DeepResearch Bench II⁷では、Claude Fable 5.1はlow、medium、highでほぼ同じスコアを記録した一方、タスクあたりのコストは$4.66から$7.12に上昇しました。つまりこのケースでは、エフォートを上げても出力の品質は目に見えて向上しません。すべての条件で問題なく完了した21タスク（参考文献7）では、Claude Fable 5もエフォート全体で平坦でしたが、各モデル自身の途中で打ち切られた試行を除外したチャートの33タスク基準では上昇しているように見えます。曲線は、前回測定したモデルではなく、実際に出荷するモデルで測定してください。

タスクの説明だけでは、自分のワークロードがどちらの種類かはわかりません。そのため、自分のトラフィックのサンプルで2〜3のエフォートレベルをスイープし、曲線から答えを読み取ってください。各レベルは別々のセッションでテストしてください。セッションの途中でトップレベルのエフォートを変更するとキャッシュが無効になり（繰り返されるコンテキストをキャッシュするを参照）、比較が歪みます。パラメータの詳細については、エフォートを参照してください。

失敗したタスクをより高いエフォートで再実行する

タスクの結果が検証可能な場合、エフォート曲線上で最も安価な方針は固定の設定ではありません。すべてのタスクを低い設定で実行し、失敗したものだけをより高い設定で再実行するのです。

Anthropicは、エフォートを調整するで扱ったSWE-bench Pro³サブセットのエフォート実行から、この方針をタスクごとに計算しました。Claude Opus 5をlowで実行すると16%のタスクが失敗しました。それらをデフォルトで再実行すると、1件あたり約$0.45で約93%が合格しました。これに対し、すべてをデフォルトで実行した場合は$0.93で91.7%でした。失敗した安価な試行を含めても、同じ合格率を半分のコストで達成したことになります。代わりにmediumから始めると、約$0.61で約94%を解決しました。わずかな上昇分の大半は2回目の試行によるものです（デフォルト自身の失敗をデフォルトで再実行しても、より多くの費用でほぼ同じスコアになります）。したがって、この方針は上昇分のためではなく節約のために使ってください。

2つの条件があります。第一に、失敗シグナルが必要です（ここではベンチマーク自身のテスト）。不良な成果物を合格させてしまうチェッカーは、それらの失敗を素通りさせます。第二に、初回で失敗したタスクはすべて2回分の実時間を要するため、節約の代償は失敗したタスクにおけるレイテンシとして支払われます。

予算と出力上限を設定する

エージェント型タスクの実行の大半は安価ですが、少数の実行は検索、再検証、過剰なテストに中央値の何倍ものコストを費やします。タスク予算はそのテール（裾）を狙います。モデルはタスク全体に対するリアルタイムのトークンカウントダウンを見て自己調整し、価値の低い検索を削り、冗長な検証を省き、際限なく迷走する代わりに作業をまとめ上げます。

Anthropicは、予算を厳しくしていった際のSWE-bench Pro³における合格率とタスクあたりのコストを、Claude Fable 5.1で測定しました。

余裕のある予算は、実行間ノイズの境界程度である約3ポイントの合格率と引き換えにタスクあたりのコストを44%削減し、許容される最も厳しい予算は6ポイントと引き換えに58%削減しました。ここでは予算が効率を買いましたが、その代償となる合格率の低下は予算を厳しくするほど大きくなります。

3つの制御手段は3つの異なる役割を果たします。タスク予算は、モデルがそれを見るため、費用を節約します。max_tokensは安全上限です。これを下げると試行あたりのコストは下がりましたが、解決済みタスクあたりのコストは下がりませんでした。Claude Managed Agentsでは、セッション予算がその両方の背後にあるドル建てのハードストップです。3つすべてを設定してください。タスク予算、高めのmax_tokens、そして請求書に決して載せたくない実行のためのセッション上限を設定し、最後の防波堤としてワークスペースの支出制限を置きます。

• タスク予算は最新のモデルでベータ版（ベータヘッダーtask-budgets-2026-03-13）として提供されています。どのモデルが対応しているかはサポート表を確認してください。ループの90パーセンタイルのトークン使用量付近から始め、そこから厳しくしていきます（その分布の収集方法は予算の選び方に示されています）。現在の下限である20,000トークンを下回る予算は拒否され、非常に厳しい予算は拒否に似た挙動を生むことがあります。タスク途中の変更はキャッシュを無効にするため、予算は最初のリクエストで一度だけ設定してください。予算は助言的なものであり、モデルを停止させるのではなく誘導するものなので、自分のワークロードで遵守状況を検証してください。
• **max_tokens**は単一のレスポンスに上限を設けますが、モデルからは見えないため、これを下げてもモデルが節約するようにはなりません。その余地を必要としていたターンは破棄され、それでも課金されます。社内のリポジトリタスクベンチマーク¹²では、16,384トークンの上限はデフォルトのエフォートでClaude Opus 5の試行の15%、Claude Fable 5.1の試行の43%を打ち切り、上限に達した117件のFableの試行のうち合格したのはわずか9件でした。上限に達した実行は試行あたりの支出は少なかったものの、それに比例して解決数も少なかったため、解決済みタスクあたりのコストは64,000の場合とほぼ同じでした（$21対$22）。64,000では、デフォルトのエフォートで約14,000ターンのうち2ターンが依然として打ち切られ、Fable 5.1は36.3%ではなく58.5%のタスクを解決しました（参考文献12で説明されているSWE-bench Pro³サブセットの別の切り出しでは差はなく、どちらの上限でも100件中94件でした）。上限に達した試行を再試行してもほとんど役に立ちません。同じ上限ではその大半が再び失敗し、より高い上限では無駄になった試行の分も支払うことになります。エージェント型の作業ではmax_tokensを64,000に設定し、1回の打ち切りが高くつく場合は最大値の128,000に設定してください。128,000ではFable 5.1は解決済みタスクあたり同じコストで60.0%を解決しました。これほど大きなレスポンスはストリーミングし、stop_reason: max_tokensを失敗として扱い、費用の節約はモデルから見えるエフォートとタスク予算で行ってください。
• Claude Managed Agentsのセッション予算はハードストップです。セッション予算は、トークン、検索、セッション時間の定価に基づく、1セッションに対するドル建ての上限です。上限に達するとセッションはstop_reason: budget_reachedで一時停止し、予算を引き上げると再開します。これはプラットフォームによって強制され、タスク予算がまだ利用できないモデルを含め、定価のあるあらゆるモデルで機能し、助言的なタスク予算と組み合わせられます。デプロイメントは同じフィールドをすべての実行に適用します。

より短い回答を求めてください。Claude Sonnet 5では出力トークンは入力トークンの5倍のコストがかかり、エージェントループではモデルが書いたすべてのトークンが以降のすべてのターンで入力として戻ってくるため、長い回答に対して何度も繰り返し支払うことになります。Anthropicは、同じモデルとツールを使い、3種類の最終回答指示のもとでトリアージジョブをそれぞれ3回実行しました。元の指示は2行を求めていました。

4. Finish with exactly two lines:
LABEL: <one of: bug-confirmed, needs-more-info, duplicate-candidate, feature-request, upstream-issue, perf, ui-polish>
SUMMARY: <one or two sentences for the engineering team>

短い方のバリアントは1行を求めました。

4. Finish with exactly one line in this form:
DECISION | LABEL | REASON
where DECISION is one of: triage-now, needs-info, close-duplicate; LABEL is one of: bug-confirmed, needs-more-info, duplicate-candidate, feature-request, upstream-issue, perf, ui-polish; REASON is one clause under 15 words. Output nothing after that line.

長い方のバリアントは、問題の要約、証拠、重複チェック、推奨ラベル、次のステップという5つの見出し付きセクションからなるメモを求めました。ある1件のissue（スキップされた質問の後にキューに入ったプロンプトが送信されないというもの）について、最初の2つの回答は次のとおりでした。

LABEL: bug-confirmed
SUMMARY: When a user submits a new prompt instead of answering an agent's pending question, the question is cancelled/skipped but the new prompt remains stuck in "QUEUED" state indefinitely since it's waiting on a response to the now-cancelled question; the queued prompt should be processed immediately after cancellation.

triage-now | bug-confirmed | Clear repro steps show prompt queues indefinitely after cancelled question.

1行の回答は2行の元の形式より出力トークンが39%少なく、1回あたりのコストは14%低くなりました。メモは6倍の出力トークンを使い、1行の回答の2.8倍のコストがかかりました。3つともゴールドラベルに対するスコアは互いに実行間ノイズの範囲内だったため、形式の違いは正答率よりも支払う金額にはるかに大きく表れます。徹底して見える回答ではなく、実際に読む回答を求めてください。

低い方のmax_tokens上限では、どちらのモデルも試行あたりの支出は少なくなりますが、それに比例して解決するタスクも少なくなるため、解決済みタスクあたりのコストはほとんど動きません。

ほぼすべてのターンはどちらの上限よりもはるかに下で終了します。高い方の上限が買うのは、まれに発生する長いターンです。

モデルを組み合わせる

マルチモデルアーキテクチャは、タスクの複雑さが十分にばらついており、異なるステップに異なるモデルが最適となるワークロードに適しています。トラフィックに、小さなモデルが確実に処理できる定型作業と、フロンティア級の能力を必要とする難しいステップが混在している場合、作業を分割することで、フロンティアの知能を重要な箇所に残しつつ、大半のトークンを小さなモデルの料金で課金できます。難易度が均一である、あるいは1本の依存関係の連鎖であるといった理由でワークロードにその混在がない場合は、通常、よく調整された単一モデルの方が良い選択です。各戦略のセクションでは、この2つのケースを見分けるためのルールを示します。

2つの戦略でほとんどのワークロードをカバーでき、両者はどのモデルがメインループを保持するかで異なります。

アドバイザー戦略：難しい判断をエスカレーションする

アドバイザー戦略では、低コストのエグゼキューターモデルがエージェントループを実行し、大半のターンを処理します。アプローチの選択や失敗からの回復など、より深い判断を要する決定に突き当たると、より高い知能を持つアドバイザーモデルを呼び出して戦略的な指針を得てから続行します。大半のトークンはエグゼキューターの料金で課金され、時折の相談だけがアドバイザーの料金で課金されます。

これを使うには、リクエストにアドバイザーツールを追加します。このベータ機能は戦略全体を1回の/v1/messagesリクエスト内でサーバー側で実行します。エグゼキューターがツール呼び出しを発行し、Anthropicがアドバイザーの推論を実行し、エグゼキューターがその助言を受けて続行します。オーケストレーションコードを書く必要はありません。Claude Managed Agentsでは、エージェントのmultiagentロスターにadvisorエントリを追加することでセッションにアドバイザーを与えます。セッションのプライマリスレッドは同じ方法でそれに相談します。Claude Codeもこれをサポートしています。アドバイザーツールで難しい判断をエスカレーションするを参照してください。

見返りを決めるもの。 アドバイザーはエグゼキューターの呼び出しを通してしかタスクを見ないため、どれだけ役立つかは2つの要素で決まります。

1つ目はモデル間のギャップです。アドバイザーが渡せるのはエグゼキューターに欠けている能力だけです。GPQA Diamond⁹では、Claude Haiku 4.5エグゼキューターはClaude Opus 5アドバイザーから大きな恩恵を受け、Claude Sonnet 5エグゼキューターは数ポイントを得、フロンティアエグゼキューターはほとんど何も得ませんでした。

2つ目は、そして脆いのはこちらですが、エグゼキューターが実際に尋ねるかどうか（相談率）です。低いエフォートのエグゼキューターは、自分が行き詰まっていることを検知しなくなることがあります。デフォルトのエフォートでは大半のタスクで相談するペアリングが、エフォートを下げるとほとんど相談しなくなり、その結果エグゼキューター単独よりも低いスコアになることがあります。この率はタスクによっても変わります。DeepSWE¹⁰では低エフォートのSonnet 5エグゼキューターは尋ね続けて23ポイントを得ましたが、SWE-bench Pro³では同じエグゼキューターが尋ねるのをやめました。エグゼキューターが実際に尋ねる場合、ギャップの多くを取り戻します。次のチャートのペアリングのうちエグゼキューターが尋ね続けたものでは、アドバイザーはより強いモデルとのギャップの少なくとも半分を埋め（コーディングのペアリングはより強いモデルを完全に上回りました）、しかもより強いモデルに支払うのは相談の分だけです。これがコスト面での成立を可能にしています。

相談率はプロンプトに反応します。ツールの組み込みの説明だけでは、エグゼキューターは特にコーディング作業で呼び出し不足になるため、アドバイザーツールのドキュメントでは、実質的な作業の前に1回、終了前に1回の呼び出しを求める「system prompt」（システムプロンプト）を提示しており、タスクあたり約2〜3回の呼び出しになります。次に測定したコーディングのペアリングはそのペースで実行され、すべてのタスクで約2回の相談を行いました。そのページでは、呼び出し不足のエグゼキューターを促す方法や、コストを抑えるためにクライアント側で呼び出し回数に上限を設ける方法も扱っています。したがって相談率を監視してください。プロンプトでそれを促し、測定し、崩れた場合はエグゼキューターのエフォートを元に戻してください。

コスト面で見合う場合。 アドバイザーが費用を節約するのは、アドバイザーの料金で課金される少数の短い相談が、タスク全体にわたってアドバイザーのモデルを実行することを置き換える場合です。これはアドバイザーのモデルの価格がエグゼキューターよりかなり高い場合に最もうまく機能するため、最もコスト効率の高い構成は中位のエグゼキューターの上にフロンティアのアドバイザーを置くものです。ペアリングは価格帯の最上位でも引けを取らないことがあります。助言はエグゼキューターのトークンも節約するからです。正しいアプローチを教えられたエグゼキューターは行き止まりの探索が減り、それで相談の費用を賄えることがあります。

社内のエージェント型コーディングベンチマーク¹¹（素のAPIエージェントで実行）では、Claude Opus 5エグゼキューターとClaude Fable 5.1アドバイザーの組み合わせが、測定した中で最も精度の高い構成で、試行あたり$7.69でした。これは各モデル自身のエフォート設定を通る線の上方に位置します。デフォルト設定のOpus 5単独よりわずかに少ない費用で3.5ポイント上回り（このギャップはタスクあたり5回の試行でノイズから分離できます）、アドバイザーのモデル単独よりも約1.5倍の費用で約2.5ポイント上回りました。

Claude Codeのアドバイザーモードを通じた以前の測定でも同じ順序になりました。この結果は、自分のワークロードでテストすべき形として読んでください。アドバイザーはエグゼキューター自身の価格程度で数ポイントを買います。能力のギャップが広いからといって、より良い取引が保証されるわけではありません。レイテンシのコストは相談そのものです。このベンチマークではタスクあたり約2回の追加のフロンティアモデル呼び出しがあり、それぞれがタスクのクリティカルパス上にあります。

より強いモデル単独の方が良い一手である場合。 ワークロードの精度がエフォートに反応する場合は、ペアリングを構築する前に、設定を下げたアドバイザーのモデル単独と比較してください。アドバイザーに支払うのはそれを必要とするタスクだけですが、大半のタスクで発火する相談は、より強いモデル自体を実行するよりも高くつきます。Chartography¹³では、同じペアリングはmediumのClaude Fable 5.1単独と実行間ノイズの範囲内で並びましたが（65.0対67.5）、タスクあたりのコストは約2.6倍でした。アドバイザーがほぼすべてのタスクで相談を受けたためです。まず自分の相談率を測定してください。エグゼキューターが大半のタスクで尋ねるなら、ワークロード全体にわたってアドバイザーの料金を支払っていることになり、アドバイザーのモデル自体を実行する方が同じスコアへのより安い道です。

どのペアリングであれ、まず低いエフォートでのアドバイザーのモデル単独の価格を出してください。それが上回るべきベースラインです。モデルのリリースごとに再確認してください。リリースは能力のギャップと価格比の両方を動かすからです。

適する場合。 アドバイザー戦略は、ターンの大半は機械的だが優れた計画が重要なワークロードに適しています。コーディングエージェント、コンピュータ操作、多段階のリサーチパイプラインなどです。すべてのターンが本当にフロンティア級の能力を必要とする場合、計画すべきものがない場合（単一ターンのQ&A）、あるいはエグゼキューターがすでにアドバイザーの能力に近い場合には適しません。

オーケストレーター戦略：大量の作業を委任する

オーケストレーター戦略では、フロンティアモデルがループを保持します。タスクを分解し、サブタスクを低コストのワーカーモデルにディスパッチし、その結果を統合します。トークンを大量に消費する探索はワーカーが吸収するため、オーケストレーター自身のトランスクリプトは短く保たれ、大半のトークンはワーカーの料金で課金されつつ、計画と統合は依然としてフロンティアモデルから得られます。

これを構築するには、Claude Managed Agentsのマルチエージェントオーケストレーションを使用します。コーディネーターエージェント（オーケストレーター）と、それぞれ独自のモデルを持つワーカーエージェントのロスターを設定します。フロンティアのコーディネーターとClaude Sonnet 5ワーカーを使った完全な動作例については、Claude Cookbookのレシピコーディネーターパターン：計画には大きなモデル、実行には小さなモデルを参照してください。

このパターンは、ワーカーが並列に実行できる場合に実時間を節約します。コーパスベンチマーク⁸では、コーディネーターがプラットフォームの文書化された上限である25の同時ワーカーを実行した場合、1エピソードは約2.3時間で済んだのに対し、単独では15〜20時間かかりました。費用を節約したのは、測定した中で2つの状況だけでした。単一モデルが単独で処理できる作業では、同じモデルを低いエフォートで使う方が毎回安価でした。

ケース1：定型作業におけるコストのテールに対する保険。 単独で実行されるフロンティアモデルは、通常なら解決する定型的な問題で時折迷走します。どれがそうなるかを事前に知ることはできないため、そうした少数の実行が請求額を支配します。定型作業を低コストのワーカーに渡すコーディネーターはそのテールに上限を設けます。迷走が起きてもワーカーの料金で起きるからです。

Anthropicはこれを、意図的に簡単にしたBrowseComp⁴のスライス（単独モデルが確実に解く10問。委任実行50回、単独実行70回）で測定しました。Claude Sonnet 5ワーカー1つを持つClaude Fable 5コーディネーターは、平均でClaude Fable 5単独の約半分、90パーセンタイルでは約3分の1のコスト（$12対$33）で済み、単独モデルの最も高額だった1回の実行（$84）は答えも間違っていました。

委任が見合ったのは、作業のうち定型的で通常は解決可能な部分であり、ワーカーは難しい問題のためのものだという直感とは逆でした。より難しいBrowseCompの全セットでは、経済性は逆転しました。トラフィックに定型タスクでの長いコストのテールがあるなら、これが最初に測定すべきオーケストレーターのケースです。

ケース2：コンテキストウィンドウ1つ分より大きな作業。 単独モデルはそれほど大きな入力を、コンテキストウィンドウ1つ分ずつ直列に処理しなければならず、パスごとに自身の状態を読み直すための費用を支払います。ワーカーはそれぞれ自分のパーティションを、並列に、ワーカーの料金で読みます。読み取りの多い作業でも1つのコンテキストウィンドウに収まるなら、それは委任の問題ではなくモデル選択の問題です。読み取りコストだけで見れば、オーケストレーターが優位に立つのは、単一のコンテキストでは作業を保持できない場合だけです。

Anthropicはこのケースのためのベンチマーク⁸を構築しました。14の公開Pythonパッケージからなる2,160万トークンのコーパスに130の欠陥を仕込んだもので、どのコンテキストウィンドウにも大きすぎます。請求額はコーパスの読み取りそのものなので、エフォートを下げても役に立ちません。Claude Fable 5.1単独は3つのエフォート設定にわたって1エピソードあたり$468〜$552かかり、動いたのは精度だけでした。コーディネーター構成（25のClaude Sonnet 5ワーカーを率いるClaude Fable 5.1リード）は、それらの設定の約半分のコスト（47%〜55%減）で、スコアはそれらより10〜12ポイント低く、1エピソードあたり15〜20時間に対して約2.3時間で済み、Claude Sonnet 5単独のベースラインは完全に上回りました。

トークンの内訳は読み取りの規模を示しています。コーディネーター構成は1エピソードあたり約5億6,000万のキャッシュ済みトークンを読み取り、これは単独モデルの約3億6,500万の約1.5倍で、そのほぼすべてがClaude Sonnet 5のキャッシュ読み取り料金でしたが、それでも全体のコストは約半分でした。highエフォートのFable 5.1は依然として最高精度を保持しており、そのコストはコーディネーター構成の約2.2倍です。したがって、ここでの委任は精度の大半を買いますが、すべてではありません。

委任が見合わない場合。 オーケストレーターが何かを買えるのは、渡すべき大量の作業がある場合だけです。多数の独立した部分、理想的には1つのコンテキストウィンドウには多すぎるほどの部分です。作業が1本の依存関係の連鎖である場合、あるいは単一のコンテキストに収まる場合、オーケストレーターは、単一モデルなら無料で得られる計画、引き渡し、統合に対して支払うことになります。測定したそのようなケースのすべてで、コーディネーターのモデル単独を低いエフォートで使う方が優位でした。

境界はベンチマークではなくタスクの難易度です。より難しいBrowseComp⁴の全セットでは、Claude Fable 5単独がコーディネーター構成の精度に22%〜30%低いコストで到達しました。独立した外部の研究も同じパターンを報告しています⁵。作業が1本の連鎖である、長いコストのテールなしに1つのコンテキストに収まる、あるいは低いエフォートの単一モデルがすでに基準を満たしているなら、オーケストレーターを構築しないでください。

戦略を選ぶ

ほとんどのケースは1つの問いに帰着します。作業は独立した部分に分割できるのか、それとも依存するステップの連鎖を経て到達する1つの答えなのか。戦略の表は、この2つの答えを2つの戦略に対応付けています。

確信が持てないなら、まだ何も構築しないでください。

1. まず現在のモデルでエフォートをスイープします。これはこのページで最も安価な実験であり、ほとんどのワークロードはそこで終わります。
2. スイープでギャップが見つかったら、低いエフォートでのより強いモデル単独の価格を出します。それがアドバイザーのペアリングが上回らなければならない数字であり、このページでそれを上回ったペアリングは、エグゼキューターが実際に相談したものでした。

このページのマルチモデルの結果は、同じモデルを低いエフォートで使った場合、および1つ下のモデルを単独で実行した場合と比較して評価されました。それが自分のワークロードで実行すべき比較であり、最初のステップがエフォートのスイープである理由です。

実際にアドバイザーを追加する場合、それは再アーキテクチャではなくツール定義の追加です。

自分のワークロードで測定する

このページの数値は測定時点の定価を反映しており、モデルと価格が変わるにつれてずれていきます。エスカレーション率、タスクがどれだけきれいに分割できるか、トランスクリプトの長さもそれらを動かします。方法は変わりません。

1. 本番ログから実際のトラフィックと同じ重み付けでいくつかのタスクを抽出し、それぞれに結果チェックを書きます。テストが通る、チケットがクローズされる、行数が正しい、などです。スコアの横にタスクあたりのコストを記録します。各レスポンスのusageにある5つの課金対象トークン数をそれぞれの料金で価格付けし（キャッシュなし入力、入力価格の1.25倍と2倍の5分および1時間キャッシュ書き込み、キャッシュ読み取り、出力）、タスクのリクエスト全体で合計します（Usage and Cost APIは集計値を報告します）。
2. デフォルトだけでなくエフォートレベル全体にわたってモデルの各ティアのベースラインを取り、支出に対するスコアをプロットします。マルチモデル構成は単一モデルの曲線全体を上回らなければなりません。
3. 曲線にエフォートでは埋められないギャップが見られる場合は、適合するマルチモデル戦略を追加してスイートを再実行します。
4. 切り替え前にトラフィックの一部で勝者をシャドー実行し、その後もスイートを実行し続けます。

次の例は、Claude Opus 5の定価で1つのリクエストのステップ1のコストを計算します。

# 料金ページの100万トークンあたりの価格。別のモデルの場合はこの3つを変更してください。
INPUT_PER_MTOK = 5.00  # Claude Opus 5
# 入力価格の0.1倍。Claude Fable 5.1とClaude Mythos 5.1では0.025倍
CACHE_READ_PER_MTOK = 0.50
OUTPUT_PER_MTOK = 25.00

client = anthropic.Anthropic()
response = client.messages.create(
    model="claude-opus-5",
    max_tokens=1024,
    messages=[{"role": "user", "content": "Hello, Claude"}],
)
usage = response.usage
cache_writes = usage.cache_creation
writes_1h = cache_writes.ephemeral_1h_input_tokens if cache_writes else 0
writes_5m = cache_writes.ephemeral_5m_input_tokens if cache_writes else 0
cost = (
    usage.input_tokens * INPUT_PER_MTOK
    # 1時間キャッシュ書き込みは入力価格の2倍、5分は1.25倍で課金。読み取りはキャッシュ読み取り価格。
    + writes_1h * INPUT_PER_MTOK * 2.0
    + writes_5m * INPUT_PER_MTOK * 1.25
    + (usage.cache_read_input_tokens or 0) * CACHE_READ_PER_MTOK
    + usage.output_tokens * OUTPUT_PER_MTOK
) / 1_000_000
print(f"Request cost: ${cost:.6f}")

エージェントループでは、通常5つのうちキャッシュ読み取りの項が最大になります。そうでない場合は、キャッシングが有効になっているか確認してください。アドバイザーツールまたはコンパクションが有効な場合、一部のトークンはusage.iterationsにのみ報告され、トップレベルの合計には含まれないため、代わりにusage.iterationsを合計し、advisor_messageエントリはアドバイザーモデルの料金で価格付けしてください。

次の表は、試すべき順序でレバーを一覧にしたものです。

参照したベンチマーク

参照先に別途記載がある場合を除き、測定値はこれらのベンチマークをAnthropic社内で実行した結果です。特に注記がない限り、コストは各ベンチマーク実行時点で有効だった定価に基づく米ドル建てです。Claude Sonnet 5の数値は、入力トークン100万あたり$2、出力トークン100万あたり$10を使用しています。「notional USD」（名目米ドル）と表示されたチャートは、請求書の金額を報告するのではなく、各リクエストのトークン数をこれらのレートで価格付けしたものです。

1. WideSearch: Wong et al., "WideSearch: Benchmarking Agentic Broad Info-Seeking," arXiv:2508.07999, 2025。多数の行を持つ表の完全性と正確性で採点される広範なウェブリサーチタスク。200問、構成ごとに3回実行、2026年8月1日から2日に実行。コスト集中チャートは別途の20問の実行で、1問あたり3回実行、2026年8月3日から4日に実行し、リクエストごとの請求記録からコストを算出しています。
2. GDPval: OpenAI, "GDPval: Evaluating AI Model Performance on Real-World Economically Valuable Tasks," 2025。タスクのルーブリックに照らして採点されるナレッジワークの成果物。公開されたゴールドセットの210タスクの実行で、タスクごとに1回の試行、2026年8月2日に実行。Claudeモデルが採点するため、絶対スコアは公開結果と異なる場合があります。
3. SWE-bench Pro: Scale AI, "SWE-Bench Pro: Can AI Agents Solve Long-Horizon Software Engineering Tasks?", 2025。Anthropicの評価ハーネスとの互換性のために選定した482問のサブセット。スコアは公開リーダーボードと比較できません。デフォルトのeffortでのClaude Opus 5は2回の実行の平均、effortを下げた設定は単一実行で、すべて2026年8月4日に実行しました。エスカレーションの数値はこれらの実行からタスクごとに得ています。まずlow、次にその失敗分にデフォルトを適用した場合、実行の組み合わせ全体で92.5%から93.6%を解決し約$0.45。まずmediumの場合、93.8%から94.2%で約$0.61。デフォルトを自身の失敗分に再実行した場合、94.0%で$1.06。すべてデフォルトの場合、90.9%から92.5%で$0.93。このサブセットのコストは、顧客の組織が計量されるのと同じ方法で価格付けしています。各リクエストの以前のプロンプトをキャッシュ読み取りとして、新しいトークンを5分間のキャッシュ書き込みとして、実行自体の使用量記録から算出し、顧客の台帳と照合しました。キャッシュを8,192トークンのページ単位で請求する評価用組織自体の計量では、1.4倍から1.8倍高い数値となりました。アドバイザーチャート上のClaude Sonnet 5エグゼキューターの組み合わせは、このサブセットでの同じ測定シリーズから得ています。Sonnet＋Opusの組み合わせは2回実行（2026年8月7日と8月8日、1回の実行とその正確な再現）、低effortの組み合わせは1回（2026年8月8日）、Claude Sonnet 5単独は2回（77.4%、Proの両行のベースライン）です。「モデルをアップグレードする」におけるClaude Fable 5のポイントは、デフォルトのeffortでの3回の実行の平均で、2026年8月26日に実行し、同じ方法で価格付けしています。Claude Fable 5.1のタスク予算の数値は、同じサブセットでデフォルトのeffortにて予算ごとに1回の実行（35,000トークンでは2回）、2026年8月26日に実行し、同日の予算なしの実行（92.1%、タスクあたり$1.10）をベースラインとしています。それ以前のlow effortでのセットは2026年8月21日に実行し、予算なしで88.6%、タスクあたり$0.48でした。モデルを比較するの比較では、その単一実行を同じサブセットからプールした2回のClaude Sonnet 5実行と組み合わせています。Fable 5.1のデフォルトのeffortでは、この組み合わせは逆の結果となり、解決済みタスクあたりSonnet 5より41%高くなります。アップグレードの階段は、各モデルを出荷時のデフォルトで1回ずつ実行したもの（Opus 5とSonnet 5はそれぞれ2回、Fable 5のポイントは上記のとおり）で、OpusとSonnetの実行は同じ週に1つのハーネスと組織で行いました。
4. BrowseComp: Wei et al., "BrowseComp: A Simple Yet Challenging Benchmark for Browsing Agents," OpenAI, 2025。effortの数値は500問のカットを使用し、設定ごとに1回から3回実行、2026年8月3日に実行、デフォルトのポイントは2026年7月26日から27日の2回の実行をプールしています。コスト保険チャートは、26問のスライスから確実に解決される10問を使用し、委任実行50回（2026年8月1日から2日）と単独実行70回（2026年8月2日から3日の50回、2026年7月12日から13日および8月1日からアーカイブした20回）で、期待値で1実行あたり$6.45対$11.99です。委任の数値には約20%の測定幅があります。
5. エージェントアーキテクチャのスケーリング: Kim et al., "Towards a Science of Scaling Agent Systems," arXiv:2512.08296, 2025。独立した外部研究で、委任が割に合わない場合に関する知見の方向性についてのみ引用しており、いかなる数値についても引用していません。
6. DeepWideSearch: "DeepWideSearch: Benchmarking Depth and Width in Agentic Information Seeking," arXiv:2510.20168, 2025。220問は15のドメインにまたがり、それぞれが多数行の収集とマルチホップ検索を組み合わせています。ベンチマークの常設の行セットで測定し、構成ごとに3回実行、2026年8月2日に実行しました（単一ワーカーのチームポイントは2026年7月26日から27日に実行）。
7. DeepResearch Bench II: Li et al., "DeepResearch Bench II: Diagnosing Deep Research Agents via Rubrics from Expert Report," arXiv:2601.08536, 2026。22のドメインにわたる132のリサーチタスクが、専門家由来の二値ルーブリックに照らして採点されます。全テーマにわたって層化した50タスクのサブセットで測定し、タスクごとに1回の試行、設定ごとに3回実行、Claude Managed Agents上でプラットフォーム自体のウェブ検索およびフェッチツールを使用しました（2026年8月26日から27日）。どの構成も拒否しなかった33タスクで採点し、本番の安全性分類器が途中で打ち切った試行は除外しています。コストは顧客に請求される金額、すなわちプラットフォームのリクエストにウェブ検索料金を加えたものです。スコアは、各モデル自身の打ち切られたタスクを除いた33タスクベースでの各モデルの平均です。すべてのアームでクリーンだった21タスクでは、Claude Fable 5.1はすべてのeffortレベルでClaude Fable 5に対して2から3ポイントのリードを保ち、両モデルともeffort全体で横ばいです。キャッシングチャートは、同じリクエストをすべての入力トークンを非キャッシュレートで再価格付けしたものです。Claude Opus 4.6がベンチマークのルーブリックプロトコルに従って判定します。オリジナルは別の判定者を使用しており、Anthropicの判定者は自社のスタイルを好む可能性があります。デフォルトのeffortでのClaude Opus 5は、同じサーフェスとサブセットで3回、2026年8月28日に実行しました。生の50タスクで68.8%、33タスクベースで70.8%、21タスクセットで71.1%、タスクあたり$6.71（キャッシングなしでは$23.72）でした。その試行はいずれも安全性分類器によって打ち切られませんでしたが、これは他のモデルが実行された際のものより新しいセーフガードのデプロイメント下でのことです。
8. コーパス欠陥スイープ: Anthropic社内、1つのコンテキストウィンドウより大きな作業向け。14の公開Pythonパッケージソースからなる2,160万トークンのコーパスに130の欠陥を埋め込み、決定論的に採点します。プロトコルは実行前に固定し社内でレビュー済み、構成ごとに3回実行。すべての構成はClaude Managed Agents上で実行しました。チャートに示したチーム構成は、Claude Fable 5.1コーディネーターがプラットフォーム内で、文書化された上限である25の同時Claude Sonnet 5ワーカーでスイープ全体を実行したもので、2026年8月30日に実行しました。その3つのエピソードは、追加分の監査後にF1 0.764、0.825、0.791（生の値は0.751、0.821、0.781）を記録し、コストは$225、$234、$283でした。Claude Sonnet 5単独構成は2026年8月3日から4日に実行しました。Claude Fable 5.1単独構成は2026年8月24日から25日に、プラットフォームのローンチ時のサービング設定下で、effort設定ごとに3シード、同じコーパスビルドで実行しました。サンドボックスイメージにはコーパスの一部のインストール済みコピーが含まれており、Claude Fable 5.1の最終組み立てステップは9エピソード中7エピソードでそれらと比較しました。それらの追加分を除いて再採点すると、影響を受けたシードは最大3ポイント動きました。絶対F1はこのコーパスビルドに固有のもので、ベンチマーク間で比較できません。構成の比較は同一条件です。
9. GPQA Diamond: Rein et al., "GPQA: A Graduate-Level Google-Proof Q&A Benchmark," 2023。198問のDiamondサブセット、構成ごとに2回実行、2026年8月7日に実行、参照解答に照らしてモデルが採点、アドバイザートークンはリクエストごとに計量。プラットフォームの安全性チェックがSonnetおよびOpusエグゼキューターで生物学の2問を拒否しました。それらを除外しても、どの比較も1ポイントを超えて変化しません。
10. DeepSWE: Datacurve, "DeepSWE: Measuring Frontier Coding Agents on Original, Long-Horizon Engineering Tasks," arXiv:2607.07946, 2026。このセットには5つの言語にわたる113のオリジナルタスクがあり、プログラムベースの検証器が付いています。組み合わせはそれぞれ2回実行、2026年8月7日に実行、アドバイザートークンはリクエストごとに計量し、アドバイザーツールではなくクライアント側のアドバイザーループを使用しましたが、会計処理は同一です。単一モデルのeffortスイープは単一実行で、トークン数から価格付けしたキャッシュを考慮した近似値です。タスクあたりのコストは実行合計を113で割ったものです。
11. 社内エージェント型コーディングベンチマーク: Anthropic社内。リポジトリ自体のテストで採点される370のリポジトリタスク。APIの数値は128,000トークンの出力上限で測定し、構成ごとに1回実行しました。デフォルトのeffortでのOpus 5単独は2026年8月9日から10日、明示的に設定した5つのeffort値でのClaude Fable 5.1単独は2026年8月20日、組み合わせは2026年8月24日から25日です。タスクあたりの試行回数は、組み合わせとOpus単独の対照で5回、単一モデルのポイントで1回です。組み合わせは試行あたり平均約2回のアドバイザー相談を行いました。コストは試行あたりです。Claude Codeの数値は、2026年7月8日から23日に同じタスクを実行したもので、構成ごとに1回実行、コストは概算です。
12. 社内リポジトリタスクベンチマーク（上限測定）: 約130のリポジトリタスクからなる別のAnthropic社内セットで、2026年8月8日から10日（Claude Opus 5）および2026年8月20日（Claude Fable 5.1）に、プレーンなAPIエージェントループでタスクごとに1回の試行で実行しました。Claude Fable 5.1の実行は、デフォルトのeffortを明示的に設定し、上限ごとに135タスクです。16,384トークンの数値は2回の実行の平均（両方とも36.3%）、64,000と128,000の数値は単一実行（58.5%と60.0%）です。6問はすべての実行で安全性拒否を受け、失敗として数えています。Opus 5の16,384トークンの数値は2回の実行の平均で、64,000の数値は単一実行（124タスクを採点）です。SWE-bench Proの上限の数値は、デフォルトのeffortで上限ごとにClaude Fable 5.1を1回実行したもので、2026年8月26日に、参照3の482問セットから層化した100問のサブセットで実行しており、そのスコアとは比較できません。2つの上限はデフォルトで同じスコアでした。チャートのターンごとの分布は、64,000でのOpusの実行と128,000でのClaude Fable 5.1の実行から得ています。Opusのターンで上限に達したものはなく、Fable 5.1のターンの1つが128,000に達しました（そのターンの0.46%が16,384を超えました）。
13. Chartography: Surge AI, "Chartography," 2026。公開された100問の完全なセットを、2026年8月8日から10日に、Claude Managed Agents上のAnthropicの実装で測定しました（標準クラウドサンドボックス。アドバイザー構成はManaged Agentsのアドバイザーを使用）。参照判定者の代わりにClaude Sonnet 4.6が採点し、ベンチマークはツール付きで実行されるため、スコアはここでの構成間では比較できますが、公開リーダーボードとは比較できません。構成ごとに2回実行しプール。実行間のばらつきは4から10ポイントでした。コストにはサンドボックス時間を含みませんが、これは1%未満の追加でした。Claude Fable 5.1単独の実行は2026年8月24日のもので、プラットフォームのローンチ時のサービング設定下で、設定ごとに2回実行しました。6つの試行が15分のセッション上限に達してスコア0となり、実行ごとに2つのチャートは安全性拒否の後にClaude Opus 5が回答しました。Claude Fable 5.1アドバイザー付きのClaude Opus 5低effortエグゼキューターは、2026年8月30日に同じ設定下で2回実行しました（63.0と67.0、平均65.0、チャートあたり$0.72。アドバイザーは各実行でタスクの88%で相談を受け、その219件の返答のうち4件は代わりにClaude Opus 5からのもので、いずれも本番の安全性フィルターがアドバイザー自身の返答を停止した後のものです）。以前の組み合わせの相談率の比較は、2026年8月10日から11日に、同じ構成をコンテナツールセット付きのMessages APIで再実行したものから得ています。
14. サポートデスクのプロンプト監査評価: Anthropicが構築した44件のサポートチケットのセットで、決定論的に採点し、2026年8月初旬に実行して2026年8月8日に報告しました。6つのシステムプロンプトの下で実行し、それぞれが同じクリーンなプロンプトに、Claude Opus 4.8およびClaude Sonnet 4.6向けに書かれたプロンプトでよく見られるパターンを1つ追加しています。各チャートポイントは、3つのケース（旧モデル、同じプロンプトでの新モデル、監査後の新モデル）のいずれかを、6つのプロンプトと44件のチケットで平均したものです。Opus 5の精度向上の95%信頼区間は3から8ポイントです。Sonnetの精度差はノイズの範囲内です。
15. データファイル質問セット: 公開されている酒類販売CSVの1,862行のスライスに対する25の集計質問からなるAnthropicが構築したセットで、正解はpandasで計算し完全一致で採点、Claude Sonnet 5とClaude Opus 5で思考を無効にして実行しました（コンテキスト内アームはデフォルトでは完了できません）。4,000トークンの出力上限、プロンプトキャッシングなし、構成ごとに3回実行、2026年8月19日に実行。ファイルアームはFiles APIを通じてCSVをアップロードし、code_execution_20260120ツールを使用します。
16. キャッシュ期間の測定: 入力トークンとコンテキストトークンを削減するの20件のイシュートリアージジョブを、2026年8月23日に、Claude Sonnet 5とClaude Opus 5でMessages API上で同じハーネスを使って実行しました。Claude Opus 5のセルはmax_tokensを4,096に引き上げ、ランダムに選んだ割合のターンの前に一時停止を挿入しました（両モデルで全20件のイシューに対し、なし、5%、10%、および全ターンで6分。加えてClaude Sonnet 5で全ターン2分。両モデルで5件のイシューのサブセットに20分の一時停止。Claude Sonnet 5のみで5件のイシューのサブセットに45分の一時停止）。セルごとに3回実行、コストは顧客請求の組織で各レスポンスのusageフィールドから定価で計算、精度は同じゴールドラベルに照らして評価。クロスオーバーは両モデルでターンの約3.3%です。これは、分析対象のClaude Sonnet 5の45セッションとClaude Opus 5の36セッション（いずれも20件のイシュー）すべてにわたる、各セッションの損益分岐割合の中央値で、コストモデルがそのセッションのターンごとのコンテキストサイズから計算したものです（フルジョブで実行したすべての一時停止スケジュール、3つのキャッシュ設定すべて、各3回実行。5件のイシューのセルは含まれません）。5%のセルはClaude Sonnet 5で同点でしたが、これはその抽選の一時停止が小さなプレフィックスに当たったためです。このページの20回に1回のルールは、測定されたクロスオーバーより上にあります。Anthropicは、5分間のキャッシュを更新するキープアライブリクエストを比較対象としてのみ測定しました。それらは最良でも1時間設定と同等で、全ターンの前に一時停止がある場合はより高コストだったため、これら2つのモデルでは使用しないでください。Claude Fable 5.1では計算が逆転します（参照19）。
17. 本番環境でのキャッシュ読み取りの割合: 2026年8月23日までの14日間のファーストパーティClaude API使用量の集計で、直接API製品のみ、Anthropic社内組織を除外、組織は特定していません。組織日は、そのリクエストがツール定義とツール結果を含み、プロンプトが平均9回以上の以前のツール呼び出しを保持し、キャッシングが使用され、そのようなリクエストを少なくとも10回行った場合にエージェントループとして数えます（APIには会話識別子がないため、これが会話の長さの代わりとなります）。106,487組織にわたる303,003組織日で、キャッシュ読み取りの割合の中央値は全入力トークンの84.2%、上位四分位は91.7%です。ユースケースラベル（組織が申告したユースケース、またはそれ以外の場合は分類されたもの）は、これらの組織日の74%とそのトークンの99%をカバーしています。コーディング組織はエージェント型入力トークンの87%を供給し、中央値88.5%を読み取り（以前のツール呼び出しが25回以上では90.9%）、上位四分位は93.4%で、コーディング組織日の約72%が80%以上です。サポート、リサーチ、データのエージェントは84%から85%を読み取ります。組織日の上位十分位は、コーディングで95.9%以上、サポート、リサーチ、データ、その他のエージェントで94.2%から94.8%を読み取ります。以前のツール呼び出しが25回以上でのリクエストレベルの内訳は6時間のサンプルから得ています。コーディングは92%が読み取り、7%が書き込み、1%未満が非キャッシュです。ラベルのない組織は大半が小規模で、中央値11%を読み取ります。ツール定義のない組織日は中央値34.6%を読み取ります。組織日を採点するのではなく、10リクエスト以上の会話を再構築する同じ期間に対する独立したクエリでは、中央値は90.2%となります。この差はスコープによるもので、データによるものではありません。
18. コンパクションのタイミング測定: 入力トークンとコンテキストトークンを削減するのトリアージエージェントの長いバリアントを、2026年8月24日に、Claude Sonnet 5で5分間のキャッシュを使って実行し、コストはusageフィールドから定価で算出、アームごとに5セッションです。全体を通してデフォルトのeffortの変更なしアーム（セッションあたり$0.81）と、低effortで開始して同じ2つのキャッシュを破壊する変更（デフォルトのeffortへの切り替えと1つのツール追加）を、セッション途中のリクエスト12と17で行うアーム（$0.95）、または最初のコンパクション後の最初のリクエストでまとめて行うアーム（$0.75）の2つです。2026年8月25日に実行した6セッションの4番目のアームは、最初のコンパクションをトリガーしたリクエストで同じ2つの変更を行いました（セッションあたり$0.92）。そのリクエストの要約パスは81,000トークンのコンテキストを読み取る代わりにキャッシュに書き込んだため、そのパスのコストは$0.21で、境界アームでの同じパスの$0.04と対照的でした。セッションは、プロンプトが80,000トークンのコンパクショントリガーを超えた時点で、リクエスト21から25で最初にコンパクションされ（21セッション中16セッションがリクエスト22）、変更なしの2セッションは終わり近くで2回目のコンパクションを行いました。境界アームの合計が変更なしアームより低いのは、キャッシングではなく、変更前の低effortリクエストとそれらの2回目のコンパクションを反映しています。2つのアームの再書き込みコストの差は1セント未満です。セッション途中アームはキャッシュ再書き込みにセッションあたり$0.23を支払いました。セッション途中アームと境界アームの差は$0.20で、95%信頼区間は$0.11から$0.29でした。セッション途中の1セッションは、コンパクション後にモデルが検索ツールを誤って呼び出して空の結果を得たため、安価（$0.82）に実行されました。これは含まれており、これを除くとアームの平均は$0.98です。精度は8月24日の各アームで20ラベル中平均14.2、8月25日のアームで14.7でした。キャッシュ読み取りは、変更なしでプロンプトトークンの91%、セッション途中で85%、境界で91%、トリガーリクエストでの変更で86%でした。
19. Claude Fable 5.1でのキャッシュ期間の測定: 参照16と同じ20件のイシュートリアージジョブとハーネスを、2026年8月23日と8月26日に、Claude Fable 5.1のローンチスナップショットでローンチ価格（100万トークンあたり入力$10、5分間書き込み$12.50、1時間書き込み$20、キャッシュ読み取り$0.25、出力$50）にて実行し、スケジュールごとに3つの設定です。5分間のキャッシュ、1時間のキャッシュ、およびアイドル時間4分ごとに変更のないプレフィックスに対するmax_tokens: 0リクエストでウォーム状態を保った5分間のキャッシュです（8月23日の実行はmax_tokens: 1でpingしました。8月26日のすべてのpingはキャッシュを更新し、出力は請求されませんでした）。スケジュールは、全20件のイシューに対し一時停止なし、ターンの10%、全ターンで6分、および5件のイシューのサブセットに45分の一時停止です。セルごとに3回実行、コストは各レスポンスのusageフィールドから定価で計算、精度は同じゴールドラベルに照らして評価（20中12から17の完全一致ラベル）。8月26日の5分間、1時間、キープアライブ設定のセッションあたり平均は、一時停止なしで$2.42、$3.09、$2.29、10%一時停止で$4.50、$2.96、$2.36、全ターンで$22.89、$3.01、$2.62です。8月23日のセルは6%以内で一致します。45分の数値（5件のイシューのセッションあたり$1.68、$0.59、$0.71）は、キャッシュ請求のインシデントがその日の最初のセルを損なった後の8月26日のクリーンな再実行からのものです。8月23日の実行では$1.67、$0.58、$0.70でした。5分間設定と1時間設定の間のクロスオーバーはターンの3.1%で、参照16と同じ指標です。
20. Terminal-Bench 3: 公開されているターミナルエージェントベンチマークの74タスクを、Claude Managed Agents上で、プラットフォームの組み込みツールの代わりに、評価ハーネスが各タスク自身のコンテナ内で実行する2つのカスタムツール（シェルとファイルエディター）を使用し、それ以外は外部アカウント向けのプラットフォームのデフォルト設定で、モデルごとにhigh effortで2回、2026年8月27日から28日に実行しました。スコアはモデルごとの148試行に対する生の合格率です。単一実行は5から11ポイント変動します。コストは顧客が定価で請求される金額で、実行の使用量記録から5分間のキャッシュ有効期間でリクエストごとに再価格付けしています。Claude Opus 4.7は148試行のうち11試行を出力上限で終了しました。

次のステップ