OpenRouter AutoとAuto Code、どう使い分ける？

コーディングエージェントと汎用チャットボットを、同じルーター設定で動かす必要はありません。用途が混在するならopenrouter/auto、何往復も続くコーディングセッションならopenrouter/auto-codeが基本です。ただし注意点があります。解決できたタスクあたりのコストは、通常Auto CodeのほうがAutoより高く、「74%安い」という数字もOpus 5.5を比較対象にしたものです。

両ルーターは2026年11月5日に提供開始され、OpenRouterが2026年11月6日に発表しました。ルーティングエンジンは共通ですが、最初に選ぶモデルの価格帯と、失敗シグナルをセッションにどう反映するかが異なります。ルーティング手数料はなく、各リクエストには選ばれたモデルの通常料金が適用されます（OpenRouterの発表）。

用途が混在するならAuto、コーディングセッションならAuto Code

Auto Codeはコーディングエージェント向けのルーターです。より高い価格帯から開始し、成功率、速度、解決タスクあたりのコストを重視してモデルを選びます（OpenRouterの発表）。

すでに自分の用途に最適なモデルが分かっているなら、OpenRouter自身もそのモデルを使い続けるよう案内しています。ルーターは、すべてのリリースを追いかけなくても、コスト効率の良い選択を安定して得られる代わりに、ピーク性能を少し犠牲にする仕組みです（OpenRouterの発表）。

「74%安い」という数字はどこまで信頼できるか

方向性としては正しいものの、数字には但し書きがあります。「74%安い」という数字は、OpenRouterが実施した5つのベンチマークでAuto CodeとClaude Opus 5.5を比較したものです。Autoとの比較ではなく、第三者による検証でもありません。2026年11月6日、提供開始の翌日時点で、独立した再現結果は確認できませんでした（OpenRouterの発表）。

見出しだけでは分からない部分もあるので、発表に掲載されたベンチマークの全結果を示します。

この表から分かることは3つあります（OpenRouterの発表）。

1. Auto CodeがAutoのスコアを上回ったのは5項目中4項目です。ただしTau-bench Bankingでは52.6%対53.1%でAutoに負けています。差は2〜約5ポイントで、世代が変わるほどの飛躍ではありません。
2. Auto Codeは5タスク中4タスクでAutoより高コストです。TerminalBenchでは最大3.7倍（$4.96対$1.33）かかります。さらに、すべてのベンチマークで旧Auto Routerより高く、TerminalBenchでは8.1倍です。
3. 「安い」という主張が成立するのは、Opus 5.5との解決タスク単位の比較だけです。タスク単価にはリトライが含まれます。トークン単価が安いモデルでも2回失敗すれば、1回で成功する高価なモデルより解決タスク単価が高くなることがあります。エージェントには適した指標ですが、トークン単価が74%下がるという意味ではありません。

コミュニティの懐疑は、方向性よりも検証可能性に向いています。

「はっきりしているのは、74%という数字がOpenRouter独自の5つのベンチマークに基づくもので、第三者検証ではないこと。数字そのものではなく、方向性を信じるべきです」 — @LJL06019

別のユーザーは、再現性を左右する問いを投げています。「74%という数字は、プロンプトがルーターに何が難しいかを伝える場合にしか成立しないのでは。何が難しいかをルーターに伝えるのは誰なのか？」（@harden_369741）。

現時点では、次のように捉えるのが妥当です。5つのコーディング寄りベンチマークにおいて、Auto CodeはOpus 5.5クラスの性能を、より低い解決タスク単価で実現した。一方、素のスコアが最優先でない場合は、Autoのほうが安いルーターです。予算を組む前に、自分のリポジトリ群で再計測してください。

内部で本当に違うのは何か

