Um guia prático para escolher modelos, calibrar esforço de raciocínio e distribuir trabalho entre agentes sem desperdiçar capacidade, tempo ou orçamento.

No desenvolvimento tradicional assistido por IA, escolher um modelo é relativamente simples: seleciona-se um modelo, envia-se uma pergunta e avalia-se a resposta. No desenvolvimento de software agêntico, essa lógica deixa de ser suficiente. Um agente pode passar dezenas de minutos trabalhando, navegar por milhares de linhas de código, executar comandos, alterar arquivos, criar testes, consultar documentação, revisar o próprio trabalho e delegar partes do problema a outros agentes.

Nesse cenário, usar sempre o modelo mais capaz é uma estratégia tecnicamente preguiçosa e economicamente ruim. O modelo mais caro frequentemente passa boa parte da sessão procurando arquivos, corrigindo imports, executando testes conhecidos e realizando outras tarefas que modelos menores fariam com qualidade equivalente. No extremo oposto, usar sempre o modelo mais econômico transfere custo para retrabalho, supervisão e correção de erros.

A estratégia mais eficiente é tratar a seleção de modelos como uma forma de arquitetura de execução:

1. Escolher um modelo principal capaz de coordenar o trabalho cotidiano.
2. Reservar modelos superiores para ambiguidade, arquitetura, segurança, debugging difícil e decisões de alto impacto.
3. Delegar exploração, transformação e tarefas repetitivas a modelos rápidos e baratos.
4. Usar o menor nível de esforço de raciocínio que entregue resultado confiável.
5. Separar planejamento, execução e revisão, mesmo quando todos fazem parte do mesmo objetivo.
6. Medir resultado por entrega válida, não por quantidade de mensagens ou aparência de inteligência.

Em termos práticos, a recomendação-base deste artigo é:

Plataforma	Configuração cotidiana	Escalonamento
OpenAI Codex	Terra com esforço Medium como coordenador	Luna para tarefas mecânicas; Sol High ou XHigh para problemas difíceis
Claude Code	Sonnet com esforço Medium ou High como coordenador	Haiku para exploração; Opus High ou XHigh para decisões difíceis
Claude Code, goal misto	opusplan com esforço High	Opus planeja e Sonnet executa
Tarefa excepcionalmente longa	Sol/Ultra no ecossistema OpenAI ou Fable no ecossistema Anthropic	Somente quando a escala e o risco justificarem

O princípio é simples: o melhor modelo não deve executar todas as tarefas; deve entrar nos pontos em que sua inteligência adicional muda materialmente o resultado.

---

1. O que muda no desenvolvimento de software agêntico

Um assistente de código responde. Um agente de código age.

Essa diferença parece pequena, mas altera toda a economia do trabalho. Quando um agente recebe um objetivo de longa duração, cada decisão errada pode gerar uma cadeia de efeitos:

• explorar a parte errada do repositório;
• interpretar incorretamente uma regra de negócio;
• escolher uma arquitetura inadequada;
• implementar dezenas de arquivos sobre uma premissa falsa;
• escrever testes que confirmam o próprio erro;
• consumir contexto e franquia corrigindo o caminho depois.

Por isso, capacidade de raciocínio e custo não devem ser avaliados apenas por resposta. Devem ser avaliados por ciclo completo:

mermaid flowchart TD A["Entender o objetivo"] --> B["Explorar o sistema"] B --> C["Planejar a mudança"] C --> D["Implementar"] D --> E["Testar e observar"] E --> F["Revisar riscos"] F --> G{"Critérios atendidos?"} G -- Não --> C G -- Sim --> H["Entregar resultado"]

Cada etapa possui uma exigência cognitiva diferente. Encontrar referências é uma tarefa de busca. Projetar uma transação distribuída é uma tarefa de julgamento. Corrigir um import é uma transformação mecânica. Investigar uma condição de corrida exige raciocínio causal. Usar a mesma combinação de modelo e esforço em todas elas é conveniente para a interface, mas ineficiente para o sistema.

1.1 A unidade correta de otimização

O erro comum é perguntar:

Qual é o melhor modelo para programar?

A pergunta útil é:

Qual combinação de agente, modelo, esforço, ferramentas e critérios de verificação produz esta entrega com menor custo total e risco aceitável?

Essa formulação inclui cinco dimensões:

Dimensão	Pergunta
Capacidade	O problema exige busca, execução ou julgamento profundo?
Esforço	Quanto raciocínio adicional altera a qualidade do resultado?
Contexto	O agente precisa compreender um arquivo, um módulo ou todo o sistema?
Autonomia	Ele apenas recomenda ou pode modificar e executar?
Verificação	Há testes, compilador, análise estática ou revisão que detectem erros?

