🎛️ Comparando modelos por papel

Imagine uma oficina mecânica. Você não usa a chave de impacto pneumática para apertar um parafuso de óculos, nem uma chave de fenda para soltar a roda de um caminhão. Cada serviço tem a ferramenta certa — e usar a cara demais é desperdício, usar a fraca demais é retrabalho. Com uma frota de subagentes é igual: o papel do agente decide o modelo. Quem escaneia 200 arquivos quer velocidade e baixo custo; quem raciocina sobre uma decisão irreversível quer o motor mais forte. O mapa abaixo é o coração deste módulo: uma matriz papel × modelo.

↑ A matriz papel × modelo: cada papel cai na coluna do motor certo. Pílula em destaque = padrão recomendado; tracejada = 2º olhar de outro provedor.

A família Claude vem em três tamanhos, e cada um tem um ponto doce. Haiku é o operário veloz: escaneia, busca, resume, lê documentação. Sonnet é o profissional do dia a dia: constrói código e revisa. Opus é o arquiteto: raciocina sobre decisões difíceis, analisa segurança, pensa fundo. Não é "Opus é melhor logo uso Opus em tudo" — é "o papel pede tal motor".

A frota não precisa ser de uma família só. Os modelos GPT e o ambiente Codex (CLI da OpenAI, visto no módulo 4.2) entram como um segundo olhar: um revisor que pensa diferente do construtor. Famílias distintas erram de jeitos distintos — então um achado que dois provedores confirmam é bem mais confiável.

você > O Sonnet acabou de escrever este módulo de auth.
        Peça a um revisor em GPT/Codex pra refutar:
        onde isso quebra? Só os furos, sem reescrever.

# construtor (Sonnet) e revisor (outra família) erram
# de formas diferentes — a divergência é o valor.
# o que os DOIS apontam é o que merece atenção.

Além de Anthropic e OpenAI, há um mercado inteiro — Google (Gemini), modelos abertos rodando localmente, provedores especializados. O erro é decorar nomes; o certo é pensar por capacidade. Para a sua matriz, todo modelo cai numa de três classes, e você encaixa o papel na classe — não na marca da semana.

Aqui está a tensão central. Modelo forte pensa mais fundo, mas custa mais e demora mais. Modelo leve é barato e instantâneo, mas raso. Não existe almoço grátis: você escolhe onde gastar profundidade. A pergunta operacional é simples — o custo de errar este papel é alto? Se for, suba. Se não, desça.

Trocar de modelo tem um preço escondido: cada subagente começa do zero e precisa reunir o contexto de novo. Por isso a troca compensa em tarefas grandes, não em recados de 30 segundos. E há dois eixos de troca: trocar de nível (Haiku↔Sonnet↔Opus) por profundidade, e trocar de provedor (Claude↔GPT) por independência.

O destino é uma frota heterogênea: vários subagentes apontando para modelos diferentes, cada um no seu papel. Não é um sistema homogêneo "tudo Opus" nem "tudo Haiku" — é uma mistura desenhada. E toda mistura vive sob três forças que puxam em direções opostas: custo, latência e qualidade. Você não maximiza as três; você as equilibra por papel.

↑ A mesma matriz, agora com o trade-off explícito por linha. Repare: onde a qualidade exigida sobe, custo e latência sobem junto — e isso é aceitável só nos papéis críticos.

Uma frota heterogênea não é um arquivo só — é um conjunto de subagentes, cada um com seu campo model apontando para o motor do seu papel. Abaixo, quatro .md recortados lado a lado: repare como o papel (na description) e o modelo andam juntos.

# ── file-scanner.md ─ papel: ESCANEAR (volumoso, raso) ──
name: file-scanner
description: Varre o repo e lista arquivos/símbolos
  relevantes. Use para mapear antes de qualquer leitura.
tools: Grep, Glob                # só localizar
model: haiku                      # barato + rápido

# ── builder.md ─ papel: CONSTRUIR (de ofício) ──────────
name: builder
description: Implementa a mudança descrita no plano.
tools: Read, Edit, Write, Bash
model: sonnet                     # equilíbrio

# ── arch-thinker.md ─ papel: RACIOCÍNIO (juízo) ────────
name: arch-thinker
description: Decide a arquitetura e os trade-offs de
  uma mudança grande. Use ANTES de construir.
tools: Read, Grep
model: opus                       # raciocínio profundo

# ── cross-reviewer.md ─ papel: REVISAR (2º olhar) ──────
name: cross-reviewer
description: Refuta o trabalho do builder buscando
  furos. Use após qualquer mudança sensível.
tools: Read, Grep
model: gpt-codex     # OUTRA família = independência

Três prompts para o maestro distribuir modelos por papel. O padrão é sempre nomear o papel e justificar o motor — barato onde dá, forte onde precisa, independente na revisão.

Para este job, monte uma frota por papel: use Haiku pra
escanear e buscar, Sonnet pra construir e revisar, e Opus
só pro raciocínio de arquitetura. Justifique cada escolha
em uma linha (custo/latência/qualidade).

O builder (Sonnet) terminou. Agora rode um revisor em
outro provedor (GPT/Codex) só pra refutar: liste os furos
que um modelo da MESMA família talvez não veja. Não
reescreva — só aponte.

Revise minha frota: que papéis hoje em Sonnet poderiam
cair pra Haiku sem risco (erro barato de checar)? E que
papéis merecem subir pra Opus porque o erro seria caro?
Devolva só a matriz papel → modelo ajustada.

É assim que a frota heterogênea aparece no terminal: cada subagente roda no modelo do seu papel, e a coluna do meio mostra qual motor cada um está usando. Repare no custo relativo à direita — os papéis volumosos em Haiku custam quase nada; só o raciocínio em Opus pesa.

↑ Recriação ilustrativa do terminal (não é screenshot real). Cada subagente no motor do seu papel; o custo concentra-se só no Opus do raciocínio.