OpenRouter Fusionの料金：パネル数とトークンコスト

OpenRouterのモデルページでは無料に見えるFusionリクエストが、通常の補完処理の数倍になることがあります。理由は明快で、OpenRouter Fusionの料金は、Fusion専用の単価ではなく、複数のモデル呼び出しを合算したものだからです。追加の検証にいくら払う価値があるのかは、パネル数とトークン量で決まります。

OpenRouter Fusionを使うかどうかの判断基準

OpenRouter Fusionは、同程度のモデルを1回だけ呼び出す場合より、通常は高コストです。OpenRouterのFusion Routerのドキュメントでは、デフォルトで3モデルのパネルと1回のアナリスト呼び出しを使い、同じプロンプトに対する単一モデルの補完1回と比べて、およそ4～5倍のコストになると説明されています。

パネルの品質によって確認作業を減らせるなら、低価格帯のパネルが高価格モデルを上回ることもあります。ただしFusionは、常に安いモデルというより、コストを払って検証精度を高めるかどうかの選択肢です。

課金単位は「Fusionのトークン」ではなく処理の積み重ね

OpenRouterのFusion APIページでは、Fusionをルーターとして紹介しており、ルーターのエイリアスにはプロンプトと補完の料金としてゼロが表示されます。これはFusion自体に独立した単価がないという意味であって、内部で実行される推論処理が無料という意味ではありません。

ドキュメント上の処理は次のとおりです。

1. プロンプトが、選択した各パネルモデルに送られる。
2. パネルの回答をアナリストまたは判定モデルが比較する。
3. 外側のモデルが最終回答を生成する。

予算を見積もるときは、次の式を使います。

Fusion cost = sum(panel model costs)
             + analyst/judge cost
             + any final outer-model cost shown for your integration

実際の課金方法は、Fusionをopenrouter/fusionモデルのエイリアスとして呼び出すか、openrouter:fusionサーバーツールとして使うかによって異なります。ルーターに表示された$0の行だけを見て、最終請求額を判断しないでください。実際の生成処理とOpenRouter Activityの記録を確認しましょう。

OpenRouterのドキュメントでは、分析モデルを1～8個指定できます。デフォルトのパネルは3モデルです。Quality、Budget、カスタム設定が用意されているため、100万トークンあたりのFusion料金に、全ケース共通の単一価格はありません。

パネル数を増やすと料金は比例して増える。ただし判定処理も膨らむ

すべてのパネルモデルが同じプロンプトを受け取り、ほぼ同じ量の回答を生成するなら、パネルメンバーを1つ増やすごとに、モデル呼び出しが約1回増えます。OpenRouterも、コストはパネル数に対して線形に増加すると明記しています。

ただし、判定モデルの入力はパネルの回答を受け取るため、単純な呼び出し回数だけでは判定コストを捉えきれません。

C(n) = n × Cp + Cj(n) + Co

ここでnはパネルモデル数、Cpはパネル回答1件あたりの平均コスト、Cj(n)は増加する入力分を含む判定コスト、Coは該当する場合の外側モデルによる回答コストです。

したがって、デフォルトの3モデル構成で単一補完の4～5倍という見積もりは、ルーターに表示される$0よりも、予算を立てるうえで現実的な基準になります。判定モデルが高価だったり、回答が長かったり、外側のモデルによる有料補完が加わったりすると、倍率はさらに上がる可能性があります。

料金を差し替えて使える計算例

選択したモデルの最新料金を使って、次のワークシートを当てはめてください。以下の数値は説明用であり、OpenRouterの料金ではありません。入力10,000トークン、パネル回答ごとの出力2,000トークン、判定への入力6,000トークン、判定出力1,000トークンを仮定します。

Panel input  = 10,000 × sum(panel input rates)
Panel output = 2,000 × sum(panel output rates)
Judge input  = 6,000 × judge input rate
Judge output = 1,000 × judge output rate
Fusion total = panel input + panel output + judge input + judge output

単一モデルのベースラインが、同じ10,000入力トークンと2,000出力トークンを処理するとします。この場合、その合計額をワークシートの結果と直接比較できます。3モデルのパネルなら、プロンプト料金は3回分かかり、この例では判定モデルが別途6,000トークンのコンテキストを読み取ります。プロンプトや回答が長い場合は、前提を置き換えてください。

すべての呼び出しが同じコストだと単純化した場合、呼び出し回数の形は次のようになります。

ここで示した倍率はOpenRouterの料金ではありません。モデルごとの単価が異なる前に、パネル数だけでコスト構造が大きく変わることを示すものです。安価なパネルでも判定モデルが高ければ判定処理が支配的になりますし、最先端のパネルモデルを選べば、今度はパネル側の料金が大きくなります。

トークン量は、単一モデルとの比較を2方向から変える

Fusionでは、プロンプトが何度も処理されるうえ、判定モデルがパネルで生成された回答も読み取ります。そのため、トークン量の影響は単一呼び出しより大きくなります。

1. 入力トークンはパネル数分だけ重複する

Iをプロンプトのトークン数、Piをパネルモデルiの入力料金とすると、次のように表せます。

Panel input cost = I × (P1 + P2 + ... + Pn)

10,000トークンのプロンプトを3つのパネルモデルに送ると、内部では3回分の入力料金が発生します。しかも、モデルごとに単価が異なる場合があります。

2. 出力トークンもパネル数に応じて増える

各パネルがOトークンを出力すると、パネル全体ではおよそn × Oトークンが生成されます。課金対象の推論トークンが含まれる場合、画面上の回答の長さだけでは捉えられない差がさらに広がります。

