⚖️ OpenRouter Fusion

Fusion takes one prompt and sends it, unchanged, to several models at the same time. Each model answers the entire task on its own — nobody receives just one piece.

It’s how Fugu works out of the box. Anyone who confuses "multiple models" with "decomposing the task" understands neither. This is replication, not division.

Ensemble · fan-out · same prompt · parallel candidates.

After N models respond, one model judge reads all the answers and produces the final one — choosing the best, voting, or rewriting a hybrid. It’s the “fusion” in Fusion.

The judge is where the ensemble becomes one answer. Without it, you just have N separate candidates. The quality of the judge is half the quality of Fusion.

LLM-as-judge · merge · aggregation · pick-best vs. synthesis.

Different models make mistakes in different ways. When several answer the same prompt, correct answers tend to coincide while errors spread out—the judge can then favor the consensus.

It’s the theory behind the ensemble: diversity reduces idiosyncratic error. But it only works if the models are truly diverse — identical models make identical mistakes.

Diversity · uncorrelated errors · consensus · wisdom of crowds.

Fugu decomposes: breaks down the task, gives pieces to specialists, and puts them together. Fusion replicates: the same full prompt goes to everyone, and a judge merges competing answers.

These are two opposite answers to the question “who does each part?” Understanding the contrast gives you the vocabulary to classify any orchestrator you come across.

Decompose vs. replicate · pieces vs. candidates · manager vs. judge.

Fusion has a family. Self-consistency: asking the same model several times and voting for the most common answer. Mixture-of-agents: layers of models refining each other's answers.

Recognizing the related approaches shows that “parallel + aggregate” is an old, well-studied pattern — Fusion just packages it across providers behind one API.

Self-consistency · LLM-as-judge · mixture-of-agents · voting.

Running N models means paying for N complete responses — plus the judge call, which reads them all. You spend ≈ N+1 times as much to deliver just one response.

Cost is the ensemble’s Achilles’ heel. Without adding up N+1, "asking everyone" seems free; with the numbers, it’s clear when it’s worth it (and when it isn’t).

N+1 cost · judge tokens · slowest latency · cost × benefit.

Ensembles shine when errors are costly and there’s no verifiable answer: open-ended decisions, high-stakes writing, and tasks where diverse perspectives catch what a single model would miss.

Defines Fusion’s real niche. Without knowing where it wins, you either apply it to everything (expensive) or nothing (missing the robustness gains).

Cost of error · no answer key · robustness · high variance.

If a top model already solves the task, the ensemble only adds cost and wait time without changing the result — exactly what Fugu’s 38 tests showed (36/38 ties).

It's the honest default. Most tasks "fall to the top of the ladder": 1 strong model ties, faster and cheaper. Orchestrating is the exception, not the rule.

Ceiling already reached · decision ladder · default = 1 model.

You don't need a special API for the Fusion pattern. Ask Claude Code for N answers from different angles and a judge agent to combine them—manual ensemble, full control.

Demystifies Fusion: the pattern is yours, not the product’s. Knowing how to put it together yourself lets you choose when it’s worth running—and see the cost before paying.

Manual ensemble · judge agent · fan-out + merge · copy-run.

The right question isn’t “which model is better?” but “what’s the cost per acceptable result?” Sometimes 3 cheap models + a judge beat 1 expensive model for the same money.

It’s the metric the field test author uses: optimize unit economics, not benchmark vanity. Thinking in $/result changes every orchestration decision.

Cost per result · cheap×good · quality trade-off · call ROI.

Running across multiple providers through one API is insurance: if one model goes offline, gets expensive, or degrades, your application doesn’t stop — it continues with the others.

It's the benefit of Fusion that No depends on extra quality. Even when the ensemble doesn't improve the response, the hedge against lock-in may be worthwhile on its own.

Vendor lock-in · hedge · resilience · cross-provider.

The skill you develop: knowing when orchestrate, which default (decompose vs. ensemble), and which cost — instead of adopting the most automatic product just because it's trendy.

It's the course's destination. The idea is the future; judgment about when to apply it is what separates those who orchestrate well from those who just burn tokens.

Orchestration judgment · cost awareness · the right pattern · mindset.