コーディングエージェントのマルチモデルルーティング

コーディングエージェントにマルチモデルルーティングが及ぼす影響

マルチモデルルーティングでは、各リクエストを処理可能なモデルのうち最も安価なものへ送ります。チャットのトラフィックでは効果的です。しかし、コーディングエージェントでは、節約額を上回るコストが発生することが一般的です。エージェントの料金の大部分は、モデルごとにキャッシュされるプロンプトプレフィックスが占めています。モデルを切り替えると、そのキャッシュが破棄されるためです。

この投稿で示すルールは次のとおりです。可用性を確保するためにプロバイダー間でルーティングし、コスト削減のためにティア間でルーティングするのはタスクの境界に限り、エージェント処理ではセッションごとに1つのモデルを固定します。以下では、その理由を説明します。

ここでは4つの用語を定義します。ルーターは、リクエストごとにモデルを選択します。ゲートウェイは、リクエストが通過するプロキシです。ルーティング機能を備えている場合もあります。プロンプトキャッシュは、プロバイダーがプロンプトの処理済みプレフィックスを保存する仕組みです。同じプレフィックスを含む後続のリクエストは、入力料金の一部だけが課金されます。KV キャッシュ（key value cache）は、自分で運用するサーバー内部で使われる同じ仕組みです。

チャットのトラフィックは適切にルーティングできるのに、エージェントのトラフィックでは難しい理由

チャットのリクエストは 1 ターンです。リクエストが到着し、分類され、モデルに送られ、応答が返ります。次のリクエストに内容が引き継がれることはありません。ルーターはこの質問を小規模モデルに送り、次の質問を大規模モデルに送れます。どちらのリクエストも、もう一方が処理されたことを認識しません。ほぼすべてのルーティングベンチマークが測定しているのは、このワークロードです。優れたルーターは、この処理を実際に適切に行えます。

エージェントの 1 ターンは、1 つのリクエストではありません。「失敗しているテストを修正して」という 1 つの指示が、20〜60 回の API 呼び出しになります。各呼び出しでは、システムプロンプト、すべてのツール定義、エージェントが読み取ったすべてのファイル、確認したすべてのコマンド出力を含む、会話全体が再送信されます。コンテキストは増え続けます。30 回目の呼び出しでは、繰り返し送信されるプレフィックスが数万トークンになる一方、各呼び出しで実際に追加される内容は数百トークンにすぎない場合があります。

この構造により、「高コスト」という言葉の意味が変わります。チャットでは、コストはおおむねモデルの料金にリクエスト数を掛けたものです。エージェントループでは、コストの中心はプレフィックスです。プレフィックスは、すべての呼び出しで再び課金されます。以降の説明は、この 1 つの事実から導かれます。

プロンプトキャッシュはモデルごとに分かれ、エージェントはその内部で動作します

Anthropic は、キャッシュ読み取りを基本入力料金の 0.1 倍、5 分間のキャッシュ書き込みを 1.25 倍で課金します。これは 2026 年 8 月時点で公開されている定価です。

[
  {
    "label": "Opus 5",
    "uncached_input_usd": "5.00",
    "cache_read_usd": "0.50"
  },
  {
    "label": "Sonnet 5",
    "uncached_input_usd": "2.00",
    "cache_read_usd": "0.20"
  },
  {
    "label": "Haiku 4.5",
    "uncached_input_usd": "1.00",
    "cache_read_usd": "0.10"
  }
]

2 つ目の系列は、列方向ではなく行方向に、1 つ目の系列と比較してください。Opus 5 でキャッシュを読み取る場合、100 万トークンあたり 0.50 ドルです。掲載モデルの中で最も安い Haiku 4.5 におけるキャッシュされていない入力は、1.00 ドルです。つまり、最も高価なモデルでウォームなプレフィックスを再読み取りするほうが、最も安価なモデルで同じプレフィックスをコールド状態から読み取るより、入力トークンあたりの費用が低くなります。