さらに、判定モデルはそれらの回答を読み取ります。

Judge input ≈ original prompt + n × panel output + orchestration overhead

つまり回答が長くなるほど、各パネルの出力コストだけでなく、判定モデルの入力コンテキストも増えていきます。

月額コストは、次のように見積もると便利です。

Total monthly cost ≈ requests × (panel input + panel output
                                  + judge input + judge output
                                  + outer response)

実際にパネルへ組み込むモデルIDの最新料金を使ってください。「Budget」はプリセット名であり、あらゆる単一モデルより合計額が安くなることを保証するものではありません。

Budget、Quality、それとも単一モデル？

独立した検証よりも、速度、再現性、予測しやすい請求額を重視するなら、単一モデルを選びます。フォーマット変換、情報抽出、オートコンプリート、定型的なリライト、一般的なコーディング依頼などがこれに向いています。

一方、見落としの損失が大きい処理ではFusionが候補になります。たとえば、出典を重視するリサーチ、専門家による批評、デューデリジェンス、相反する根拠を含む意思決定などです。まずは、質問に答えられる最小限のパネルから始めましょう。3モデルはドキュメント上のデフォルトであり、8モデルは最大値であって推奨値ではありません。

比較すべきなのは、次の差分です。

incremental Fusion cost
versus
avoided correction cost + saved human review time + reduced error exposure

OpenRouterが別途公開しているベンチマーク発表では、100タスクのDRACO評価において、最先端Fusion構成が69.0%、Budgetパネルが64.7%という結果を報告しています。これらの数値はディープリサーチ用途を裏付けるものですが、あらゆるプロンプトにそのまま当てはまる変換率でも、パネルを大きくすれば経済性が高まることの証明でもありません。

スケールさせる前に、実際の数字を監査する

Fusionの最初の導入は、効果測定のための試行と考えましょう。次の項目を記録します。

1. パネルモデルのIDと判定モデルのID。
2. 取得できる場合は、入力、出力、推論トークンの使用量。
3. Fusionが実行されたことを示すルーターメタデータ。
4. 合計コストとレイテンシー。
5. 最終回答によって人手による修正が減ったかどうか。

Fusionのドキュメントによると、生成メタデータには"router": "openrouter/fusion"が含まれる場合があります。通常のmodelフィールドは、そのリクエストを処理した具体的なモデルを示すだけで、Fusionが実行されたことの確認には不十分です。

設定に関しては、次のようなユーザー報告もあります。

「この\"Fusion\"はそれでもOpus 4.8を判定モデルとして呼び出している。無効にする方法が見当たらない」— X上の@teortaxesTex

これはユーザーによる報告であり、OpenRouterの料金ルールではありません。ただし、パネルが低価格でも、判定モデルが高価だったり、想定と異なる設定で動作したりすれば、実行全体のコストが下がるとは限らないことを示しています。

本番環境では、APIで可能な範囲でパネルと判定モデルを固定し、予算上限を設定しましょう。あらゆる自律的なリクエストにFusionを適用するのではなく、必要な場合だけ明示的にエスカレーションする仕組みにするのが安全です。

OpenRouter Fusionの料金に関するFAQ

Fusionは単一モデルより安くなりますか？

同程度の価格帯の単一モデルと比べると、通常は安くなりません。Budgetパネルで十分な品質が得られれば、高価格モデルより安くなる可能性はありますが、最終的にはパネルの単価、判定コスト、トークン量で決まります。

OpenRouter Fusionは無料ですか？

ルーターのエイリアスでは、独自のプロンプト料金と補完料金に$0と表示される場合があります。しかしOpenRouterは、内部のパネルおよび判定モデルによる補完には課金されると説明しています。通常のFusionリクエストが無料だとは考えないでください。

1回のFusionリクエストで何回呼び出しが発生しますか？

ドキュメント上の処理では、N回のパネル呼び出しに加えて、1回のアナリスト呼び出しが発生します。最終的な外側の回答が加わるかどうかは、利用する統合方式によって異なります。デフォルトの3モデル構成は、同等の補完1回に対しておよそ4～5倍と説明されています。

パネルを大きくすれば、必ず費用対効果が上がりますか？

いいえ。モデルを増やせばカバレッジは広がる可能性がありますが、パネル料金、判定モデルへの入力、レイテンシー、相関した誤りも増えます。追加した品質によってコスト以上の効果が得られることを、ホールドアウトテストで確認できた場合にだけパネルを増やしましょう。

OpenRouter Fusionの料金はどう見積もればよいですか？

内部で発生するモデル呼び出しをすべて洗い出し、想定トークン数に現在の入力・出力料金を掛けます。さらに、パネルの回答を含む判定モデルの入力も加え、実際のリクエスト後にActivityで結果を確認してください。シナリオ比較にはサードパーティーの計算ツールも役立ちますが、基準にすべきなのはOpenRouterの最新料金とActivityの記録です。

実際に取るべき方針

まずは単一モデルを基準にします。そのうえで20～50個のプロンプトからなるホールドアウトセットを、基準モデルと小規模なFusionパネルの両方で実行してみましょう。事実関係の修正、根拠の見落とし、レビュー時間が減り、追加で発生するパネルと判定モデルのトークン料金を回収できる場合にだけ、Fusionを残します。

多くのチームにとって、コストを意識した導入方法は、定型処理には単一モデル、不確実性や判断ミスのコストが大きい処理には小規模パネルのFusion、そして測定した効果が請求額を上回る場合にだけ大規模パネルを使うという形です。