📨 What Fusion does: 1 prompt → N models
OpenRouter Fusion has a central gesture that's simple to describe: take a single prompt and send it, unchanged, to several different models at the same time. Each model gets the task entire and solves it on its own. In the end, you have N competing answers to the same question.
The keyword is ensemble: a set of models answering the same thing. This isn't division of labor — it's repetition. No one gets "just the code snippet" or "just the summary." Everyone sees the full request, and the diversity among them is exactly what Fusion aims to explore.
🆕 New here? Three terms
- Ensemble: combining multiple models (or runs) and merging their outputs — instead of trusting just one.
- Fan-out: send the same request to many destinations in parallel at once.
- Candidate: each individual response returned by a model, before the judge chooses/fuses.
⚖️ The judge that fuses the answers
N disconnected responses are useless — you want one. That’s where the judge: a model that reads all the candidates and produces the final answer. This pattern has its own name in the literature — LLM-as-judge: using a model to evaluate or choose among model outputs.
The candidates (cyan) converge on the judge, who delivers a single answer. The judge can choose the best one, vote, or rewrite a hybrid.
🎯 Three ways for the judge to merge
- 1.Pick-best: reads them all and chooses the best complete answer, discarding the rest.
- 2.Vote: when there’s a short “right” answer, go with the one produced by the most models (the majority).
- 3.Synthesize: rewrites a new answer, stitching together the best of each candidate.
🌈 Why this improves things: diverse perspectives
The intuition is old and comes from statistics: if several “voters” make mistakes in different ways independent, but combining the votes cancels out many of the errors and lets the shared correct answer stand out. It’s the “wisdom of crowds.” Different models—trained by different companies—tend to make different mistakes.
But there is a critical condition that many people forget: the errors need to be uncorrelated. If you run five copies of the same Model, they make almost the same mistakes—the ensemble doesn’t help. Fusion’s gains depend on real diversity among the models in the ensemble.
📊 The ensemble rule in one sentence
An ensemble only helps when the participants are, at the same time:
- Good enough — each one gets more right than wrong (otherwise you just add noise).
- Diverse enough — make mistakes in different places (otherwise they make the same mistakes and the judge has nothing to save).
- Judgeable — the judge can distinguish the best answer (otherwise it makes poor choices).
✓ Where diversity helps
- ✓Models from different vendors (different strengths)
- ✓Task with many valid approaches
- ✓An error from one model is rare but costly
✗ Where it won't help
- ✗Five copies of the same model
- ✗All models have the same gap
- ✗A strong model already gets it right on its own
🔀 Fusion × Fugu: ensemble × decomposition
Both use multiple models — and that’s where the similarities end. The Fugu decomposes: a manager breaks the task into parts and gives each part to a specialist (whoever is good at code writes the code). A Fusion replicates: the entire task goes to everyone, and the judge merges competing answers. Decomposing means splitting; replicating means repeating.
On the left, Fugu splits up different pieces. On the right, Fusion sends the entire task for each model. Same raw material (multiple models), opposite architecture.
| Dimension | 🐡 Fugu (decomposes) | ⚖️ Fusion (ensemble) |
|---|---|---|
| What each model receives | one piece of the task | a entire task |
| Who decides the split | one manager/conductor | No one—there’s no split |
| How it combines | combines complementary parts | judge selects/merges competitors |
| Expected gain | specialization by part | robustness through diversity |
| “Who does it?” question | divides among specialists | everyone does everything |
👪 Fusion's relatives
Fusion didn't invent "parallel + aggregate" — it packages a well-studied pattern. Knowing its relatives helps you see that this is a mature technique, not product magic. Three are worth naming:
Self-consistency
Ask same thing to same Model multiple times (with randomness) and keep the most common answer. It’s an ensemble “of a single model,” exploring the variance of its own samples. Cheap and surprisingly effective at reasoning.
LLM-as-judge
Using one model to evaluate the outputs of others — score, rank, choose the best one. It's exactly Fusion's "judge," and also the basis of many automatic quality evaluation systems.
Mixture-of-agents (MoA)
Multiple models in layers: the first layer answers, the second reads the first layer's answers and refines them, and so on. It's Fusion "in depth" — aggregating not just once, but in rounds.
💡 The thread that ties all three together
They all answer the second orchestration question — “how the responses are combined” — by generating Multiple candidates e aggregating. Fusion is the cross-provider version, behind an API; you can build the pattern itself by hand (you do this in Module 3.2).
🧾 The cost of parallelism: N responses + judge
Here’s the counterweight. Running N models costs N complete responses — each one reads the prompt and writes a complete answer, and you pay for all of them. Add the call to the judge, which still reads all the N responses. The bill grows to something on the order of N+1 runs to deliver a single answer.
Latency has good news and bad news. The good news: since the models run in parallel, the time is the slower, not the sum. The downside: the judge only starts after the last one finishes—so you always wait for the slowest in the group, plus the merge step.
📊 The ensemble math
- Cost ≈ (cost of 1 answer) × N + (cost of the judge reading N answers)
- Time ≈ (slowest answer among the N) + (judge’s time)
- Comparison: 3 models + a judge ≈ 4 paid calls per one answer
⚠️ The mental trap
“Asking everyone” seems free because each individual response is cheap. But you multiply by N and still pay the judge. If a strong model already gets it right, that N+1 is money burned—the exact decision ladder the Trilha 2 showed in the 38 tests.
Quick recall (optional): what is the key difference between Fusion and Fugu?
✅ Module summary
Next module:
3.2 — Fusion in practice and the future of the skill