エンジンは同じで、ポリシーが違います。両ルーターは1回の呼び出しごとに、タスクの種類、難易度、速度の重要性、画像やコードベースの知識が必要か、大きなモデルやより深い推論が有効かといった11個の要素を評価します。そこにリアルタイムの価格、プロバイダーの状態、プロンプトキャッシュの状況、ベンチマークデータ、セッション履歴を組み合わせます（OpenRouterの発表）。

Auto Codeは、そこにコーディング向けの重み付けを3つ加えています（OpenRouterの発表およびAuto Codeページ）。

• Autoのコスト効率重視のmediumティアではなく、より強力で高価なコーディングモデルのティアから開始する。
• レイテンシーをより強く評価し、コード変更の失敗を重く扱う。
• 編集がテストに失敗した場合や、同じエラーが繰り返された場合に、より早く別モデルへ切り替える。

セッションが行き詰まったときの切り替え順序も重要です。Auto Codeはまず推論の強度を上げ、それでも改善しない場合にモデルを変更します。OpenRouterによれば、この仕組みとセッションの固定性により、ベータ期間中はエージェントのターンの約9割で同じモデルを使い続けました。旧ルーターと比べて無効なツール呼び出しは4分の1になり、エージェント応答の途中打ち切りは半減しています（OpenRouterの発表）。ルーティングのp90レイテンシーも1.96秒から0.65秒へ、約3倍改善しました（OpenRouterの発表）。

Autoの汎用ルートはより古く、別途ドキュメント化されています。軽量な分類器が約30種類の細かなタスクタイプ（例：code:debugging、agent:multi_step_planning）を割り当て、タスクごとの直近7日間のコミュニティ利用額の割合でモデルを順位付けし、コストティアや各種制限を適用したうえで、メインモデルとフォールバックを選びます（Auto Routerのドキュメント）。新世代では、この市場シグナルにセッションのレイヤーが加わりました。

「より強いティア」が実際に何を意味するかは、リアルタイムの構成を見ると分かります。11月6日に確認したAuto Codeの直近24時間のトラフィック（992リクエスト）では、GPT-6.1 Solが70.4%、Claude Opus 5.5が14.8%、GLM 5.3が11.0%でした（Auto Codeページ）。一方、Autoの汎用構成はより安価な方向に寄っており、概要ページに表示されたボリュームの約47%だけでDeepSeek V4 Flash系が占めています（Autoの概要）。価格や新モデルの登場で構成は数日単位で変わるため、これは固定のラインアップではなく、その時点の状況として見るべきです。

モデル切り替えのコスト：キャッシュ再構築とプロバイダー固定

一般的なローンチ記事では見落とされがちですが、実際の請求額を左右するのがここです。セッション途中でモデルを切り替えると、プロンプトキャッシュは引き継がれません。新しいモデルはコンテキストをフルの入力料金で読み直す必要があります。OpenRouterもこの仕組みを認めており、キャッシュの再構築を減らすため、同じモデルが有力である間はマルチターンの会話を同じモデルに留める設計にしています（OpenRouterの発表）。

実際のユーザーからは、次のような問題が報告されています。

「リクエスト単位でルーターを作ろうとする人がいるが、それではうまくいかない……周辺のコンテキストがないプロンプトだけでは、複雑さを判断するシグナルとして不十分だ……セッション中に頻繁にモデルを変えるのは経済的ではない。1、2回の誤判断だけで、最初から最適なモデルを使うより高くつく」 — @kunchenguid

この指摘を象徴するのが、OpenCode作者の報告です。OpenRouterのキャッシュを修正したところ、あるテストの請求額が$50から$6に下がりました（@thdxr）。Redditでは、openrouter/autoを試したユーザーが「テスト時のキャッシュヒット率は、実質0だった」と報告しています（u/tankerkiller125real）。別のユーザーは「AutoがIDを切り替えるたび、次の呼び出しでcache_discountが0になった。一方、固定した実行ではキャッシュが使われ続けた」と書いています（u/Michael_Jeffords）。VS Codeスレッドで最も支持されている助言も明快です。「キャッシュでコストを節約したいなら、モデルとプロバイダーを固定する。そうしないと大きなコンテキストをランダムなプロバイダーへ送り続けることになる」（u/Zealousideal-Part849）。

