🎯 Quando paralelo-e-fundir ganha
O ensemble não é grátis (você viu o custo N+1 no módulo anterior), então ele precisa pagar o próprio preço. Ele ganha exatamente quando o custo de errar é alto e não há gabarito para verificar: decisões abertas, redação de alto risco, análises onde um ângulo cego de um modelo passaria batido.
A lógica: quando a tarefa tem alta variância — bons modelos às vezes acertam, às vezes derrapam — rodar vários e deixar o juiz escolher reduz a chance de você ficar preso a um lapso de um modelo só. A diversidade compra robustez, não genialidade.
🆕 Três termos de decisão
- Custo do erro: o quanto dói uma resposta ruim (de "refaço em 5 min" a "perdi um cliente").
- Verificável: existe um teste/gabarito que diz se a resposta está certa (código que roda, fato checável)?
- Variância: o quanto a qualidade da resposta de um mesmo modelo oscila entre execuções.
🥇 Quando 1 modelo forte basta
O default honesto é desconfortável para quem ama orquestrar: na maioria das tarefas, um top model sozinho já basta. Se ele resolve, o ensemble só adiciona custo e espera sem mudar o resultado. Foi exatamente o que os 38 testes da Trilha 2 mostraram — 36 de 38 deram empate técnico, e o solo era mais rápido e barato.
O ensemble é o último degrau, não o primeiro. A pergunta não é "como orquestro?" e sim "preciso orquestrar?".
📊 Sinais de que 1 modelo basta
- A tarefa é verificável (tem teste/gabarito) — então você testa a saída de 1 modelo direto.
- Um top model já bate a meta de qualidade no caso comum.
- Velocidade ou custo importam — o ensemble adiciona minutos e multiplica a conta.
🛠️ Montar você mesmo: o padrão "juiz"
Você não precisa de uma API especial para usar o padrão Fusion. O padrão é seu — e o Claude Code já abre sub-agents em paralelo. Peça N respostas por ângulos diferentes e um agente-juiz que funde. Ensemble manual, com controle total e o custo visível antes de pagar.
💡 Pratique: ensemble + juiz na mão
Objetivo: rodar o padrão Fusion (N candidatos → juiz funde) você mesmo, no Claude Code. Cole, troque os <...> e rode.
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.
Como verificar: você verá os 3 agentes rodando ao mesmo tempo (o fan-out / paralelo) e, no fim, uma resposta única com a justificativa do juiz (a fusão). Isso é a Fusion — sem nenhuma API de Fusion.
✓ Por que montar na mão
- ✓Você escolhe os ângulos e o critério do juiz
- ✓Vê o custo (N agentes) antes de disparar
- ✓Liga só quando a tarefa pede robustez
✗ Cuidados
- ✗Ângulos parecidos = candidatos parecidos (sem ganho)
- ✗Juiz fraco escolhe mal — dê critério explícito
- ✗Não use em tarefa que 1 agente já resolve
💰 Unit economics da orquestração
Unit economics é o custo (e o retorno) de uma unidade — aqui, uma resposta entregue. A pergunta certa não é "qual modelo é o mais inteligente?", e sim "qual o custo por resultado aceitável?". Às vezes 3 modelos baratos + um juiz batem 1 modelo caro pelo mesmo dinheiro — e às vezes não.
É a métrica que o autor do field test usa para decidir: otimizar unit economics, não vaidade de benchmark. Lembre dos números da Trilha 2 — o orquestrador saiu 5× mais caro (US$ 53,60 vs US$ 10,66) e 4,5× mais lento para o mesmo resultado. Péssima unit economics ali; ótima em outro contexto.
| Estratégia | Custo relativo | Quando faz sentido |
|---|---|---|
| 1 modelo forte | 1× | tarefa verificável / top model basta |
| 3 modelos baratos + juiz | ~3–4× (mas barato/un.) | robustez por diversidade a baixo custo |
| 3 modelos caros + juiz | ~4× do caro (alto) | só se erro custar mais que a conta |
| Orquestrador fechado | 5× (Fugu, field test) | conveniência + hedge, custo não importa |
📊 A conta que muda a decisão
Pergunte por resposta: $ por resultado bom = custo total ÷ taxa de acerto. Um modelo barato com 90% de acerto pode ter unit economics melhor que um caro com 95% — depende de quanto custa o 5% extra e do preço de cada erro.
🛡️ Hedge de vendor: não travar em 1 provider
Vendor lock-in é ficar preso a um único fornecedor: se ele sobe o preço, sai do ar ou degrada o modelo, você não tem para onde ir. Rodar em vários providers — via uma API só, como a OpenRouter faz — é um hedge: um seguro contra esse risco.
O detalhe esperto: esse benefício não depende de o ensemble melhorar a resposta. Mesmo quando vários modelos dão o mesmo resultado, a capacidade de trocar de provider sem reescrever nada já tem valor — resiliência operacional pura.
🛡️ O que o hedge te dá
- •Continuidade: um modelo cai, sua app segue com os outros.
- •Poder de barganha: não depende de um preço só; pode migrar.
- •Adaptação: modelo novo melhor aparece? Pluga sem reescrever.
⚖️ Hedge ≠ qualidade extra
Não confunda os dois ganhos da Fusion. Um é qualidade (ensemble + juiz acerta mais) e exige diversidade real. O outro é resiliência (hedge de vendor) e vale mesmo sem nenhum ganho de qualidade. Decida qual você está comprando — às vezes é só o segundo.
🔮 A skill do futuro: orquestrar com consciência de custo
Junte tudo e aparece a habilidade que o curso queria formar: saber quando orquestrar, qual padrão usar e a que custo. Não é decorar produtos — é o julgamento de aplicar o ladder de decisão e escolher entre decompor (Fugu), replicar-e-fundir (Fusion) ou simplesmente usar um modelo só.
O takeaway do autor do field test resume bem: a ideia é o futuro — não travar em um provider, otimizar unit economics, usar o modelo mais barato que não sacrifica qualidade. Mas hoje, para muito trabalho, ainda não compensa. A skill é justamente saber distinguir o "hoje" do "quando".
🎯 O checklist do orquestrador consciente
- 1.Preciso orquestrar? Um modelo forte já não resolve? (default: usa 1 só)
- 2.Qual padrão? A tarefa pede pedaços especializados (decompor) ou robustez por diversidade (ensemble)?
- 3.A que custo? O $ por resultado bom justifica o N+1 e a espera?
- 4.Compro qualidade ou hedge? Seja honesto sobre qual benefício você está pagando.
Recuperação rápida (opcional): qual é a primeira pergunta do orquestrador consciente?
✅ Resumo do módulo
Você concluiu o curso:
Fundamentos → Fugu (decompõe) → Fusion (ensemble). Agora você orquestra — ou não — com consciência de custo.