この 1 つの比較だけで、ほとんどのルーティング計画は成立しなくなります。ルーターが処理を下位ティアへ移す場合、比較しているのは定価です。しかし、セッション途中のエージェントは、現在使用しているモデルの定価を支払っていません。キャッシュ読み取り料金を支払っています。この料金は、安価なモデルのキャッシュされていない入力料金をすでに下回っています。

キャッシュはプロンプトプレフィックスのハッシュをキーとし、モデルごとに分かれています。別のモデルへのリクエストは、そのモデルが一度も参照していないストアでハッシュ照合されるため、キャッシュが見つからず、全額を支払うことになります。キャッシュは階層構造でもあります。順序は、まずツール、次にシステム、最後にメッセージです。どの階層でも変更すると、その階層と後続のすべてが無効になります。つまり、1 つのツール定義を編集すると、その後ろにあるシステムプロンプトのキャッシュも破棄されます。実行時にツールを登録するエージェントは、ルーターに触れなくてもこの問題に遭遇します。

セッション途中の切り替え1回に実際にかかるコスト

40,000 トークンの安定したプレフィックスを持つセッションを考えます。エージェントがいくつかのファイルを読み込んだ後では、一般的なサイズです。以下は、前述の定価から計算した、1 ターン分のプレフィックスコストです。

[
  {
    "label": "Opus 5, cache warm",
    "prefix_cost_usd": "0.020"
  },
  {
    "label": "Sonnet 5, turn after switch",
    "prefix_cost_usd": "0.100"
  },
  {
    "label": "Opus 5, cache re-warmed",
    "prefix_cost_usd": "0.250"
  }
]

ウォームキャッシュを使って Opus 5 のままにすると、そのターンのプレフィックスコストは 0.020 ドルです。Sonnet 5 へ切り替えた直後の最初のターンでは、0.100 ドルかかります。Sonnet にはこのプレフィックスのエントリがなく、新たに書き込む必要があるためです。Opus 5 に戻すと、0.250 ドルかかります。セッションが離れている間に、元のエントリの有効期限が切れるためです。

つまり、往復の切り替えでは、2 回のキャッシュ読み取りを避けるために、2 回のキャッシュ書き込みが発生します。一方、切り替えによって、1 ターン分の出力を Opus の価格ではなく Sonnet の価格で生成できます。詳細ブロックでは、この往復全体を計算しています。節約額は 1 セント未満ですが、キャッシュのペナルティは数十セントです。ペナルティは 1 桁以上大きく、プレフィックスが長くなるほど増加しますが、節約額は増加しません。

Opus 5, warm read     40,000 x $0.50 / 1e6  = $0.020
Sonnet 5, cache write 40,000 x $2.50 / 1e6  = $0.100   (1.25 x $2 base)
Opus 5, cache write   40,000 x $6.25 / 1e6  = $0.250   (1.25 x $5 base)

800 x ($25 - $10) / 1e6 = $0.012

プロバイダーによってツール呼び出しの形式は異なります

エージェントはツール呼び出しのループで動作するため、チャットの場合とは異なり、ツール呼び出しの形式が重要です。Anthropic の Messages API は tool_use コンテンツブロックを返し、戻り値として tool_result ブロックを要求します。OpenAI 互換 API は tool_calls 配列を返し、その中の function.arguments はネストしたオブジェクトではなく、JSON エンコードされた 文字列 です。ゲートウェイはこの2つの形式を相互変換します。通常の呼び出しであれば、変換に問題はありません。

問題は、特殊なケースで発生します。モデルが1回のレスポンスで複数の呼び出しを生成する並列ツール呼び出しは、プロバイダーごとに表現が異なり、対応状況も同じではありません。厳密なスキーマ適用はプロバイダー単位の機能です。そのため、あるエンドポイントで引数のスキーマ準拠が保証されるモデルでも、別のエンドポイントでは有効な引数になりやすい程度にとどまります。エージェントはこの違いを、解析エラーを含むツール結果として認識し、別のターンを使って修復しようとします。修復のターンにもプレフィックスの全額が課金されるため、形式の不一致はトランスクリプトだけでなく請求額にも現れます。

