OpenRouter Fusion: How It Works and When to Use It

Fusion is our compound model. It takes one prompt and turns it into a short debate among several models. We send your prompt to a panel of expert models at once, and a judge compares every response so the calling model can write a single final answer.

With Fusion, you trade some speed and tokens for quality. This page covers what Fusion does, what it costs, when it beats a single model, and when it doesn’t.

Tl;dr

• What Fusion does. It gives a model access to a multi-model deliberation tool. A panel answers in parallel, a judge maps agreement and disagreement, and the calling model writes the final response.
• What it costs. An invoked Fusion call adds panel and judge completions. The default three-model panel costs roughly four to five times as much as one completion on the same prompt and often takes two to three times longer.
• When to use it. Use Fusion as a selective escalation path for complex research, expert critique, and decisions where an incorrect answer creates more cost than a few additional model calls.

What is OpenRouter Fusion?

Fusion is a compound inference system that gives a model access to multi-model deliberation. When the model invokes Fusion, several models answer the prompt in parallel. A judge compares their responses and produces structured analysis, which is then used to produce the final answer.

That makes Fusion different from a single model call. A single call follows one model’s reasoning path. Fusion can bring several reasoning paths, source selections, and interpretations into the same response.

Fusion and auto-routing serve different jobs. Auto-routing picks one model for your request by classifying the prompt’s task type and choosing the model the OpenRouter community spends the most on for that kind of task. Fusion combines many models and blends their answers, and it can produce a stronger answer than any single panelist would give.

How OpenRouter Fusion works

Fusion adds a deliberation loop inside a normal model request.

The pipeline has four stages:

1. The calling model evaluates the prompt. When you use Fusion, we resolve the alias to a model and attach the Fusion tool. The model can answer directly or invoke Fusion when the task warrants more analysis.
2. The panel works in parallel. Between one and eight participant models independently answer the prompt. Each panelist can use OpenRouter web search and web fetch to find current sources.
3. The judge compares the responses. Our docs call this role the analyst. The judge identifies consensus, contradictions, partial coverage, unique insights, and blind spots. It returns that comparison as structured analysis.
4. The calling model writes the answer. The original model receives the judge’s analysis and uses it to produce the response returned to your application.

The judge’s job is comparison rather than simple voting. Three models repeating the same unsupported claim don’t automatically make that claim correct. The judge can also surface a useful point that appears in only one response or identify a gap that every panelist missed.

Where the quality gain comes from

Fusion benefits from diversity between models and variation between separate runs. Different models may choose different methods, notice different constraints, or retrieve different sources. Even two runs of the same model can follow different reasoning paths and make different tool calls.

We tested that second effect by pairing Claude Opus 4.8 with another Opus 4.8 run and using the same model for synthesis. The fused configuration scored 65.5% on our DRACO benchmark run, compared with 58.8% for a solo Opus 4.8 run. That 6.7-point improvement suggests that the comparison and synthesis process contributes meaningful value even without model diversity.

Multi-model ensembling is an established technique. Fusion’s product value is operational. You can add a panel, judge, tools, and synthesis loop through one model slug or server tool instead of building and maintaining that orchestration yourself.

Fusion vs. a single model

Fusion can improve difficult answers, but it does so by performing more work.

Quality depends on the task

On DRACO, a deep-research benchmark by Perplexity AI, a budget Fusion panel using Gemini 3 Flash, Kimi K2.6, and DeepSeek V4 Pro scored roughly 64.7% against about 65.3% for Claude Fable 5 on its own. Fable-based results reflect 93 of 100 tasks because of content filters, so direct comparisons are slightly uneven.

DRACO measures deep research, not raw coding or general chat. Fusion’s synthesis tends to help most on research and analysis prompts, where several viewpoints genuinely sharpen the answer. Don’t assume the same margin carries to every task.

More tokens, but cost per task can still win

Fusion pays for several model calls plus the judge, so a single request uses more tokens than a single-model call. Cost per call isn’t always the number that matters, though. Cost per correct answer often matters more.

If one Fusion call returns the right answer while a cheaper model needs three attempts, a rerun, and a human to check it, Fusion can come out cheaper across the whole task. Count the total cost of reaching the result, not the price of one request. Our Fusion model page has current costs.

Latency runs two to three times longer

Fusion calls often take two to three times as long as a standard single-model call. The panel runs concurrently, so you’re not waiting on each model in sequence, but you still wait for the slowest panelist and then for the judge. That delay usually rules out chat, autocomplete, and other real-time paths.

Non-deterministic by design

A panel plus a synthesis step can return different results run to run. That’s by design. It’s fine for a one-off research task, but it becomes a problem when you need repeatable output, like evaluation suites, regression tests, or any check that compares today’s result against yesterday’s.

When to use Fusion and when to skip it

The strongest production pattern is selective escalation. Let a model handle routine work directly and invoke Fusion for the smaller set of prompts that deserve additional scrutiny. For per-step escalation to a single stronger model, see the Advisor server tool.

