🧪 O exame: 38 tarefas, 4 waves, graded por código
Antes dos números, a régua. O field test (2026-06-22) colocou 38 tarefas divididas em 4 waves de dificuldade crescente, somando 334 chamadas graded. "Graded por código" significa que cada resposta passou por testes ocultos — a chave foi provada por um solver independente antes de qualquer chamada paga. Sem juiz humano, sem achismo: ou passou no teste, ou não.
O prompt foi idêntico dos dois lados (Fugu e Opus), com 3 a 7 runs por tarefa para medir consistência, e partial credit nas tarefas multi-regra (você ganha proporcional ao número de regras cumpridas). Essa é a base que dá peso a tudo que vem depois.
🆕 Novo aqui? Três termos
- Graded por código: a nota vem de testes automatizados, não de opinião — remove viés do avaliador.
- Testes ocultos: os casos de avaliação não são mostrados ao modelo, para ele não "decorar" a resposta.
- Partial credit: em tarefas com várias regras, acertar 4 de 5 vale 4/5, não zero.
🌊 As 4 waves
| Wave | Tarefas | Caráter |
|---|---|---|
| Wave 1 | 14 | puzzles "textbook-hard" (teto do solo já alto) |
| Wave 2 | 11 | "designed traps" (armadilhas projetadas) |
| Wave 3 | 6 | "dense multi-rule specs" (specs densas, multi-regra) |
| Wave 4 | 7 | "failure frontier" (feitas para quebrar 1 modelo) |
Total: 14 + 11 + 6 + 7 = 38 tarefas. Cada wave é mais difícil que a anterior — a Wave 4 foi desenhada para encontrar onde um modelo solo trava.
🎯 Quem foi mais correto
O placar de correção, somando as 38 tarefas: 36 empates · 2 vitórias do soloist (Opus) · 0 vitórias do time (Fugu). Lendo wave a wave, o time escondido nunca achou uma resposta que o solo não achasse. Nas palavras do field test: "nem 1 vez em 38".
🏁 Correção por wave (Fugu / Opus / empate)
| Wave | Vitórias Fugu | Vitórias Opus | Empates |
|---|---|---|---|
| Wave 1 | 0 | 1 | 13 |
| Wave 2 | 0 | 0 | 11 |
| Wave 3 | 0 | 1 | 5 |
| Wave 4 | 0 | 0 | 7 |
| Total | 0 | 2 | 36 |
As 2 vitórias do Opus vieram da Wave 1 e da Wave 3 (detalhadas no tópico 5). O time não venceu nenhuma, em nenhuma wave.
⚠️ A leitura crua
Mais modelos não produziram mais acerto. A promessa "combine vários e passe do teto do solo" (Trilha 1) não se confirmou neste exame: o teto do solo já era suficiente para empatar quase tudo, e o ganho marginal do time foi exatamente zero em correção.
⏱️ O relógio: 4.5× mais lento
Se a correção empatou, o relógio não. No total do exame, o Fugu levou 357 minutos contra 80 minutos do Opus — cerca de 4.5× mais lento. Em código simples o contraste é brutal: Opus respondia em 3–6 segundos, o Fugu em 2–7 minutos — para a mesma resposta.
Latência média por tarefa, Fugu (azul) vs Opus (ciano). Em todas as waves o time é multiplicamente mais lento — o preço de esperar o fan-out inteiro.
📊 Latência média por tarefa (segundos)
| Wave | Fugu | Opus | Razão aprox. |
|---|---|---|---|
| Wave 1 | 205s | 40s | ~5× |
| Wave 2 | 110s | 19s | ~6× |
| Wave 3 | 161s | 6s | ~27× |
| Wave 4 | 97s | 15s | ~6× |
| Total | 357 min | 80 min | 4.5× |
A Wave 3 (specs densas) foi a mais desproporcional: o Opus resolvia em 6s o que o Fugu levava ~161s — mesma resposta, ~27× o tempo.
💸 A conta: 5× mais caro
A conta final do exame: US$ 53,60 (Fugu, 163 calls) contra US$ 10,66 (Opus, 171 calls) — cerca de 5× mais caro. Repare: o Fugu fez até menos chamadas externas, mas custou muito mais. O motivo é o custo escondido da Trilha 1, agora com nota fiscal: a maior parte do gasto do Fugu são os orchestration tokens — o que o time privado lê e escreve por dentro, todo billado.
Custo médio por tarefa, Fugu (azul) vs Opus (ciano). A Wave 3 é a mais desigual: ~$0.358 vs ~$0.014 — o time custa ~26× para empatar.
📊 Custo médio por tarefa (US$)
| Wave | Fugu | Opus | Razão aprox. |
|---|---|---|---|
| Wave 1 | $0.389 | $0.100 | ~4× |
| Wave 2 | $0.297 | $0.046 | ~6× |
| Wave 3 | $0.358 | $0.014 | ~26× |
| Wave 4 | $0.276 | $0.037 | ~7× |
| Total | $53.60 (163 calls) | $10.66 (171 calls) | 5× |
Mais caro com menos chamadas: o custo não está no número de calls, está nos tokens internos do time. Você paga o pool inteiro, não só a resposta final.
🥈 As 2 derrotas do time
Das 38 tarefas, só 2 não empataram — e nas duas foi o solo que ganhou. O time não só não venceu nada: onde houve diferença, perdeu. Coordenar não imuniza contra escorregões; às vezes adiciona pontos de falha.
Wave 3 — "fix every bug in stats module"
O módulo tinha 6 bugs. O Opus pegou os 6 em todo run (100%). O Fugu, repetidamente, perdeu 1 — ficou em 80% (5/6). Mesma tarefa, e o time consistentemente deixou um bug passar.
Wave 1 — "strict Roman numeral validation"
A regra era rejeitar formas inválidas como "IIII". O Opus fez 5/5; o Fugu fez 4/5 — escorregou uma vez, aceitando o que deveria recusar.
📊 As 2 derrotas, lado a lado
| Tarefa | Fugu | Opus | Vencedor |
|---|---|---|---|
| Stats: 6 bugs | 80% (5/6) | 100% (6/6) | Opus |
| Romano estrito | 4/5 | 5/5 | Opus |
⚠️ A lição
Quando o ganho de juntar modelos é zero (correção) e o time ainda escorrega onde o solo acerta, a conta de custo × benefício pende forte para o modelo único — exatamente o que o ladder do próximo tópico formaliza.
🪜 O ladder de decisão + setup no Claude Code
O veredito não é "orquestrador é ruim" — é "use o critério certo". O field test propõe um ladder de decisão: uma escada de 3 perguntas que diz, para cada tarefa, se o orquestrador ganha seu lugar ou se um modelo forte sozinho é a melhor compra.
O ladder: só no degrau final o orquestrador vence. Neste exame, toda tarefa "caiu pelo topo" — um modelo forte já empatava, mais rápido e barato.
🪜 Os 3 degraus
- 1.Um modelo forte já resolve? → SIM: use 1 modelo (mais rápido, barato e empata).
- 2.NÃO → quer 1 endpoint + hedge de vendor, e a espera e a conta não importam? → NÃO: 1 modelo ainda é a melhor compra.
- 3.SIM → aí sim o orquestrador ganha seu lugar.
✓ Quando escolher Fugu
- ✓Quer zero código de orquestração + 1 endpoint
- ✓Quer hedge contra lock-in de 1 vendor
- ✓Custo e espera não importam para o seu caso
✗ Quando ficar com 1 modelo forte
- ✗Um top model já resolve a tarefa
- ✗Você liga para velocidade (o time soma minutos)
- ✗Você liga para custo (paga o time escondido)
🛠️ Prático: setup conceitual do Fugu no Claude Code
A ideia, no nível de conceito, é apontar o Claude Code para o endpoint do Fugu usando sua API key — o mesmo padrão de "base URL + API key" que você usa para qualquer provider compatível. Honestidade primeiro: os passos exatos (endpoint correto, nome das variáveis, billing) vêm da documentação oficial da Sakana (sakana.ai) e do markdown de setup do autor. O field test relata que o setup do Fugu não é trivial — não é só "trocar endpoint + key" como num provider OpenAI-compatible comum. Trate o exemplo abaixo como esqueleto, não como receita literal.
# Esqueleto conceitual — substitua pelos valores reais da doc da Sakana. # NÃO é um endpoint garantido; confirme em sakana.ai e no .md do autor. export ANTHROPIC_BASE_URL="<base-url-da-sakana>" # ex.: a URL do gateway Fugu export ANTHROPIC_API_KEY="<sua-api-key>" # sua chave do Fugu # depois, no Claude Code, você apontaria a sessão para esse provider # e usaria o modelo "fugu-ultra" conforme a doc indicar. claude --model fugu-ultra "resuma este repositório e aponte 3 riscos"
Billing: há duas formas — assinatura (plano mensal, como o autor que estourou a janela de 5h no plano de US$ 200/mês) ou pay-as-you-go via API (paga por token usado). Para experimentar sem comprometer um plano, pay-as-you-go costuma ser o caminho — mas lembre do custo escondido: você paga os orchestration tokens do time. Confirme valores e endpoints em sakana.ai antes de rodar.
Recuperação rápida (opcional): no field test, qual foi o resultado headline?
✅ Resumo do módulo
Próxima trilha:
Trilha 3 — OpenRouter Fusion: o ensemble (mesmo prompt, N modelos, um juiz)