セルフホストのエンドポイントでは、この設定を明示的に行う必要があります。vLLM の OpenAI 互換サーバーでは、モデルファミリー（hermes、mistral、llama3_json など）に対応する --tool-call-parser と、--enable-auto-tool-choice が必要です。さらに、tool-role メッセージを処理できるチャットテンプレートも必要です。vLLM のドキュメントでは、この方式の制限を明確に説明しています。tool_choice="auto" を使用し、厳密なスキーマ制約を設定しない場合、vLLM は生のテキストからツール呼び出しを抽出するため、引数が不正な形式になったり、関数のパラメータースキーマに違反したりすることがあります。モデルに対して誤ったパーサーを選ぶと、エージェントがツールを呼び出せないという形で現れる設定エラーになります。トラフィックをそのエンドポイントへルーティングする前に、この点を把握しておくことが重要です。自分でモデルを提供する場合の Ollama と vLLM の違い もここで関係します。両者は異なる条件でツール呼び出しを公開しています。

タスクの途中でフォールバックが発生すると、エラーなしで動作が変わります

フォールバックルーティングは、意図せず有効になりやすい機能です。ゲートウェイが、最初のモデルからレート制限または 5xx が返された場合に別のモデルで再試行するよう設定されていると、失敗したモデルを数秒間クールダウン状態にします。チャットのトラフィックでは、これは適切な動作です。しかし、長時間実行するエージェントタスクでは、タスクの後半が選択していないモデルで実行されることを意味します。

この変更は、どこにも報告されません。タスクは失敗せず、エージェントも警告せず、終了ステータスも成功になります。実際には、計画を一方のモデルが作成し、編集を別のモデルが実行したタスクになります。途中で文体や作業上の慣行も変わります。信頼できる唯一の手掛かりは、ゲートウェイのリクエストログまたはレスポンスメタデータにある model フィールドです。そのため、フォールバックを使用する場合は、リクエストごとにこのフィールドを記録し、結果に予想外の点があるときに確認してください。どのモデルが生成したかを把握せずに動作をデバッグすると、フォールバックで節約した時間以上の時間を失います。

コンテキスト圧縮でも、同じ問題が発生します。多くのエージェントは、長い履歴を小規模なモデルの呼び出しによって要約します。その呼び出しに別のモデルまたは別のシステムプロンプトが指定されていると、メインセッションのキャッシュを更新せずに独自のキャッシュエントリを作成します。そのため、次の完全なターンでは、プレフィックスがキャッシュにない状態から処理することになります。圧縮によってトークンは節約できますが、キャッシュは失われます。

ルーティングのオーバーヘッドは現実にあるが、問題になるのはレイテンシではない

ルーターはリクエストごとに処理を追加します。その規模は正確に把握する必要があります。DigitalOcean によると、同社の Arch-Router モデルは、独自の評価でルーティング精度 93.17% を達成し、ルーティングの意図を約 51 ミリ秒で判定します。これは同社の測定とベンチマークによる数値であり、私たちの結果でも普遍的な結果でもありません。この数値をそのまま受け取るなら、結論は安心できるものです。エージェントの呼び出し 40 回で 51 ミリ秒を積み重ねても、数分かかるタスクに追加される時間は約 2 秒です。

ここでルーティングのコストを押し上げるのは 2 秒ではありません。影響が大きいのは、フルモデルの呼び出しで分類するルーターです。これはリクエストごとに 2 回目の推論を実行するため、通常の推論と同じように課金され、キューにも入ります。その下には、前述したキャッシュの計算があります。これはオーバーヘッドではありません。ルーティングが最適化するはずだった処理そのもののコストです。