Quanto mais forte for a verificação automática, mais seguro é delegar a execução a um modelo econômico. Quanto mais ambígua e irreversível for a decisão, maior deve ser a capacidade do modelo responsável.

---

2. Modelo e esforço são controles diferentes

O modelo define o teto de capacidade. O nível de esforço define quanto dessa capacidade será usado para raciocinar sobre uma tarefa específica.

Um modelo superior com esforço baixo pode ser adequado para uma tarefa curta que ainda exige bom julgamento. Um modelo intermediário com esforço alto pode resolver problemas razoavelmente complexos sem recorrer ao modelo mais caro. E um modelo pequeno com esforço elevado não se transforma magicamente em um modelo de fronteira; ele apenas dedica mais computação dentro de seus próprios limites.

2.1 Escala prática de esforço

Embora OpenAI e Anthropic usem controles ligeiramente diferentes, a interpretação operacional pode ser normalizada:

Nível	Uso recomendado	Sinal de uso incorreto
Low ou Light	Busca, alteração mecânica, resposta curta e tarefa totalmente delimitada	O agente começa a ignorar impactos ou premissas
Medium	Implementação cotidiana que exige planejamento moderado	Há muitas tentativas, regressões ou correções posteriores
High	Problemas com múltiplas etapas, casos-limite e necessidade de validação	O agente passa tempo demais em tarefa trivial
XHigh ou Extra High	Arquitetura, segurança, debugging difícil e mudança transversal	Quase toda tarefa é classificada como crítica
Max	Problema excepcional, único e de alto impacto	Uso como padrão; latência alta e retornos decrescentes
Ultra ou mecanismos equivalentes	Trabalho grande e realmente decomponível	Paralelização de tarefas dependentes ou concorrência sobre os mesmos arquivos

A regra saudável é começar no menor nível plausível e escalar com base em evidência. Evidência significa falha de testes, ambiguidade real, hipóteses concorrentes, impacto transversal ou risco elevado — não apenas a sensação de que “pensar mais deve ser melhor”.

2.2 O paradoxo do esforço máximo

Effort máximo pode melhorar problemas difíceis, mas também pode produzir:

• latência desnecessária;
• consumo excessivo de tokens;
• análise de alternativas irrelevantes;
• alterações maiores do que o necessário;
• excesso de confiança decorrente de uma resposta mais elaborada.

O modelo não recebe bom senso adicional só porque ganhou mais tempo. Se o objetivo estiver mal definido, ele poderá raciocinar longamente sobre a ambiguidade errada. Antes de aumentar o esforço, melhore o critério de conclusão.

---

3. A família OpenAI no Codex

Na família GPT-5.6 usada pelo Codex, a divisão de papéis é clara:

Modelo	Papel principal	Onde se destaca
GPT-5.6 Luna	Execução rápida e econômica	Busca, extração, transformação, classificação e tarefas repetitivas
GPT-5.6 Terra	Modelo equilibrado para trabalho cotidiano	Features, bugs, refatorações, integrações e uso de ferramentas
GPT-5.6 Sol	Modelo de fronteira para trabalho complexo	Arquitetura, ambiguidade, investigação difícil, segurança e acabamento

A documentação oficial de modelos do Codex descreve Luna como a opção para tarefas claras e repetíveis, Terra como o modelo pragmático de uso geral e Sol como a escolha para trabalho complexo e aberto.

3.1 Matriz de tarefas para Codex

Tipo de tarefa	Modelo	Effort	Justificativa
Localizar arquivos, símbolos e referências	Luna	Low	Trabalho de busca bem definido
Explicar um trecho pequeno	Luna	Low	Contexto delimitado e resultado verificável
Formatar, corrigir lint e organizar imports	Luna	Low	Transformação mecânica
Gerar DTOs, schemas e tipos	Luna	Low ou Medium	Padrões previsíveis
Criar testes unitários simples	Luna	Medium	Comportamento já expresso no código
Produzir documentação técnica básica	Luna	Medium	Baixo risco e alta repetição
Criar CRUD convencional	Luna ou Terra	Medium	Terra se houver regras de domínio
Explorar repositório desconhecido	Terra	Medium	Exige síntese entre vários arquivos
Diagnosticar erro de build	Terra	Medium	Busca mais interpretação
Implementar feature bem especificada	Terra	Medium	Melhor ponto de equilíbrio
Corrigir bug reproduzível	Terra	Medium	Escalar se houver múltiplas causas
Integrar API externa	Terra	Medium ou High	Autenticação, retries e idempotência elevam o risco
Refatorar múltiplos módulos	Terra	High	Necessidade de preservar invariantes
Revisar pull request	Terra	High	Rastrear impactos e casos-limite
Investigar performance	Terra ou Sol	High	Sol quando a causa não for evidente
Resolver concorrência e condições de corrida	Sol	High ou XHigh	Raciocínio causal complexo
Fazer debugging sem reprodução clara	Sol	High ou XHigh	Muitas hipóteses e evidências dispersas
Tomar decisão arquitetural	Sol	High ou XHigh	Trade-offs duradouros
Revisar segurança e permissões	Sol	XHigh	Alto impacto de falsos negativos
Resolver o problema mais difícil do ciclo	Sol	Max	Uso excepcional
Auditar sistema amplo e decomponível	Sol	Ultra	Delegação paralela com síntese central