実運用で重要なのは2点です。

1. 請求額を決めるのはリスト価格ではなく、キャッシュヒット率です。あるユーザーの推定では、現在エージェントのトークンの約87%がキャッシュ由来です（@shu8ham_）。そのため、固定性を壊すルーターは、コンテキストを再利用できる高価な固定モデルよりも高くつく場合があります。このユーザーの場合、システムプロンプトの先頭にあったタイムスタンプを末尾へ移すだけで、毎回キャッシュが無効になる問題が解消しました（@shu8ham_）。
2. 固定性が、弱いホストへの固定になってしまうこともある点です。キャッシュが温まっている間、後続リクエストは同じプロバイダーに留まります。そのため、品質の低い量子化エンドポイントを引くと、セッション全体に影響する可能性があります。「同じモデル名でも、同じモデルとは限らない。何が配信しているかまで固定するべきです」（@webtkdev）。切り替え後に品質が揺れたら、モデル名だけでなくプロバイダーも記録してください。

Auto Codeの方針、つまり明確な失敗がない限り推論強度を上げ、必要な場合だけ素早く切り替えるという考え方は理にかなっています（Auto Codeページ）。ただし、自分のセッションでcache_discountが継続的に0以外になっていることを確認できるまでは、切り替えを無料の機能ではなく、予算に織り込むべきリスクとして扱うのが安全です。

請求額を本当に抑えるコスト制御

cost_tierは上限ではなく、価格帯です。low、medium、high、xhigh、maxの5段階があり、それぞれ該当する価格帯のモデルを選びます。価格帯の上下にあるモデルは対象外にできます。また、従来のドキュメントに沿った経路では、ティアを指定しない場合はおおむねlowとして動作します（Auto Routerのドキュメント）。Redditの説明をそのまま覚えておくとよいでしょう。「cost_tierは上限ではなく価格帯。請求額を確定させたいなら、正確なモデルを固定する」（u/conifer_v11）。

どちらのルーターでも、次のような構成が現実的です。

