Fusion & LLM Councils — why many models beat one

For NAO + anyone learning LLM systems. Simple but smart, then deep. This is the first article in the lab's knowledge library (Karpathy-pattern, but ours). It explains the idea behind our M11 super-feature, grounds it in the real production system (OpenRouter Fusion) and research lineage (Mixture-of-Agents, self-consistency, LLM-as-judge), and is honest about where the magic stops. Sources: OpenRouter Fusion beats frontier, Karpathy's llm-council, Together AI's MoA, and the LLM-judge-bias literature.

The one-sentence idea

Ask several models (or one model several times) the same question, then have a judge model reconcile their answers — the combined result reliably beats any single model, even the best one in the panel.

It mirrors a human team: a smart person is good; a smart team that debates, catches each other's blind spots, and writes a combined answer is better. The mechanism is statistical, not mystical: models have different blind spots (different training data, architectures, RLHF), so their errors are partially independent. Aggregating partially-independent estimators cancels variance the way independent voters cancel noise — the classic ensemble result, now applied at the level of whole language models instead of decision trees.

Why it matters

Three reasons it's more than a parlor trick:

1. It moves the Pareto frontier. OpenRouter's headline result: a panel of cheap models beats a frontier model at ~half the cost (more below). You buy accuracy with parallelism instead of a bigger model.
2. It's a prompting technique, not a training one. No fine-tuning, no new weights — you orchestrate existing endpoints. That makes it composable with anything and trivially upgradable as new models ship (Together's MoA paper stresses exactly this: "relies entirely on prompting").
3. It's the substrate for "a second opinion." A council is the natural place to put a critic, a verifier, or a dissenting voice — which is what an agentic system needs at high-stakes decision points.

How it actually works — three real systems

There is a family of techniques here. They differ in what is diverse (samples vs models), how many rounds, and how answers are aggregated (vote vs judge vs synthesize). Knowing the family prevents you from conflating them.

1. OpenRouter Fusion — the production reference

One API call ("model": "openrouter/fusion"), server-side, three stages:

1. Parallel dispatch. The prompt fans out to a panel of N models at once. Each panel member gets tools enabled: openrouter:web_search and openrouter:web_fetch (both via Exa) and openrouter:bash. So each member isn't just answering from weights — it can research independently, producing genuinely different evidence bases.
2. Judge analysis. A designated judge model reads every panel response and writes a structured comparison — not a vote. The judge's output is explicitly: consensus points, contradictions, partial coverage, unique insights, and blind spots. This is the load-bearing step. The judge is doing reading-comprehension-over-answers, surfacing where members agree (high confidence), where they contradict (needs resolution), and what only one member caught (recoverable signal that a majority vote would have discarded).
3. Synthesis. The judge writes the final answer grounded in that analysis.

Configuration knobs that matter in practice: analysis_models (the panel) is set via the plugin form "plugins":[{"id":"fusion","analysis_models":[...]}], and you can scope the panel's tools with excluded_domains/blocked_domains — OpenRouter themselves had to use this because panel models were finding the DRACO grading rubric online and gaming it. (A nice real-world reminder that tool-enabled panels leak benchmark contamination.)

2. Karpathy's llm-council — the deliberative flavour, with anonymized peer review

Same family, more democratic. Karpathy is explicit that it's "99% vibe coded as a fun Saturday hack… provided as is" — read it as a clean reference design, not production code. FastAPI + async httpx fan-out to OpenRouter, React/Vite UI, conversations persisted as JSON in data/conversations/. Three stages:

1. First opinions. Each council member (example config: GPT-5.1, Gemini-3-Pro, Claude Sonnet 4.5, Grok-4) answers the query independently. Shown side-by-side in a tabbed UI.
2. Review & ranking. Each model is shown its peers' answers with identities anonymized, and ranks them by accuracy and insight. The anonymization is the important engineering choice: it's a deliberate mitigation for self-enhancement bias (models rate their own output higher when they can recognize it). Strip the labels and the ranking gets closer to honest.
3. Synthesis. A designated Chairman model compiles the individual responses (now with peer rankings as signal) into one final answer.

The difference from Fusion: llm-council adds an explicit cross-review round (members judge each other, not just a single external judge), à la a peer-review panel. That's a debate round in everything but name.

3. Mixture-of-Agents (MoA) — the research ancestor, layered

Together AI's MoA is where the modern "use a panel, then aggregate" pattern was benchmarked hard. Its twist is depth: instead of one dispatch→judge pass, MoA stacks layers.