3.2 O custo relativo importa

Na tabela de créditos consultada em agosto de 2026, Sol consome aproximadamente 2,5 vezes os créditos de Terra por token, enquanto Terra consome aproximadamente dez vezes os créditos de Luna. A proporção exata pode mudar, e o consumo real também depende de contexto, ferramentas, cache e tokens de saída. A conclusão operacional, porém, é estável: manter Sol em tarefas repetitivas reduz drasticamente a quantidade de trabalho possível dentro da mesma franquia. Consulte a tabela oficial de preços e limites.

3.3 O problema do goal com modelo único

Ao iniciar um goal, o modelo selecionado permanece como agente principal. Ele não troca silenciosamente de Luna para Terra ou Sol a cada passo do ciclo. Portanto, uma tabela de modelos por tarefa não basta quando o objetivo contém exploração, arquitetura, implementação e revisão.

A solução é usar o modelo principal como coordenador e delegar subtarefas a agentes especializados.

Uma configuração equilibrada é:

Papel	Modelo	Effort	Responsabilidade
Coordenador	Terra	Medium	Decompor, distribuir, integrar e verificar
Explorador	Luna	Low	Mapear código e retornar evidências
Implementador	Terra	Medium	Alterações bem delimitadas
Revisor	Sol	High	Correção, regressões, segurança e testes
Arquiteto	Sol	XHigh	Decisões estruturais e invariantes

O Codex permite definir agentes locais com model e model_reasoning_effort próprios. A precedência dessas configurações e os mecanismos de delegação estão descritos na documentação oficial de subagentes.

Exemplo de configuração do Codex

Configuração do projeto em .codex/config.toml:

toml [agents] enabled = true max_concurrent_threads_per_session = 4 default_subagent_model = "gpt-5.6-terra" default_subagent_reasoning_effort = "medium"

Agente explorador em .codex/agents/explorer.toml:

```toml
name = "explorer"
description = "Exploração rápida e somente leitura do repositório."
model = "gpt-5.6-luna"
model_reasoning_effort = "low"
sandbox_mode = "read-only"

developer_instructions = """
Mapeie arquivos, símbolos, dependências e fluxos relevantes.
Não altere código. Retorne evidências e um resumo objetivo.
"""
```

Agente revisor em .codex/agents/reviewer.toml:

```toml
name = "reviewer"
description = "Revisão profunda de correção, segurança e regressões."
model = "gpt-5.6-sol"
model_reasoning_effort = "high"
sandbox_mode = "read-only"

developer_instructions = """
Revise alterações procurando bugs, regressões, riscos de segurança,
problemas de concorrência e ausência de testes. Não edite arquivos.
"""
```

O AGENTS.md deve conter a política de roteamento. Sem uma instrução explícita, o agente principal pode não delegar ou pode herdar sua própria configuração para tarefas que mereciam outro modelo.

```markdown
Para objetivos com múltiplas etapas:

1. Atue como coordenador antes de editar.
2. Delegue exploração e busca ao explorer.
3. Delegue implementação delimitada ao worker.
4. Use reviewer após mudanças críticas.
5. Use architect somente quando houver decisão estrutural real.
6. Paralelize leitura; serialize alterações sobre os mesmos arquivos.
7. Integre os resultados e execute a verificação final no agente principal.
   ```

3.4 Quando usar Max e Ultra

No Codex, Max aumenta o tempo de raciocínio sobre um único problema. Ultra vai além: utiliza subagentes para decompor trabalho complexo. Isso torna Ultra apropriado para uma auditoria com frentes independentes, mas inadequado para uma sequência estritamente dependente ou para vários agentes editando a mesma região do código.

