🎚️ Modelo por tarefa

Pense numa oficina mecânica. Pra trocar um pneu você não chama o engenheiro-chefe — manda o ajudante, é rápido e barato. Pra remontar o motor, aí sim o mestre entra. Modelos de IA funcionam igual: existe um tier baixo (rápido, barato, ótimo pra trabalho braçal), um tier médio (o operário competente que constrói e revisa) e um tier alto (o mestre que você só aciona quando o problema exige raciocínio de verdade). No Claude Code esses três são Haiku, Sonnet e Opus — e cada subagente pode rodar o seu.

↑ A escada de tiers: cada degrau pra cima ganha raciocínio, mas paga em custo e latência. Suba só o quanto a tarefa exige.

Haiku é o tier barato e rápido. Ele brilha no trabalho mecânico de alto volume: escanear uma pasta inteira, buscar uma string em centenas de arquivos, resumir um log gigante, ler documentação e devolver os 5 pontos que importam. Tarefas onde a resposta é "ache e relate", não "pense fundo".

Sonnet é o tier médio — o cavalo de batalha do dia a dia. Ele constrói (escreve código, monta arquivos, implementa um passo de um plano) e revisa (lê um diff e aponta bugs). É inteligente o bastante para a maioria das tarefas reais e ainda assim muito mais barato que o tier alto. Quando você está em dúvida, Sonnet costuma ser o default seguro.

Opus é o tier caro e mais lento, reservado para o que realmente exige raciocínio profundo: decisões de arquitetura, análise de segurança, planejamento delicado, depuração de um problema que ninguém entende. Aqui o custo extra se paga: um erro de arquitetura sai muito mais caro que alguns tokens a mais.

Subir de tier não é só "ficar mais esperto". São três dials que se movem juntos: mais raciocínio vem com mais custo e mais latência (demora mais para responder). Escolher modelo é decidir de quanto de cada um a tarefa precisa — e parar de pagar pelo que ela não usa.

Eis o detalhe que pega muita gente. O subagente não herda a sua conversa — ele começa do zero, com a janela vazia. Antes de produzir qualquer coisa, ele precisa reunir o contexto sozinho: ler os arquivos, entender o terreno. Isso muda a conta: parte do trabalho dele é só "se situar", e esse trabalho de leitura é exatamente o que um tier barato faz bem.

# o maestro já conversou com você por 1h.
# o subagente NÃO sabe nada disso. ele nasce assim:

contexto: (vazio)
tarefa:   "ache onde o login quebra nos 40 arquivos de /auth"

# 1º ele GASTA tokens só pra se situar:
#   - lista a pasta /auth
#   - abre os 40 arquivos
#   - mapeia o fluxo de login
# SÓ DEPOIS ele começa a raciocinar sobre o bug.

# lição: essa fase de "reunir contexto" é leitura bruta
# → é trabalho de Haiku, não de Opus.

Há um custo fixo em disparar um subagente: ele nasce em branco, reúne contexto, depois trabalha. Para uma tarefa grande, esse custo se dilui — vale a pena. Para uma microtarefa de 30 segundos, a sobrecarga de "se situar" é maior que o trabalho em si: é desperdício. E para o caso comum, existe o atalho honesto — herdar o modelo do pai.

Esta é a tabela canônica do curso para escolher modelo. Leia da esquerda para a direita: cada tier tem um nível de raciocínio, um custo relativo, uma latência — e um conjunto de tarefas onde é a escolha certa. Guarde-a; ela volta na Trilha 4 quando compararmos modelos de outros provedores.

A escolha de modelo mora no campo model do frontmatter. Veja três subagentes de um mesmo projeto, cada um no tier justificado pela sua tarefa — e leia o comentário que explica por quê cada um está onde está.

# ── 1) file-scout.md ── varre o repo atrás de um padrão
---
name: file-scout
description: Varre o repositório atrás de onde um símbolo
  ou string aparece e devolve só os caminhos + linhas.
tools: Read, Grep, Glob       # só leitura
model: haiku                  # ← é "ache e relate": tier barato basta
---
You are a fast code scout. Liste apenas os arquivos e linhas
onde o alvo aparece. Não explique, não opine. Só o mapa.


# ── 2) feature-builder.md ── implementa um passo do plano
---
name: feature-builder
description: Implementa um passo bem-definido de um plano
  (uma função, uma validação, um endpoint) e roda os testes.
tools: Read, Edit, Write, Bash
model: sonnet                 # ← constrói código: o operário competente
---
You are a focused implementer. Implemente exatamente o passo
pedido, siga o padrão do projeto e rode os testes ao final.


# ── 3) security-reviewer.md ── caça falha de segurança
---
name: security-reviewer
description: Revisa o diff em busca de falhas de segurança
  (injeção, vazamento, authz). Use após mexer em auth/pagamentos.
tools: Read, Grep, Glob       # read-only: revisor não edita
model: opus                   # ← raciocínio de segurança: o erro é caro
---
You are a senior security reviewer. Pense como atacante.
Aponte cada risco com arquivo:linha e a gravidade. Não conserte.

Três prompts para mandar o maestro casar modelo com tarefa. Repare no padrão: você diz o tier e a razão — e deixa o trabalho barato no Haiku, o caro no Opus.

Use um subagente em Haiku pra escanear /auth e me
trazer só os trechos que tocam o login. Depois,
com esse resumo, use Opus só pra decidir onde está
o bug. Não rode o Opus na varredura.

Crie um subagente "doc-summarizer" read-only com
model: haiku — a tarefa é só ler docs e resumir,
então quero o tier mais barato e rápido.

Esse é um revisor de segurança: coloque model: opus.
O erro aqui é caro, então quero o raciocínio máximo,
mesmo custando mais. Mantenha o agente read-only.

É assim que a escolha aparece no terminal. O maestro disparou três subagentes e a status line mostra, para cada um, qual modelo está rodando. Note o desenho: a frota de varredura em Haiku, o builder em Sonnet, e só o revisor de segurança em Opus — chefe caro, trabalhadores baratos.

↑ Recriação ilustrativa do terminal (não é screenshot real). A status line revela o modelo de cada subagente — e a frota barata carrega o grosso do trabalho.