• Proposers (a layer of N models) each answer the prompt.
• Their outputs are concatenated and handed to the next layer of proposers as auxiliary context ("here are other agents' attempts — improve on them"). This repeats for several layers.
• A final aggregator synthesizes the last layer into one answer.

Reference config: 6 open-source proposers (WizardLM-2-8x22b, Qwen1.5-110B/72B-Chat, Llama-3-70B-Chat, Mixtral-8x22B, dbrx-instruct), 3 layers, Qwen1.5-110B-Chat as final aggregator. MoA-Lite uses 2 layers. The key conceptual contribution: a model that wouldn't propose the best answer alone can still be a great aggregator, and vice-versa — these are separable skills. (In Fusion terms: being a good panel member ≠ being a good judge.)

The common shape (pseudocode-in-prose)

All three reduce to: dispatch in parallel → optionally let answers see each other (review/layer) → aggregate. The aggregation strategy is the real design axis:

• `vote` — sample/answer K times, pick the majority answer. This is self-consistency (Wang et al., 2022): for problems with a checkable final answer (math, multiple-choice) it gives large gains (+17.9% on GSM8K over greedy CoT) for almost no machinery. Cheap, but only works when answers are comparable tokens, not prose.
• `judge` — a model scores the candidates and picks/ranks one. Keeps an existing answer; adds an evaluation step.
• `synthesize` — a model writes a new combined answer from the candidates. Strongest for open-ended work, because it can merge the best of several and resolve contradictions, not just pick a winner. This is what Fusion, the Chairman, and the MoA aggregator all do.

Does it really beat the best single model? (the evidence)

OpenRouter's DRACO benchmark: 100 deep-research tasks across 10 domains (academic, finance, law, medicine, technology, UX, general knowledge, retrieval, personalized assistance, product comparison), graded on a ~39-criterion weighted rubric (≈20 factual-accuracy criteria, ≈9 breadth/depth, ≈6 presentation, ≈5 citation), with negative-weight criteria that penalize errors so you can't game the score by being verbose.

Three results that feel almost unfair:

• The panel beats every one of its own members. 69.0% > Fable 5's 65.3% and > GPT-5.5's 60.0%. The whole exceeds the best part.
• Cheap + diverse beats expensive + alone. The budget panel (64.7%) beats solo GPT-5.5 (60.0%) and solo Opus 4.8 (58.8%), landing within ~1% of Fable 5 at ~50% of the cost. This is the "Fusion beats frontier" headline.
• Self-fusion is real. Running Opus 4.8 twice and synthesizing scores 65.5% vs 58.8% solo — a +6.7-point gain from the same model. Diversity of samples (different stochastic rollouts) helps, not just diversity of models. This is self-consistency wearing a synthesizer instead of a vote.

Cross-check from the research lineage, so this isn't a single vendor's claim: Together's MoA hits 65.1% on AlpacaEval 2.0 LC vs GPT-4o's 57.5% using only open-source models, and 9.25 on MT-Bench vs GPT-4o's 9.19 — the same "panel of weaker models > one strong model" shape, on a different benchmark, two years earlier.

Key ideas & tradeoffs

• Diversity is the fuel. The gain comes from decorrelated errors. A panel of three near-identical fine-tunes of one base model helps far less than three genuinely different lineages. This is why Codex (a different model family) is worth a seat even though it's expensive — its errors are uncorrelated with Claude's.
• The judge is where quality concentrates. OpenRouter notes absolute scores shift 10–25 points depending on which model judges. Spend your best model on the judge seat, not (necessarily) on the panel.
• `synthesize` > `judge` > `vote` for open-ended work; vote wins on cost for closed-form answers. Pick the aggregator to match the task's answer-shape.
• More rounds/layers ≈ diminishing returns at rising cost. MoA's layers help but each adds a full serial pass. Fusion's single dispatch→judge→synthesize is usually the sweet spot; reserve a debate round for the hardest problems.
• It's a scalpel. The whole point is to spend extra compute selectively on problems where being more-right is worth 2–3× the latency and N× the tokens.

Honest caveats & limitations