Use Max quando houver um problema único excepcionalmente difícil. Use Ultra quando houver várias investigações independentes cujo resultado possa ser consolidado. Para o resto, Medium e High cobrem a maior parte do trabalho profissional.

---

4. A família Anthropic no Claude Code

Em agosto de 2026, a linha principal disponível no Claude Code inclui:

Modelo	Papel principal	Onde se destaca
Claude Haiku 4.5	Modelo rápido e econômico	Exploração, busca, transformações e tarefas simples
Claude Sonnet 5	Equilíbrio entre velocidade e inteligência	Desenvolvimento cotidiano e execução agentic
Claude Opus 5	Raciocínio complexo e coding agentic	Arquitetura, debugging difícil e decisões de alto impacto
Claude Fable 5	Maior capacidade para agentes de longa duração	Grandes migrações, investigação profunda e objetivos maiores que uma sessão comum

Fable depende de disponibilidade para a conta ou organização e não é o modelo padrão. Os aliases haiku, sonnet, opus, fable e best podem resolver para versões diferentes conforme o provedor; por isso, ambientes que exigem reprodutibilidade devem fixar o identificador completo. Consulte a visão oficial dos modelos Claude e a configuração de modelos do Claude Code.

4.1 Matriz de tarefas para Claude Code

Tipo de tarefa	Modelo ou configuração	Effort	Justificativa
Localizar arquivos e referências	Haiku	Padrão do modelo	O Explore integrado já usa Haiku
Mapear estrutura do repositório	Explore/Haiku	Thoroughness conforme necessidade	Mantém ruído fora do contexto principal
Explicar código pequeno	Haiku	Padrão do modelo	Escopo delimitado
Formatação, imports e lint	Haiku	Padrão do modelo	Alteração mecânica
Gerar DTOs e boilerplate	Haiku ou Sonnet	Low ou Medium no Sonnet	Sonnet quando houver decisões
Criar testes unitários	Sonnet	Medium	Boa compreensão com custo controlado
Criar CRUD convencional	Sonnet	Medium	Melhor padrão para execução
Diagnosticar build ou teste	Sonnet	Medium	Escalar após evidência de complexidade
Implementar feature bem definida	Sonnet	High	Combina execução e validação
Integrar API externa	Sonnet	High	Mais atenção a falhas e contratos
Refatorar múltiplos módulos	Sonnet	High ou XHigh	Opus se houver invariantes complexos
Revisar pull request comum	Sonnet	High	Bom equilíbrio entre profundidade e uso
Revisar segurança	Opus	High ou XHigh	Alto custo de erro
Investigar condição de corrida	Opus	XHigh	Raciocínio causal e temporal
Fazer debugging sem reprodução	Opus	High ou XHigh	Exploração de hipóteses concorrentes
Tomar decisão arquitetural	Opus	XHigh	Julgamento e trade-offs
Resolver problema excepcional	Opus	Max	Sessão pontual, não padrão
Planejar e executar um goal misto	opusplan	High	Opus planeja; Sonnet executa
Executar rotina com decisões difíceis	Sonnet + Advisor Opus	Medium ou High	Escalonamento apenas nos pontos críticos
Conduzir migração extensa e autônoma	Fable	High ou XHigh	Mantém objetivos de longa duração
Investigar incidente amplo	Fable	XHigh	Quando autonomia e profundidade justificarem
Executar automação recorrente	Haiku ou Sonnet	Low ou Medium	Evita gastar Opus em repetição

4.2 Effort no Claude Code

Fable 5, Opus 5 e Sonnet 5 oferecem low, medium, high, xhigh e max. High é o padrão nos modelos atuais compatíveis. Max é restrito à sessão e deve ser avaliado com cuidado, pois a própria Anthropic alerta para retornos decrescentes e tendência a pensar além do necessário.

O Claude Code também possui mecanismos relacionados:

Mecanismo	O que faz	Quando usar
ultrathink no prompt	Solicita raciocínio mais profundo naquele turno sem alterar formalmente o effort da API	Uma decisão difícil isolada
ultracode	Planeja um fluxo dinâmico para tarefas substantivas com raciocínio XHigh	Sessão excepcionalmente complexa
opusplan	Usa Opus em plan mode e troca para Sonnet na execução	Goal misto com planejamento importante
Advisor	Permite ao modelo principal consultar um modelo superior em pontos críticos	Trabalho majoritariamente rotineiro com algumas decisões difíceis

4.3 opusplan: roteamento por fase

O opusplan é a resposta nativa mais simples para um problema comum: o planejamento exige mais inteligência do que a implementação.

