OpenRouter Fusion Pricing: Panel Size and Token Cost

A Fusion request can look free on OpenRouter’s model page while costing several times more than a normal completion. The reason is simple: OpenRouter Fusion pricing is the sum of multiple underlying model calls, not a standalone per-token rate. Panel size and token volume decide whether the extra scrutiny is worth paying for.

OpenRouter Fusion pricing in one decision

OpenRouter Fusion is usually more expensive than calling one comparable model once. OpenRouter’s Fusion Router documentation describes a default three-model panel and one analyst call at roughly 4–5 times the cost of a single completion over the same prompt.

A budget panel can beat a premium model when its quality saves review work, but Fusion is a cost-versus-verification decision, not automatically a cheaper model.

The billing unit is a stack, not a Fusion token

OpenRouter’s Fusion API page presents Fusion as a router and shows zero prompt and completion pricing for the router alias. That label means Fusion itself has no separate standalone rate; it does not mean that the underlying inference is free.

The documented execution is:

1. The prompt goes to each selected panel model.
2. Panel responses are compared by an analyst or judge model.
3. The outer model produces the final answer.

For budgeting, use this equation:

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

The exact accounting depends on whether Fusion is invoked as the openrouter/fusion model alias or as the openrouter:fusion server tool. Do not infer the final invoice from the router’s displayed $0 line. Check the actual generation and OpenRouter Activity record.

OpenRouter’s documentation supports 1–8 analysis models. The default panel has three. Quality, Budget, and custom configurations mean there is no single universal Fusion price per million tokens.

Panel size changes the bill linearly—until the judge grows

If every panel model received the same prompt and generated a similar amount of output, adding one panel member adds approximately one more model call. OpenRouter explicitly says that cost scales linearly with panel size.

Call count understates judge cost because judge input grows with panel outputs:

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

Here, n is the number of panel models, Cp is the average panel-response cost, Cj(n) is judge cost including its growing input, and Co is the outer response cost when applicable.

The default three-panel estimate of 4–5× a single completion is therefore a better planning anchor than the router’s $0 display. The multiplier can rise when the judge is expensive, outputs are long, or the outer model adds another paid completion.

A worked example with editable rates

Use this worksheet with live rates for the models you select. The figures are illustrative, not OpenRouter prices: assume 10,000 input tokens, 2,000 output tokens per panel answer, 6,000 judge-input tokens, and 1,000 judge-output tokens.

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

If a one-model baseline processes the same 10,000 input and 2,000 output tokens, compare its total directly with this worksheet. For a three-model panel, the prompt is charged three times and the judge reads a separate 6,000-token context in this example. Change the assumptions when your prompts or answers are longer.

Under a simplified equal-cost assumption, the call-count shape is:

These are not OpenRouter prices. They show why panel count matters before model rates differ. A costly judge can dominate a cheap panel; frontier panel models can dominate the judge instead.

Token usage changes the comparison in two different ways

Token usage affects Fusion more than a single call because the prompt is processed repeatedly and the judge receives the panel’s generated answers.

1. Input tokens are duplicated across the panel

Let I be prompt tokens and Pi the input price of panel model i:

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

A 10,000-token prompt sent to three panel models creates three underlying input charges, potentially at three different rates.

2. Output tokens are multiplied too

If each panel produces O output tokens, the panel generates approximately n × O output tokens. Billed reasoning tokens can widen the gap beyond visible answer length.

The judge then reads those outputs:

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

A longer answer can therefore increase cost through each panel response and the judge’s input context.

A useful monthly estimate is:

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

Use current rates for the concrete model IDs in your panel. “Budget” is a preset label, not a promise that its total cost will beat every single model.

Budget, Quality, or one model?

Choose one model when speed, repeatability, and predictable billing matter more than independent review. This fits formatting, extraction, autocomplete, routine rewriting, and many ordinary coding prompts.

Choose Fusion when a missed issue is expensive: source-heavy research, expert critique, due diligence, or decisions with competing evidence. Start with the smallest panel that can answer the question. Three models is the documented default; eight is a maximum, not a recommendation.

The relevant comparison is:

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

OpenRouter’s separate benchmark announcement reports a 100-task DRACO evaluation, including a 69.0% result for a frontier Fusion configuration and 64.7% for a budget panel. Those figures support a deep-research use case, not a conversion rate for every prompt or proof that a larger panel is more economical.

Audit the number before scaling

Treat the first Fusion deployment as a measurement exercise. Log:

1. Panel model IDs and judge model ID.
2. Input, output, and reasoning-token usage where exposed.
3. Router metadata confirming whether Fusion ran.
4. Total cost and latency.
5. Whether the final answer reduced human corrections.

The Fusion documentation says generation metadata can include "router": "openrouter/fusion". The ordinary model field identifies the concrete model handling the request and is not enough to prove that Fusion ran.

A user report illustrates the configuration risk:

“this \"Fusion\" still calls Opus 4.8 as a judge. I see no way to disable it.” — @teortaxesTex on X

That is a user report, not an OpenRouter pricing rule. It illustrates why a low-cost panel does not guarantee a low-cost run if the judge is expensive or the configuration is not what you expected.

For production, pin the panel and judge where the API allows it, set budget limits, and make Fusion an explicit escalation path rather than exposing it to every autonomous request.

OpenRouter Fusion pricing FAQ

Is Fusion cheaper than one model?

Usually not against a similarly priced single model. It can be cheaper than a premium model when a budget panel delivers enough quality, but panel rates, judge cost, and token usage decide the result.

Is OpenRouter Fusion free?

The router alias may show $0 for its own prompt and completion fields. OpenRouter separately states that underlying panel and judge completions are billed, so a normal Fusion request should not be assumed to cost zero.

How many calls does one Fusion request make?

The documented process uses N panel calls plus one analyst call, with the final outer response depending on the integration. The default three-panel setup is described as roughly 4–5 times one comparable completion.

Does a larger panel always improve value?

No. More models can add coverage, but they also add panel charges, judge input, latency, and correlated errors. Increase panel size only when holdout tests show that the added quality saves more than it costs.

How can I estimate OpenRouter Fusion cost?

List every underlying model call, multiply current input and output rates by expected tokens, include judge input containing panel outputs, and verify the result in Activity after a real request. A third-party calculator can help with scenarios, but OpenRouter’s live rates and your Activity record are the authority.

The practical call

Use a single model as the baseline. Run a 20–50-prompt holdout set through that baseline and a small Fusion panel. Keep Fusion only if fewer factual corrections, missed evidence, or review hours pay for the additional panel and judge tokens.

For most teams, the cost-aware rollout is one model for routine traffic, small-panel Fusion for uncertain or high-cost decisions, and larger panels only when the measured gain survives the bill.