Use it for high-stakes, research-style prompts where being wrong is expensive

Research questions, expert review, comparisons, and due-diligence summaries, anywhere accuracy is the priority and a later correction costs real time or money. In practice, think of summarizing a competitive field from a dozen current sources before you commit to a strategy call.

Use it when you’d otherwise poll several models by hand

If your current workflow is asking three models the same question and comparing the answers yourself, Fusion is doing exactly that job. The judge also compares answers more consistently than a manual review.

Skip it for latency-sensitive or high-QPS interactive paths

When a user is waiting for a response, the two-to-three-times latency is too long. In practice, this means a customer chatbot or inline code completion.

Skip it for reproducibility-sensitive workloads

Evals, regression suites, and anything that needs stable results across runs. Non-determinism makes those comparisons unreliable. In practice, a CI pipeline that checks whether an LLM’s output changed.

Skip it for simple, well-scoped tasks a single mid-tier model already handles

If one mid-tier model returns correct answers today, a panel just adds cost and delay for no real gain. In practice, classification, extraction, short rewrites, and format conversion.

How to use OpenRouter Fusion

You can test Fusion in the web interface or call it through any supported inference endpoint.

The no-code path

Open the Fusion lab, select a preset, and enter a prompt that benefits from multiple perspectives.

Start with a prompt you already know is difficult. Compare the fused result with the answer from your current production model. Look for fewer factual errors, broader coverage, clearer disagreement handling, or less human editing.

The interface also lets you build a custom panel before moving the configuration into your application.

The Fusion API

The simplest API path is to replace your current model slug with openrouter/fusion. With no additional configuration, Fusion uses the default Quality panel and lets the model decide whether deliberation is necessary.

The example below selects the general-budget preset, overrides its judge model, and requires Fusion to run:

import os

from openai import OpenAI

client = OpenAI(
    base_url="https://openrouter.ai/api/v1",
    api_key=os.environ["OPENROUTER_API_KEY"],
)

response = client.chat.completions.create(
    model="openrouter/fusion",
    messages=[{
        "role": "user",
        "content": "Compare three approaches to multi-tenant data isolation.",
    }],
    tool_choice="required",
    extra_body={
        "plugins": [{
            "id": "fusion",
            "preset": "general-budget",
            "model": "~openai/gpt-latest",
        }]
    },
)

print(response.choices[0].message.content)

The preset chooses a curated panel. The nested model field selects the judge and, when you use the Fusion model alias, the model that writes the final response. Explicit analysis_models or model values override the corresponding preset settings. tool_choice: "required" forces the model to invoke Fusion instead of letting it decide.

The available general-purpose presets currently include:

• general-high for the strongest all-around panel
• general-budget for cheaper panelists with a frontier judge
• general-fast for a panel optimized around similar response times

You can also attach the openrouter:fusion server tool to your own outer model. That path is useful when the same model needs access to Fusion alongside your application’s other tools.

See the Fusion Router documentation for the full request formats and the Presets guide for reusable configuration management.

Conclusion

Fusion gives difficult prompts more than one attempt and gives your application a structured way to compare those attempts. That can improve research, critique, and high-cost decisions where a fast first answer isn’t enough.

The additional scrutiny has a measurable price. The panel and judge add tokens, cost, latency, and output variance. Those costs are justified when they reduce retries, manual comparison, or the risk of acting on an incomplete answer.

Start with one hard prompt from your real workload. Compare Fusion with your current model using cost per accepted result, not model price alone.

Try it with the Fusion Router, or read the Fusion benchmark announcement for the full DRACO methodology and results.

Frequently asked questions

How does OpenRouter Fusion work?

OpenRouter Fusion lets a calling model send a prompt to several panel models in parallel. A judge compares the responses and returns structured analysis covering consensus, contradictions, partial coverage, unique insights, and blind spots. The calling model uses that analysis to write the final answer.

What is model fusion in AI?

Model fusion can refer to combining model parameters or combining outputs from several models. OpenRouter Fusion uses output-level deliberation during inference. It gathers independent responses, compares them through a judge, and gives the resulting analysis to the model that writes the final response.

Is OpenRouter Fusion better than Fable 5?

Fusion outperformed Fable 5 on its own in several frontier-panel configurations on the DRACO deep-research benchmark by Perplexity AI. A budget panel scored 64.7%, compared with Fable 5 at 65.3%, while a frontier panel scored 69.0%. Fable-based results reflect 93 of 100 tasks because of content filters. These results apply to deep research and don’t establish that Fusion replaces Fable across long-horizon or general workloads.

Does OpenRouter Fusion have an API?

Yes. You can call the OpenRouter Fusion API with the openrouter/fusion model slug or attach Fusion as an openrouter:fusion server tool. The fusion plugin configures the panel and judge for either entry point but does not start a Fusion run on its own. Both entry points use the same underlying panel, judge, and final-answer pipeline.