自分で運用するサーバーでは、余裕がさらに小さくなるものの、同じ原則が適用されます。プロンプトキャッシュに相当するローカルの仕組みは、GPU メモリ上に存在する KV キャッシュのプレフィックスキャッシュです。1 台の GPU で 2 つのモデルをホスティングすると、そのメモリを両者で分けることになります。その結果、それぞれが保持できる KV キャッシュが小さくなり、プレフィックスが早く追い出されます。したがって、2 つのローカルモデル間でルーティングすると、両方のキャッシュヒット率が同時に低下する可能性があります。この用途でハードウェアを見積もるなら、ルーターよりも、VPS 上でコーディングエージェントが実際に必要とするメモリと CPU から始めるほうが有用です。

判断基準

• 可用性のためにプロバイダー間でルーティングします。 代替手段がリクエストの失敗である場合は、どのようなコストでも許容できます。エージェントのループを維持できるよう、フォールバック先には同じツール呼び出し形式のモデルを指定し、各呼び出しを処理したモデルをログに記録します。
• コストのためのティア間ルーティングは、タスクの境界でのみ行います。 rename には Haiku、refactor には Opus を選ぶのは、セッション開始前に1回だけ行う適切な判断です。そのセッションの30ターン目にモデルを選び直すのは、適切ではありません。
• エージェント処理では、セッションごとに1つのモデルを固定します。 セッションの価値は、ウォームキャッシュにあります。モデルの切り替えは、キャッシュのクリアと同じように扱ってください。実際にキャッシュをクリアするためです。
• サブエージェントは自由にルーティングします。 新しく小さなコンテキストで開始するサブエージェントには失うウォームキャッシュがないため、タスクに適したモデルで実行できます。エージェント内部でルーティングのコストがほぼ発生しないのは、ここだけです。

これを構築する場合、処理はゲートウェイに任せます。モデルエイリアスと明示的なフォールバックリストを使用します。最小構成の LiteLLM プロキシ設定は次のとおりです。

model_list:
  - model_name: agent-primary
    litellm_params:
      model: anthropic/claude-opus-5
      api_key: os.environ/ANTHROPIC_API_KEY
  - model_name: agent-standby
    litellm_params:
      model: anthropic/claude-sonnet-5
      api_key: os.environ/ANTHROPIC_API_KEY

router_settings:
  fallbacks: [{"agent-primary": ["agent-standby"]}]
  num_retries: 2
  cooldown_time: 30

エージェントの接続先を agent-primary にすると、そのモデルに到達できなくなるまで1つのモデルが使われます。2つのエントリは同じプロバイダー上にあるため、フォールバックが発生してもツール呼び出し形式は変わりません。その時点ではティアの変更を受け入れることになりますが、代替手段がリクエストの失敗であるため、このトレードオフには価値があります。これはコストのルーティングを伴わない可用性ルーティングであり、多くのコーディングエージェントが求める組み合わせです。キーと予算を含む完全な構築方法は、自分の VPS でセルフホスト LiteLLM ゲートウェイを運用するで説明しているため、この投稿では繰り返しません。

適切に選んだ 1 つのモデルが、どのルーターよりも優れる場合

ルーティングは、リクエストの難易度のばらつきに対する解決策です。コーディングエージェントでは、見た目ほどこのばらつきは大きくありません。リクエストの内容に関係なく、すべての呼び出しでコストの大部分を占めるのは同じプレフィックスだからです。プレフィックスが支配的になると、低価格ティアと高価格ティアの差は、出力価格の差に近づきます。しかも、エージェントのトークンに占める出力の割合は小さいものです。

そのため、基本方針としては、1 つのモデルを選び、キャッシュを有効にして、差分を読むために停止する時間をカバーできる十分に長い TTL（time to live）を設定するのが適切です。Anthropic では、基本入力料金の 2 倍で 1 時間のキャッシュ書き込みを利用できます。これは 2 回読み取れば元が取れるため、どのルーターよりも効果的な場合があります。Opus、Sonnet、Haiku を直接比較する ことでティアを慎重に選び、それでも請求額が問題になる場合は、セッション途中の切り替えではなく、VPS 上の AI エージェントのコストを管理する 方法に従って、予算とコンテキストを小さくして削減してください。