bash claude --model opusplan --effort high

Durante o plan mode, o Claude Code usa Opus. Ao entrar em execução, troca automaticamente para Sonnet. Essa separação reduz o desperdício de manter Opus durante buscas, alterações mecânicas e ciclos de teste.

Há uma limitação: opusplan roteia por fase, não por natureza de cada subtarefa. Ele não decide, por si só, que busca deve ir para Haiku e revisão de segurança para Opus. Para isso, são necessários subagentes especializados.

4.4 Sonnet com Advisor Opus

Para goals em que a maior parte da execução é cotidiana, mas algumas decisões merecem um modelo superior, o Advisor pode ser ainda mais econômico:

bash claude --model sonnet --effort medium --advisor opus

O Sonnet continua como agente principal. Ele pode consultar Opus antes de escolher uma abordagem, quando encontra erros recorrentes ou antes de declarar o trabalho concluído. O Advisor recebe a conversa e devolve orientação ao agente principal. Como cada consulta adiciona consumo, não é uma licença para chamar Opus a cada passo. A proposta é justamente reservar o modelo superior para pontos de decisão. O recurso é experimental e sua disponibilidade depende da forma de acesso; veja a documentação oficial do Advisor.

4.5 Subagentes no Claude Code

O Claude Code já inclui alguns comportamentos úteis:

• o agente Explore usa Haiku e trabalha somente com leitura;
• o agente Plan herda o modelo principal;
• o agente general-purpose também herda o modelo principal;
• agentes personalizados podem definir model, effort, ferramentas e permissões;
• a descrição do agente influencia a delegação automática;
• uma menção explícita ao agente garante maior controle sobre o roteamento.

Agentes de projeto são armazenados em .claude/agents/. Agentes pessoais ficam em ~/.claude/agents/. A configuração completa está na documentação oficial de subagentes do Claude Code.

Exemplo de agente implementador

Arquivo .claude/agents/worker.md:

```markdown

name: worker
description: Implementa proativamente tarefas bem definidas e delimitadas.
model: sonnet
effort: medium
tools: Read, Grep, Glob, Edit, Write, Bash

---

Implemente mudanças delimitadas seguindo os padrões do projeto.
Execute os testes relevantes e reporte arquivos alterados, decisões e riscos.
Não amplie o escopo sem devolver a decisão ao coordenador.
```

Exemplo de agente revisor

Arquivo .claude/agents/reviewer.md:

```markdown

name: reviewer
description: Use proativamente após mudanças críticas para revisar correção e segurança.
model: opus
effort: high
tools: Read, Grep, Glob, Bash
permissionMode: plan

---

Revise o diff procurando regressões, falhas de segurança,
problemas de concorrência, inconsistências de domínio e lacunas de testes.
Não altere arquivos. Retorne achados priorizados com evidências.
```

4.6 Quando usar Fable

Fable não deve substituir Sonnet como padrão. Ele existe para outra classe de problema: objetivos grandes, ambíguos e autônomos, capazes de ocupar uma sessão longa e exigir investigação e verificação continuadas.

Use Fable quando pelo menos duas destas condições forem verdadeiras:

• o trabalho é maior que uma sessão comum;
• a solução exige descobrir o problema antes de implementá-lo;
• há muitas etapas dependentes e risco de perder o objetivo central;
• a verificação precisa ser repetida ao longo do processo;
• uma decisão ruim no início geraria grande retrabalho.

Se o trabalho é apenas volumoso e previsível, subagentes Sonnet ou Haiku provavelmente são melhores. Volume não é sinônimo de inteligência.

---

5. Comparação operacional entre OpenAI e Anthropic

Os nomes são diferentes, mas os papéis se aproximam:

Papel operacional	OpenAI	Anthropic
Execução rápida e repetitiva	Luna	Haiku
Coordenador e implementador cotidiano	Terra	Sonnet
Raciocínio complexo e revisão crítica	Sol	Opus
Objetivo excepcionalmente amplo	Sol com Ultra	Fable ou arquitetura de subagentes
Aumento de raciocínio em uma tarefa	High, XHigh ou Max	High, XHigh, Max ou ultrathink
Delegação paralela profunda	Ultra e subagentes	Subagentes e agent teams
Planejamento forte, execução econômica	Configuração manual de agentes	opusplan
Consulta pontual a modelo superior	Revisor ou arquiteto como subagente	Advisor

Essa tabela não afirma equivalência de qualidade entre modelos. Ela compara função dentro de uma arquitetura de execução. Benchmarks isolados ajudam pouco quando o resultado depende de ferramentas, contexto, qualidade da especificação e capacidade de verificar o trabalho.