1. It is 2–3× slower and N×+ more expensive. Fusion is "often 2–3x longer than a standard call." You're paying for N panel calls + a judge call. Never the default path; it's an opt-in for hard problems.
2. LLM-judge bias is real and measurable — the council inherits it. The judge/aggregator is itself an LLM, so it carries the documented failure modes: - Position bias — judges favor answers by their slot, with up to ~75% preference for the first-positioned response in some studies (arXiv:2406.07791↗). Mitigation: randomize order, or judge pairwise both ways. - Self-enhancement bias — a judge rates its own output higher; the effect correlates with the model's ability to recognize its own text. This is exactly why llm-council anonymizes peer answers, and a reason not to let a panel member also be the sole judge of its own work. - Verbosity bias — judges over-reward length. DRACO's negative-weight criteria are a deliberate counter. (Survey: LLMs-as-Judges, arXiv:2412.05579↗.) Powerful models acting as judges have been measured with error rates exceeding 50% on some tasks; multi-judge consensus (3 judges, aggregate) recovers much of the reliability — itself a mini-council.
3. Benchmarks don't fully generalize. DRACO is text-only, English-only, single-turn, and explicitly excludes long-horizon tasks (where Fable reportedly shines and a panel may not help). Fusion is also not a drop-in for coding models — these results are about deep-research/reasoning prose, not agentic code.
4. Tool-enabled panels leak. Panel members with web access found and gamed the grading rubric; you must blocklist eval sources. The same risk applies to any benchmark you run a tool-using council against.
5. The +6.7 self-fusion number is data-set-specific. Self-consistency gains vary hugely by task; don't promise a fixed lift.
6. Aggregation can wash out a lone correct answer. A naive vote discards the one member who was uniquely right. synthesize can recover it — but only if the judge notices ("unique insights / blind spots"). Garbage judge → lost signal. The judge prompt is doing real work and deserves real engineering.

How it connects to OpenAlice

The lab's M11 — flexible model-council / fusion is our first-party take. Design, grounded in everything above + NAO's constraints:

• Configurable panel. Choose the N models per task. Defaults: a budget panel (cheap, diverse — our analogue of Gemini-Flash + Kimi + DeepSeek) for most jobs; a frontier panel for the hardest.
• Configurable aggregation — vote (closed/factual questions; cheapest), judge (score + pick), synthesize (write the combined answer; default for open-ended). Map the strategy to the answer-shape, per the tradeoffs above.
• Judge = our strongest available (Opus 4.8 at high effort) — judging is where quality concentrates, and the judge choice alone can swing scores 10–25 points.
• Anonymize panel answers to the judge when feasible, and never let a single member self-judge — directly importing llm-council's bias mitigations rather than re-discovering them.
• Codex is a *voice*, not a workhorse. Per NAO: Claude is the cheap default executor (subscription); Codex is reserved as one distinct council member. Its value here is precisely model diversity — a different lineage with decorrelated errors, which is the fuel of fusion. (Self-fusion proves even same-model panels help, so Codex's different family is a genuine asset.)
• Built on M10's provider-router ([[model-routing]]) — the council is "call the router N times in parallel, then judge." The router already abstracts Codex ↔ Claude ↔ future Alice; M11 is the aggregation layer on top.
• Rounds optional. 1 round (dispatch→judge→synthesize) by default; an optional debate round (members critique each other, à la llm-council) for the hardest problems — explicitly priced as 2–3× slower.
• Spend it selectively. Wire the council in at high-stakes decision points (deep research, irreversible actions, a self-edit gate) — not the hot path. It's the "opinion of another model" NAO wants in the [[vision-living-organism]]: a second mind, on demand, for decisions worth it.

Adjacent in our stack: a council's synthesizer is the natural home for a critic / verifier ([[agent-memory-systems]] feeds it context); fusion over retrieval-grounded members overlaps with [[graphrag]] and [[mempalace]] (diverse retrieval + diverse synthesis); and [[mixture-of-agents]] is the layered generalization if we ever want depth over a single judge pass.

Takeaways

1. Many models > one — because their errors are partially independent and a judge cancels them. Diversity is the fuel.
2. The judge's *analysis* (consensus, contradictions, unique insights, blind spots) matters more than a vote — and the judge choice alone swings results 10–25 points.
3. Cheap + diverse can beat expensive + alone, at ~half the cost (Fusion's budget panel; MoA's open-source panel).
4. Even one model run twice + synthesized gains points (self-fusion / self- consistency) — sample diversity counts.
5. The judge is an LLM and inherits its biases (position, self-enhancement, verbosity) — anonymize, randomize, penalize length, consider multi-judge.
6. Spend it selectively. It's 2–3× the latency and N× the tokens — a scalpel, not a hammer.

Sibling articles in the library: [[fusion-and-llm-councils]] · [[mixture-of-agents]] · [[model-routing]] · [[graphrag]] · [[agent-memory-systems]] · [[mempalace]] · [[graphify]] · [[llm-maintained-wiki]] · [[llm-from-scratch]] · [[microgpt-build-an-llm-from-scratch]]. The [[deep-research]] skill (M13) writes these at depth as NAO seeds topics.