リクエストが独立していて短い場合、またはサブエージェントが新しいコンテキストで開始する場合は、ルーティングを使用します。1 つの長いセッションで 1 つの作業を続ける場合は、モデルを固定します。コーディングエージェントの作業の多くは後者です。そのため、チャット製品でコストを削減できるルーターが、ここでは気付かないうちにコストを増やすことがあります。まだエージェント自体を決めていない場合は、Claude Code、Cursor、Codex、Copilot の比較で、それぞれがモデル選択をどのように処理するかを確認できます。一部の製品では、この判断が自動的に行われます。

FAQ

セッション途中でモデルを切り替えると、本当にプロンプトキャッシュは失われますか？

はい。プロンプトキャッシュはプロンプトプレフィックスのハッシュをキーとしており、モデルごとに保存されます。そのため、別のモデルに送信したリクエストは、そのプレフィックスを一度も見ていないストアに対してハッシュ化されます。キャッシュは見つからず、キャッシュされていない入力料金を全額支払います。キャッシュが有効なら、そのうえでキャッシュ書き込み料金も発生します。元のモデルに戻しても、通常はデフォルトの 5 分間の有効期間が切れているため、元のエントリは復元されません。レスポンスの usage オブジェクトにある cache_read_input_tokens と cache_creation_input_tokens のフィールドを確認してください。長いセッションでキャッシュ済みトークン数が 0 になるターンが、その症状です。

エージェントで安価なモデルへルーティングすると、常に安くなりますか？

失うウォームキャッシュがない場合に限り、安くなります。Anthropic のキャッシュ読み取り料金は基本入力料金の 0.1 倍です。そのため、Opus 5 のウォーム読み取りは Haiku 4.5 のキャッシュされていない入力料金を下回ります。セッションに大きなキャッシュ済みプレフィックスがある場合、入力料金については現在のモデルのほうがすでに安価です。コンテキストが新しく小さい場合は、ルーティングによるメリットがあります。たとえばタスクの開始時や、必要なコンテキストだけを保持するサブエージェントです。

タスクの途中でエージェントの動作が変わったのはなぜですか？

ゲートウェイのフォールバックが発生していないか確認してください。プライマリモデルでレート制限または 5xx が発生すると、ゲートウェイはスタンバイモデルで再試行し、プライマリモデルを数秒間クールダウン状態にします。そのため、タスクの残りは別のモデルで実行されます。この場合、エラーも警告も表示されず、タスクは成功として報告されます。ゲートウェイのリクエストログまたはレスポンスメタデータにある model フィールドだけが信頼できる記録です。フォールバックを使用する場合は、リクエストごとに記録してください。

すべてのプロバイダーでツール呼び出しは同じように動作しますか？

完全には同じではありません。Anthropic の Messages API は tool_use と tool_result のコンテンツブロックを使用します。一方、OpenAI-compatible API は tool_calls 配列を使用し、その function.arguments は JSON でエンコードされた文字列です。ゲートウェイは一般的なケースを適切に変換しますが、並列ツール呼び出しと厳密なスキーマ適用の動作はプロバイダーごとに異なります。セルフホストの vLLM では、--enable-auto-tool-choice と、使用するモデルファミリーに対応した --tool-call-parser を設定する必要があります。vLLM のドキュメントにもあるとおり、厳密なスキーマ制約がない場合、サーバーは生テキストからツール呼び出しを抽出します。そのため、引数が不正な形式になることがあります。

コーディングセッションのキャッシュ TTL はどのくらいに設定すべきですか？

継続的に作業する場合はデフォルトの 5 分間を使用し、ターンの間に人が差分を確認する場合は 1 時間のオプションを使用してください。Anthropic の料金は、5 分間の書き込みが基本入力料金の 1.25 倍、1 時間の書き込みが 2 倍です。読み取り料金は 0.1 倍です。5 分間の書き込みは 1 回の読み取りで元が取れ、1 時間の書き込みは 2 回の読み取りで元が取れます。そのため、後で戻って作業を続ける予定のセッションでは、コールドプレフィックスの料金を支払い直すより、通常は長い有効期間のほうが安くなります。