5.1 Onde a Anthropic oferece mais automação de roteamento

O Claude Code possui dois mecanismos particularmente convenientes:

• opusplan, que troca automaticamente entre planejamento e execução;
• Advisor, que permite consultar um modelo superior durante a sessão.

Além disso, o agente Explore usa Haiku por padrão. Isso cria algum roteamento de modelo sem configuração extensa.

5.2 Onde o Codex oferece controle explícito

O Codex permite associar modelo e effort a agentes customizados e definir defaults de subagentes no projeto. Ultra também transforma o esforço máximo em delegação automática quando a tarefa pode ser dividida.

A consequência prática é que o Codex recompensa uma política explícita em AGENTS.md, enquanto o Claude Code oferece mais atalhos prontos, mas ainda se beneficia de uma boa política em CLAUDE.md e de agentes personalizados.

---

6. A arquitetura recomendada para goals mistos

Um goal real raramente é homogêneo. “Implemente autenticação por passkeys”, por exemplo, pode envolver:

1. localizar o fluxo atual;
2. compreender sessões e identidade;
3. escolher arquitetura e bibliotecas;
4. alterar backend;
5. alterar frontend;
6. criar migrations;
7. escrever testes;
8. revisar segurança;
9. executar testes e corrigir regressões.

Escolher Sol ou Opus para tudo é desperdício. Escolher Luna ou Haiku para tudo é risco. O desenho apropriado é hierárquico:

mermaid flowchart TD A["Coordenador: Terra ou Sonnet"] --> B["Explorador: Luna ou Haiku"] A --> C["Implementador: Terra ou Sonnet"] A --> D["Especialista: Sol ou Opus"] B --> E["Evidências"] C --> F["Código e testes"] D --> G["Decisões e revisão"] E --> A F --> A G --> A

6.1 Responsabilidade do coordenador

O coordenador não deve fazer tudo. Ele deve:

• transformar o objetivo em etapas verificáveis;
• identificar dependências entre etapas;
• escolher quais tarefas podem ser paralelizadas;
• delegar trabalho com escopo e contrato de retorno;
• preservar decisões e requisitos no contexto principal;
• integrar os resultados;
• executar a verificação final;
• interromper o ciclo quando os critérios forem atingidos.

Essa função exige mais consistência do que genialidade. Por isso, Terra e Sonnet são os melhores defaults. Sol ou Opus como coordenadores são justificáveis quando o próprio objetivo é dominado por ambiguidade, arquitetura ou investigação.

6.2 Contrato de uma subtarefa

Toda delegação deve conter:

Elemento	Exemplo
Objetivo	Mapear onde tokens de sessão são emitidos e validados
Escopo	Somente src/auth e src/middleware
Permissão	Somente leitura
Saída	Lista de arquivos, fluxo e riscos
Limite	Não propor arquitetura nem editar código
Critério	Toda afirmação deve citar arquivo ou teste

Sem esse contrato, o subagente pode produzir uma segunda narrativa completa do sistema, poluir o contexto e duplicar o trabalho do coordenador.

6.3 Paralelizar leitura, serializar escrita

Exploração, análise de logs, revisão e pesquisa são bons candidatos à execução paralela. Alterações de código sobre os mesmos módulos não são. Vários agentes escrevendo simultaneamente podem:

• sobrescrever mudanças;
• criar decisões incompatíveis;
• produzir migrations conflitantes;
• ajustar testes a implementações diferentes;
• elevar o custo de integração acima do ganho de velocidade.

Se for necessário paralelizar escrita, use worktrees ou divisões de propriedade realmente independentes.

---

7. Política de seleção recomendada

7.1 Regra geral

Use a seguinte escada:

1. Modelo rápido quando o resultado é claro, local e verificável.
2. Modelo equilibrado com Medium quando a tarefa exige planejamento normal.
3. Modelo equilibrado com High antes de migrar para o modelo superior.
4. Modelo superior com High ou XHigh quando há ambiguidade, risco ou causalidade complexa.
5. Max apenas para o problema mais difícil do ciclo.
6. Ultra, Fable ou múltiplos agentes somente quando o tamanho e a decomposição justificarem.

7.2 Distribuição inicial de uso

Para uma equipe que ainda não possui métricas próprias, uma distribuição inicial razoável é:

Classe	Participação sugerida	OpenAI	Anthropic
Trabalho mecânico	20% a 30%	Luna	Haiku
Desenvolvimento cotidiano	55% a 65%	Terra	Sonnet
Trabalho complexo	10% a 15%	Sol	Opus
Exceções de longa duração	Até 5%	Sol Max/Ultra	Opus Max/Fable

