Here is the result that made me stop and re-read the benchmark table. On DRACO — a deep-research suite of 100 tasks across 10 domains — Claude Opus 4.8 scores 58.8% on its own. Run the same model three times in parallel and hand the three answers to a judge, and the score jumps to 65.5%. Same weights, same prompt, no fine-tuning. A 6.7-point gain came entirely from how the answers were combined.
That number is the whole argument for ensemble LLMs in one line. The value is not in owning more models. It is in the step that reads their answers and decides what to keep.
Voting is the wrong mental model
When engineers first hear "ask several models and combine them," they reach for majority voting: run five, take the answer that appears most often, ship it. That works for classification, where outputs are discrete and comparable. It falls apart for open-ended work — research summaries, architecture critiques, "compare these three approaches" — where every model writes a different paragraph and none of them are string-equal to another. There is nothing to count.
OpenRouter's Fusion tool, which launched in June 2026, takes a different route. It is a server-side tool (openrouter:fusion) that any model can call mid-conversation. The mechanics are three stages:
- Panel — your prompt fans out to a configurable set of models that answer in parallel.
- Judge — a designated model reads all the panel responses and produces a structured comparison.
- Synthesis — that comparison returns to your outer model, which writes the final answer.
The judge is where the interesting design decision lives, and it is explicitly not a vote.
Compare, don't merge
The judge does not blend the panel's prose into a smoothie. It classifies. According to the docs, it treats what all or most models agree on as higher-confidence consensus, surfaces contradictions, preserves unique insights that only one model raised, and flags blind spots none of them covered. The structured result comes back shaped like this:
{
"status": "ok",
"analysis": {
"consensus": [...],
"contradictions": [...],
"partial_coverage": [...],
"unique_insights": [...],
"blind_spots": [...]
},
"responses": [
{ "model": "...", "content": "..." }
]
}
Read those five buckets as a confidence map. Consensus is what you can lean on. Contradictions are where you need a human or a follow-up query. Unique insights are the reason you paid for a diverse panel — one model caught something the others missed, and a naive vote would have thrown it away as noise. Blind spots are the honest admission that the whole panel might be wrong in the same direction.
This is why self-fusion works at all. Three runs of one model still disagree at the margins because of sampling temperature, and the judge mines those disagreements for signal. Diversity across different models just widens the spread further.
Wiring it up
You call it like a tool, because it is one. The outer model decides when a task genuinely benefits from multiple perspectives and invokes it; you can force the issue with tool_choice.
{
"model": "~anthropic/claude-opus-latest",
"messages": [ /* ... */ ],
"tools": [
{
"type": "openrouter:fusion",
"parameters": {
"analysis_models": [
"anthropic/claude-fable-5",
"openai/gpt-5.5",
"google/gemini-3.1-pro"
],
"max_tool_calls": 8
}
}
]
}
A few defaults worth knowing before you tune anything. The panel takes 1 to 8 models. The judge is your own outer model and always runs at temperature 0 — determinism where you want it, sampling variety where you want that. Web search and fetch are enabled on both the panel and the judge, so members can pull fresh sources while they answer. And Fusion cannot recursively call itself inside one turn; a depth header (x-openrouter-fusion-depth) guards against a judge that tries to convene its own panel.
Plan for partial failure
This is the part that separates a demo from something you put behind a product. A fan-out-then-synthesize pipeline has more moving parts than a single call, so it degrades in stages rather than simply working or not.
- If the panel answers but the judge falls over, you still get
status: "ok" and the raw responses array — the analysis field is just absent. Your code has to handle a successful response that is missing the synthesis, not assume analysis is always there.
- Genuine failures return
status: "error" with a failure_reason you can branch on: all_panels_failed, insufficient_credits, rate_limited, fusion_invocation_capped, or unexpected_error.
Treat the absent-analysis case as a first-class path, not an edge case. It is the one that looks like success to a happy-path parser and quietly ships un-synthesized model output to your users.
The cost question
Running a panel is obviously more expensive than one call — but "more expensive than one model" is the wrong comparison. The right one is against the frontier model you would otherwise reach for. On DRACO, a budget panel of Gemini 3 Flash, Kimi K2.6, and DeepSeek V4 Pro landed at 64.7% — within a point of solo Claude Fable 5 (65.3%) at roughly half the cost. Push the other direction and a Fable 5 + GPT-5.5 panel judged by Opus 4.8 hit 69.0%, above any single model on the board. You are buying a point on the price-performance curve that no individual model occupies.
The takeaway
Reach for fusion when being wrong is expensive and the answer is not verifiable at a glance: research syntheses, design reviews, anything multi-domain where one model's blind spot is another's specialty. Skip it for cheap, high-volume, latency-sensitive calls — the fan-out tax is real and the synthesis buys you nothing on a task a single model already nails.
And when you do use it, spend your engineering attention on the judge's output schema, not the panel roster. Those five buckets — consensus, contradictions, partial coverage, unique insights, blind spots — are a ready-made confidence signal. Route on them: auto-accept high consensus, escalate contradictions, log blind spots. That is where an ensemble stops being a more expensive way to guess and starts being a measurably better way to answer.
Sources: Fusion Server Tool — OpenRouter Docs, Surpassing Frontier Performance with Fusion — OpenRouter Blog