Summary: What matters isn’t always cost per call; cost per correct answer often is. Reach for Fusion on high-stakes, research-style prompts where a wrong answer is costly: research questions, expert review, comparisons, and due-diligence summaries. Set Fusion against your current model and compare them on cost per accepted result, not on model price by itself.
There are times when one model call won’t cut it, and the usual fix is to query several models by hand and judge the answers yourself. OpenRouter Fusion folds that manual routine into a single API call: your prompt goes out to a panel of models at the same time, a judge lines their responses up against each other, and the calling model composes the final answer out of that analysis.
What Fusion does under the hood
Fusion is a compound inference system. The model you call may answer on its own, or bring in Fusion when a task calls for deeper analysis. Once invoked, anywhere from one to eight participant models answer the prompt independently, and every panelist has OpenRouter web search and web fetch available for finding current sources.
A judge then sets the responses side by side and hands back structured analysis spanning consensus, contradictions, partial coverage, unique insights, and blind spots. That analysis reaches the calling model, which writes the final response your application receives.
Comparison, not tallying, is the judge’s job. Three models repeating one unsupported claim doesn’t turn it into a fact. The judge can just as well lift up a good point that only one response raised, or point at a gap none of the panelists caught.
Where the quality gain comes from
Two things feed Fusion’s benefit: diversity across models, and variation across separate runs. Models differ in the methods they pick, the constraints they notice, the sources they retrieve. And two runs of a single model can walk different reasoning paths and make different tool calls.
OpenRouter probed that second effect by pairing Claude Opus 4.8 with another Opus 4.8 run and letting the same model handle synthesis. The fused configuration scored 65.5% on the DRACO benchmark, against 58.8% for a solo Opus 4.8 run — a 6.7-point improvement. So the comparison-and-synthesis step carries real value even when all the models are alike.
Ensembling several models is an established technique. What Fusion contributes is operational: a panel, a judge, tools, and a synthesis loop arrive through one model slug or server tool, sparing you the work of building and maintaining that orchestration.
What you trade for that gain
Every Fusion request covers several model calls plus the judge, so it burns more tokens than a single-model call. The default three-model panel runs roughly four to five times the cost of one completion on the same prompt, and often takes two to three times as long. Since the panel runs concurrently, you aren’t queued behind each model one at a time — but the slowest panelist sets the floor, and the judge comes after.
What matters isn’t always cost per call; cost per correct answer often is. When a single Fusion call lands the right answer and a cheaper model would have needed three attempts, a rerun, and a human to check it, Fusion can come out cheaper across the whole task.
By design, Fusion is non-deterministic as well. A panel plus a synthesis step won’t always give you the same result twice. For a one-off research task that’s harmless; it turns into a real problem wherever output must be repeatable — evaluation suites, regression tests, or any check comparing today’s result with yesterday’s.
When to escalate to Fusion
Selective escalation is the pattern that holds up best in production: let a model take routine work directly, and reserve Fusion for the narrower set of prompts that deserve extra scrutiny. The routing philosophy in Zero Data Retention: Enforcing Provider-Side Privacy on AI API Calls is the same idea — the right path follows the request’s sensitivity.
Reach for Fusion on high-stakes, research-style prompts where a wrong answer is costly: research questions, expert review, comparisons, and due-diligence summaries. It also earns its place whenever you would otherwise poll several models by hand and compare the answers yourself.
Leave it out of latency-sensitive or high-QPS interactive paths, such as a customer chatbot or inline code completion. Leave it out of reproducibility-sensitive workloads, such as evals and regression suites. And leave it out of simple, well-scoped jobs a single mid-tier model already handles — classification, extraction, short rewrites, format conversion.
Getting started
You can try Fusion in the web interface, or call it from any supported inference endpoint. The least involved API route is to swap your current model slug for openrouter/fusion. Left unconfigured, Fusion falls back to the default Quality panel and leaves the deliberation decision to the model.
Forcing Fusion to run takes tool_choice: "required" plus a plugin configuration. Among the general-purpose presets, general-high gives the strongest all-around panel, general-budget pairs cheaper panelists with a frontier judge, and general-fast tunes the panel around similar response times.
Begin with one hard prompt drawn from your real workload. Set Fusion against your current model and compare them on cost per accepted result, not on model price by itself.