Esses percentuais não são metas rígidas. São um antídoto contra a tendência de usar o modelo mais caro como padrão. Cada equipe deve substituí-los por dados reais.

7.3 Escolha pelo risco, não pelo tamanho do diff

Um diff de três linhas em autorização pode ser mais arriscado que uma alteração mecânica de quinhentos arquivos. O modelo deve ser escolhido pelo tipo de decisão:

Baixo risco	Alto risco
Alteração repetitiva	Controle de acesso
Código gerado por schema	Migração destrutiva
Documentação	Concorrência
Teste adicional	Criptografia
Renomeação	Faturamento e cálculo financeiro
Formatação	Contrato público e compatibilidade

---

8. Estratégias para economizar franquia sem reduzir qualidade

8.1 Reduza contexto inútil

Contexto custa e degrada. Logs enormes, resultados completos de testes, arquivos irrelevantes e exploração sem foco consomem tokens e escondem as decisões importantes. Subagentes de exploração devem devolver sínteses com evidências, não despejar toda a pesquisa na conversa principal.

8.2 Separe discovery de implementação

Antes de editar:

• descubra onde a mudança deve ocorrer;
• registre invariantes;
• identifique testes existentes;
• determine como provar conclusão.

Esse pequeno investimento reduz ciclos caros de implementação e reversão.

8.3 Use verificação determinística

Modelos menores tornam-se muito mais úteis quando cercados por:

• compilador;
• type checker;
• lint;
• testes unitários;
• testes de contrato;
• análise estática;
• migrations reversíveis;
• comparação de snapshots;
• validação de schema.

O objetivo não é confiar que o modelo acertará. É construir um sistema em que erros sejam baratos e visíveis.

8.4 Evite reiniciar contexto sem necessidade

Trocar de modelo ou iniciar uma nova sessão pode exigir releitura de contexto e perder cache. Quando a plataforma oferece subagente, Advisor ou roteamento por fase, esses mecanismos tendem a preservar melhor a continuidade do objetivo.

8.5 Limite turnos e escopo

Agentes sem limites podem continuar refinando uma solução já suficiente. Defina:

• número máximo de ciclos sem progresso;
• arquivos ou módulos permitidos;
• comandos de verificação obrigatórios;
• condições para escalar ao modelo superior;
• condição clara de parada.

8.6 Não use modo rápido para economizar

Fast mode geralmente compra menor latência, não menor consumo. Se o objetivo é preservar franquia, troque para um modelo menor ou reduza effort. Velocidade de resposta e eficiência econômica são controles diferentes.

---

9. Antipadrões

9.1 O modelo premium como funcionário universal

Usar Sol, Opus ou Fable para localizar arquivo, corrigir import e executar lint é como contratar um arquiteto principal para reorganizar a gaveta de cabos. Ele provavelmente fará bem. A conta também chegará bem.

9.2 O modelo econômico como arquiteto invisível

Delegar arquitetura a Luna ou Haiku porque a implementação parece pequena é economizar no ponto errado. Modelos menores são excelentes quando o resultado esperado está claro. Eles não devem definir sozinhos invariantes de longo prazo em sistemas críticos.

9.3 Max como superstição

Selecionar Max para “garantir qualidade” sem medir resultado é superstição com interface bonita. Max deve ser comparado a High ou XHigh em tarefas representativas. Se não reduzir falhas, retrabalho ou tempo total, não há justificativa.

9.4 Paralelismo decorativo

Criar vários subagentes para uma tarefa linear aumenta consumo, coordenação e conflitos. Paralelismo só ajuda quando há independência real.

9.5 Revisão pelo mesmo raciocínio

Pedir ao mesmo agente para implementar e imediatamente declarar que sua implementação está correta oferece pouca independência. Para mudanças críticas, use um revisor com instruções próprias, contexto de leitura e, quando necessário, modelo superior.

9.6 Goal sem definição de pronto

“Melhore a autenticação” não é um goal verificável. “Implemente passkeys preservando login existente, cobrindo os navegadores definidos, com migrations reversíveis e testes para cadastro, login, recuperação e revogação” é.

O segundo pode terminar. O primeiro pode consumir franquia até desenvolver personalidade própria.

---

10. Como medir a estratégia

Não otimize por tokens isoladamente. O modelo barato que exige três correções pode custar mais que o modelo intermediário que acerta de primeira. A unidade econômica adequada é a entrega aceita.

10.1 Métricas recomendadas