• まずは標準設定のAuto Codeで試験用のリポジトリ群を動かし、以前の安価な挙動を重視するならAutoをlowで開始する。OpenRouterは、より高性能なモデルを含めるため、新しい標準価格を「数か月前」に近い水準へ引き上げました（OpenRouterの発表）。
• allowed_models / excluded_modelsにワイルドカード（例：anthropic/*）を指定して候補を絞る。除外設定が許可リストより優先され、候補が空になると404で処理が停止します（Auto Routerのドキュメント）。プラグインIDにも注意が必要です。openrouter/autoはauto-routerの設定を読み、openrouter/auto-betaはauto-beta-routerを読みます。異なる設定を渡しても、静かに無視されます（Auto Routerのドキュメント）。
• provider.max_priceとワークスペースの支出上限を組み合わせて、厳格な上限を設ける。ティアだけでは請求額を制限できません（Auto Routerのドキュメント）。
• マルチターンの作業では明示的なsession_idを渡す。固定性のキーをメッセージのフィンガープリントではなく、会話に紐付けられます（Auto Routerのドキュメント）。
• リクエストごとにmodel、プロバイダー、トークン数、価格のスナップショット、cache_discountを記録する。Auto Codeが最適化する指標であり、予算管理で知りたい「受け入れられたタスクあたりのコスト」を計算するには、このログが必要です。

関連情報として、当サイトのAuto Router設定ガイド、OpenRouter料金ガイド、プロンプトキャッシュガイド、セルフホスト型ルーティングの代替案を扱ったLiteLLMとOpenRouterの比較も参照してください。

1行で呼び出し、実際に動いたモデルを確認する

どちらのルーターも、モデル文字列を受け付ける場所なら利用できます（Autoの概要）。

curl https://openrouter.ai/api/v1/chat/completions \
  -H "Authorization: Bearer $OPENROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openrouter/auto-code",
    "messages": [{"role": "user", "content": "Add a retry with backoff to fetchUser in api/users.ts"}]
  }'

汎用的な用途ではopenrouter/autoに置き換えます。レスポンスのmodelフィールドには、実際に応答したモデルが入るので、必ず記録してください（Auto Routerのドキュメント）。X-OpenRouter-Metadata: enabledを送ると、タスク分類を取得できます（Auto Routerのドキュメント）。また、チャットルームのrouting-insightsパネルを開けば、タスクタイプ、難易度の判断、候補モデルの割合など、選定理由を確認できます（OpenRouterの発表）。両ルーターは、ツール呼び出し、ストリーミング、画像、PDF、音声、動画入力とテキスト／画像出力に対応し、ルートの上限は2,000,000トークンです。ただし実際のコンテキストウィンドウは、選ばれたモデルの仕様に依存します（Autoの概要およびAuto Codeページ）。

IDE利用時にはもう1つ注意があります。Codex CLI、Cline、Kilo Code、OpenCode、Continue、Copilot系のVS Code構成では、プロンプトの裏側で独自のサブ呼び出し、リトライ、大きなコンテキスト送信が発生することがあります。あるユーザーは、Pythonからの直接呼び出しでは約20トークンだったものが、プラグイン経由では20k〜40kトークンになったと比較しています（r/openrouterのルーティングスレッド）。小さなリクエストに見えるのに請求額が大きい場合は、ルーターを責める前に、トークンを増やしたのがルーターなのかハーネスなのかを確認しましょう。両ルーターの背後にあるOpenRouterのカタログには、600以上のモデルがあります（OpenRouterの発表）。

OpenRouter AutoとAuto Codeに関するFAQ

Auto CodeはAuto Routerより高いですか？

タスク単位では、通常そうです。OpenRouter独自の表では、5つのベンチマークのうち4つでAuto CodeがAutoより高コストでした。残り1つは同額です。Auto Codeが「安い」のは、固定した最先端モデルとの解決タスク単位の比較に限られます。

ルーターの追加料金はかかりますか？

かかりません。openrouter/autoとopenrouter/auto-codeはいずれも、選ばれたモデルの通常料金で請求され、ルーター手数料はゼロです（Autoの概要）。

モデルを切り替えるとプロンプトキャッシュは壊れますか？

壊れる可能性があります。新しいモデルやプロバイダーではキャッシュの再構築が必要になり、切り替え直後にcache_discountが0になったという報告もあります。Auto Codeはモデルを変える前に推論強度を上げる方針で、ベータ期間中は約9割のターンで同じモデルを使い続けました（OpenRouterの発表）。ただし、自分のセッションで確認する必要があります。

どのモデルが選ばれますか？除外もできますか？

ゼロデータ保持、プロバイダー、許可リスト、除外リストなどのフィルターを適用した後、カタログ内の任意のモデルが候補になります（Auto Codeページ）。anthropic/*のようなワイルドカードが使え、除外設定が優先されます（Auto Routerのドキュメント）。

ルーターではなく固定モデルを指定すべきなのはいつですか？

請求額を確定させたいとき、監査やデータ所在の要件から既知のモデルが必要なとき、または固定モデルの品質が自分のリポジトリでルーターの平均をすでに上回っているときです。まずAutoで候補を探し、その後、勝者を固定または許可リストに登録する流れがよいでしょう。

プロンプトでは解決できないトレードオフがあります。Auto Codeは、より高いティアとセッション認識によって成功率を数ポイント上げる代わりに、切り替えのたびにキャッシュを消費します。セッションが長く、コンテキストが大きいなら、最も安いルーターとは、切り替えを止めてくれるルーターです。