🎯 When parallel-and-merge wins
An ensemble isn’t free (you saw the N+1 cost in the previous module), so it needs to pay the cost itself. It wins exactly when the the cost of getting it wrong is high e There’s no answer key for verification: open decisions, high-stakes writing, analyses where a model’s blind spot could go unnoticed.
The logic: when the task has high variance — good models sometimes get it right and sometimes stumble — running several and letting the judge choose reduces the chance you'll get stuck with a lapse from a single model. Diversity buys robustness, not genius.
🆕 Three decision terms
- Cost of error: how much a bad response hurts (from “redo it in 5 min” to “lost a client”).
- Verifiable: is there a test/answer key that tells you whether the answer is correct (runnable code, verifiable fact)?
- Variance: how much the quality of the same model’s response varies across runs.
🥇 When 1 strong model is enough
The honest default is uncomfortable for anyone who loves orchestration: For most tasks, a top model on its own is already enough. If it solves the task, the ensemble only adds cost and wait time without changing the result. That’s exactly what the 38 tests in Track 2 showed — 36 of 38 were technical ties, and the soloist was faster and cheaper.
An ensemble is the last rung, not the first. The question isn’t "how do I orchestrate?" but "do I need to orchestrate?".
📊 Signs that 1 model is enough
- The task is verifiable (there’s a test/answer key)—then you test the output from 1 model directly.
- A top model already meets the quality target in the common case.
- Speed or cost matter—the ensemble adds minutes and multiplies the bill.
🛠️ Build it yourself: the "judge" pattern
You don't need a special API to use the Fusion pattern. The pattern is yours—and Claude Code already launches sub-agents in parallel. Ask for N answers from different angles and a judge agent that merges. Manual ensemble, with full control and the cost visible before you pay.
💡 Practice: ensemble + judge at the helm
Goal: run the standard Fusion pattern (N candidates → judge combines them) yourself in Claude Code. Paste it, replace the <...> and run it.
Tarefa: <descreva a tarefa — ex.: "proponha um nome e tagline para o produto X"> Use o padrão ENSEMBLE + JUIZ: 1. Abra 3 sub-agents em PARALELO. Cada um resolve a tarefa INTEIRA, mas por um ângulo diferente: - agente 1: ângulo <ex.: "ousado / memorável"> - agente 2: ângulo <ex.: "claro / descritivo"> - agente 3: ângulo <ex.: "técnico / sério"> 2. Depois, um agente JUIZ lê as 3 propostas, compara segundo <critério — ex.: "memorabilidade + clareza">, e produz UMA resposta final (escolhendo a melhor OU sintetizando um híbrido). O juiz deve justificar a escolha em 2 linhas.
How to verify: you’ll see the 3 agents running at the same time (the fan-out / parallel processing) and, at the end, a single answer with the judge’s rationale (the fusion). This is Fusion — without any Fusion API.
✓ Why build it yourself
- ✓You choose the angles and the judge's criteria
- ✓See the cost (N agents) before launching
- ✓Turn it on only when the task calls for robustness
✗ Caveats
- ✗Similar angles = similar candidates (no gain)
- ✗A weak judge makes poor choices—give it explicit criteria
- ✗Don’t use it for a task 1 agent can already handle
💰 Unit economics of orchestration
Unit economics is the cost (and return) of one unit — here, one delivered answer. The right question isn’t "which model is the smartest?" but “what’s the cost per acceptable result?”. Sometimes 3 cheap models + a judge beat 1 expensive model for the same money — and sometimes they don’t.
It’s the metric the field test author uses to decide: optimize unit economics, not benchmark vanity. Remember the numbers from Track 2 — the orchestrator came out 5× more expensive (US$ 53,60 vs US$ 10,66) and 4.5× slower for the same result. Terrible unit economics there; great in another context.
| Strategy | Relative cost | When it makes sense |
|---|---|---|
| 1 strong model | 1× | verifiable task / a top model is enough |
| 3 cheap models + judge | ~3–4× (but cheap/unit) | low-cost robustness through diversity |
| 3 expensive models + judge | ~4× the expensive one (high) | only if an error costs more than the bill |
| Closed orchestrator | 5× (Fugu, field test) | convenience + hedge, cost doesn't matter |
📊 The math that changes the decision
Ask for an answer: $ per good result = total cost ÷ success rate. A cheap model with 90% accuracy may have better unit economics than an expensive one with 95% — it depends on how much that extra 5% costs and the price of each error.
🛡️ Vendor hedging: don't get locked into 1 provider
Vendor lock-in is being locked into a single provider: if it raises prices, goes offline, or degrades its model, you have nowhere to go. Running across multiple providers — through a single API, as OpenRouter does — is a hedge: insurance against this risk.
The clever detail: this benefit Doesn’t depend of the ensemble improving the response. Even when several models produce the same result, the ability to switch providers without rewriting anything already has value — pure operational resilience.
🛡️ What hedging gives you
- •Continuity: if one model goes down, your app continues with the others.
- •Bargaining power: Doesn’t depend on a single price; you can switch.
- •Adaptation: A better new model comes along? Plug it in without rewriting.
⚖️ Hedge ≠ extra quality
Don’t confuse Fusion’s two benefits. One is quality (ensemble + judge gets it right more often) and requires real diversity. The other is resilience (vendor hedge) and is worthwhile even without any quality gain. Decide which one you’re buying—sometimes it’s just the second.
🔮 The skill of the future: cost-aware orchestration
Put it all together, and the skill the course aimed to build emerges: know when to orchestrate, which pattern to use, and at what cost. It’s not about memorizing products — it’s about the judgment to apply the decision ladder and choose between decomposing (Fugu), replicating and merging (Fusion), or simply using a single model.
The field test author’s takeaway sums it up well: the idea is to future — avoid being locked into one provider, optimize unit economics, and use the cheapest model that doesn’t sacrifice quality. But today, for a lot of work, still isn’t worth it. The skill is knowing how to distinguish "today" from "when."
🎯 The conscious orchestrator checklist
- 1.Do I need to orchestrate? Can’t a strong model already solve it? (default: use just 1)
- 2.Which pattern? Does the task call for specialized pieces (decomposition) or robustness through diversity (ensemble)?
- 3.At what cost? Does the $ per good result justify N+1 and the wait?
- 4.Do I buy quality or a hedge? Be honest about which benefit you’re paying for.
Quick recall (optional): what is the first question an aware orchestrator asks?
✅ Module summary
You completed the course:
Fundamentals → Fugu (decomposes) → Fusion (ensemble). Now you orchestrate — or not — with cost awareness.