Métrica	Definição
Custo por tarefa aceita	Créditos ou tokens até todos os critérios serem atendidos
Taxa de primeira aprovação	Percentual de entregas aceitas sem retrabalho relevante
Ciclos de correção	Quantas iterações ocorreram após a primeira implementação
Tempo até verde	Tempo até compilação, lint e testes passarem
Taxa de escalonamento	Percentual de tarefas que precisaram de modelo superior
Eficiência do escalonamento	Quantos escalonamentos realmente resolveram o bloqueio
Regressões posteriores	Bugs atribuídos à alteração após integração
Consumo por papel	Participação de exploradores, implementadores e revisores

10.2 Experimento simples

Durante duas semanas, classifique as tarefas por tipo e compare:

• Terra Medium versus Terra High;
• Sonnet Medium versus Sonnet High;
• implementação com e sem revisor superior;
• goal monolítico versus coordenação com subagentes;
• Opus ou Sol como principal versus modelo equilibrado com escalonamento.

Registre custo, tempo, testes, intervenções humanas e retrabalho. A política definitiva deve vir dos seus repositórios e não de tabelas genéricas — inclusive desta.

---

11. Receitas operacionais

11.1 Feature comum

OpenAI: Terra Medium como principal, Luna para exploração e Sol High apenas na revisão se a área for crítica.
Anthropic: Sonnet Medium ou High, Explore/Haiku para busca e Opus como revisor quando necessário.

11.2 Arquitetura seguida de implementação

OpenAI: Sol High para o plano; Terra Medium para implementação; Sol High para revisão das invariantes.
Anthropic: opusplan High, com Opus no planejamento e Sonnet na execução.

11.3 Debugging difícil

OpenAI: Terra High para reproduzir e reduzir hipóteses; Sol XHigh se a causa continuar ambígua.
Anthropic: Sonnet High com Advisor Opus; migrar o principal para Opus XHigh se o problema dominar toda a sessão.

11.4 Migração mecânica ampla

OpenAI: Luna Medium em lotes pequenos, compilador e testes a cada lote; Terra para integração.
Anthropic: Haiku ou Sonnet Medium; não usar Fable só porque há muitos arquivos.

11.5 Revisão de segurança

OpenAI: Sol XHigh em agente somente leitura.
Anthropic: Opus XHigh em agente somente leitura.
Em ambos, separar revisão de correção e segurança pode aumentar cobertura, desde que os agentes retornem evidências concretas.

11.6 Goal excepcionalmente longo

OpenAI: coordenador Sol High ou Ultra, com Terra e Luna em subtarefas.
Anthropic: Fable High ou XHigh quando disponível; alternativamente, Sonnet como coordenador com especialistas Opus.

---

12. Recomendação final

A configuração mais saudável para desenvolvimento de software agêntico não é “sempre o melhor modelo”. É uma hierarquia de trabalho:

1. Modelo equilibrado no centro: Terra no Codex; Sonnet no Claude Code.
2. Modelo econômico nas bordas: Luna ou Haiku para busca, transformação e volume.
3. Modelo superior nos pontos de decisão: Sol ou Opus para arquitetura, segurança, debugging difícil e revisão crítica.
4. Capacidade excepcional sob demanda: Max, Ultra ou Fable quando o problema realmente exceder o fluxo cotidiano.
5. Roteamento explícito: AGENTS.md, CLAUDE.md, agentes personalizados, opusplan e Advisor devem transformar a política em comportamento repetível.
6. Verificação como infraestrutura: testes e ferramentas determinísticas permitem delegar mais trabalho a modelos econômicos sem sacrificar confiança.
7. Medição por entrega: custo, tempo e qualidade devem ser observados até a tarefa ser aceita, não apenas por mensagem.

O ganho real não vem de encontrar um modelo que faça tudo. Vem de construir um sistema em que cada modelo faça a parte do trabalho para a qual sua capacidade é economicamente racional.

Essa é a diferença entre apenas usar agentes de código e praticar engenharia de software agêntica.

---

Referências oficiais

OpenAI

• Modelos do ChatGPT Work e Codex
• Preços, créditos e limites de uso
• Subagentes e configuração de modelos
• Trabalho de longa duração e Goal mode

Anthropic

• Configuração de modelos no Claude Code
• Subagentes personalizados no Claude Code
• Advisor no Claude Code
• Visão geral dos modelos Claude

Modelos, aliases, preços, esforços disponíveis e limites mudam com frequência. Antes de transformar este guia em política organizacional rígida, valide a documentação oficial e execute benchmarks nos repositórios reais da equipe.