Regras de Seleção de Modelo: Quando Usar Opus, Sonnet ou Haiku

Estas são as regras enumeradas que este site usa para combinar uma tarefa com um nível de modelo Claude - Haiku, Sonnet, Opus ou Fable - com base na complexidade e latência, condensadas da cobertura mais aprofundada da família de modelos em outros locais deste site em formato de regras.

Como Usar Esta Checklist

Aplique estas regras por local de chamada, não uma vez para todo o aplicativo - um único aplicativo geralmente abrange vários níveis.
Comece com a regra do "nível padrão" para a categoria da sua tarefa, em seguida, aplique as regras de escalonamento e desescalonamento para ajustar.
Revise as designações de nível sempre que a Anthropic lançar um novo modelo - uma regra ajustada ao perfil de custo do Sonnet 4.6 pode não ser mais válida para o Claude Sonnet 5.
Registre o raciocínio para qualquer escolha de nível não padrão na revisão de código, não apenas no próprio código.

Nível Padrão por Tipo de Tarefa

Classificação e extração têm como padrão Haiku. Tarefas curtas e bem definidas - rotular um ticket de suporte, extrair um campo de um formulário, rotear uma solicitação - raramente precisam de mais do que a profundidade de raciocínio do Claude Haiku 4.5, e ele é o nível mais rápido e barato.
Chat de propósito geral e geração de conteúdo têm como padrão Sonnet. Claude Sonnet 5 é o nível de modelo padrão do site por um motivo - ele lida com a maioria das tarefas conversacionais, de rascunho e de raciocínio moderado com qualidade próxima à do Opus, sem a latência ou o custo do Opus.
Raciocínio em várias etapas e tarefas de codificação complexas têm como padrão Opus. Claude Opus 4.8 é o padrão correto quando uma tarefa requer a manutenção de muitas restrições simultaneamente, planejamento em várias etapas ou produção de código que deve estar correto na primeira tentativa.
O trabalho mais exigente e de longo prazo do agente tem como padrão Fable. Claude Fable 5 é reservado para tarefas que genuinamente precisam de seu raciocínio estendido e coerência de longo prazo - migrações autônomas em larga escala, pesquisa aprofundada ou loops de agente que rodam por muitos minutos sem supervisão.
Nunca escolha um nível porque ele "parece mais seguro". Um nível escolhido por cautela em vez de evidências é uma decisão de custo e latência tomada sem dados - exija uma lacuna de qualidade real antes de escalar.

Regras de Escalonamento (Subindo um Nível)

Escale quando a saída de um nível inferior falhar na revisão em uma amostra representativa. Execute 20-50 exemplos reais no nível mais barato primeiro; escale apenas se a taxa de falha for alta o suficiente para importar para o caso de uso.
Escale quando a tarefa exigir a manutenção de mais do que um punhado de restrições de uma vez. Raciocínio com múltiplas restrições - "satisfazer estas cinco regras de negócios simultaneamente" - é onde os níveis inferiores degradam primeiro.
Escale para loops de agente autônomos e sem supervisão com efeitos colaterais no mundo real. Um humano revisando cada etapa tolera mais erros do modelo do que um agente fazendo pagamentos ou registrando tickets por conta própria.
Escale temporariamente durante uma transição de modelo, não permanentemente por padrão. Se um novo tipo de tarefa não for comprovado, comece em um nível mais alto para estabelecer uma linha de base de qualidade, e então desescale assim que tiver evidências de que o nível mais barato se mantém.
Escale quando o custo de uma resposta errada for assimétrico. Um ticket de suporte classificado incorretamente é barato de corrigir; uma resposta errada em um contexto financeiro ou médico não é - deixe o custo da falha, não apenas a complexidade da tarefa, direcionar o nível.

Regras de Desescalonamento (Descendo um Nível)

Desescale assim que a saída de uma tarefa tiver sido estável em corridas de avaliação suficientes. Se o Sonnet igualou a qualidade do Opus em seu conjunto de avaliação para um tamanho de amostra significativo, mova a rota para baixo e continue monitorando.
Desescale qualquer rota onde a saída seja determinística ou baseada em modelo. Tarefas com uma forma de saída estreita e bem especificada raramente precisam da profundidade de raciocínio do nível superior, independentemente de como a tarefa é lida em prosa.
Desescale caminhos síncronos e sensíveis à latência primeiro. Um usuário esperando por uma resposta sente diretamente a latência adicional do Opus ou Fable - se a qualidade se mantiver no Sonnet ou Haiku, a vantagem de latência por si só justifica a descida.
Desescale antes de escalar o tráfego, não depois que a fatura chegar. Executar uma avaliação de custo/qualidade antes que um recurso vá para o tráfego completo de produção é mais barato do que reagir a uma fatura grande.

Regras de Latência

Trate o orçamento de latência e a complexidade da tarefa como eixos independentes. Uma tarefa pode ser complexa, mas tolerante à latência (um trabalho em lote noturno) ou simples, mas crítica em latência (autocompletar) - decida cada eixo separadamente antes de escolher um nível.
Roteie solicitações síncronas voltadas para o usuário para longe do nível mais pesado por padrão. Opus e Fable trocam throughput por profundidade; coloque-os em um caminho de solicitação ao vivo apenas quando a tarefa genuinamente precisar dessa profundidade e a experiência do usuário puder tolerar a espera.
Mova raciocínio pesado tolerante à latência para processamento assíncrono ou em lote. Se uma tarefa precisar de raciocínio no nível Opus ou Fable, mas o usuário não precisar da resposta de forma síncrona, execute-a como um trabalho em segundo plano em vez de bloquear uma solicitação.

Regras de Governança

Anote a decisão de nível para cada rota de produção, não apenas as exceções. Um breve comentário ou entrada de configuração nomeando o modelo e o motivo impede que o próximo engenheiro o altere silenciosamente sem saber por quê.
Revise as designações de nível em uma cadência fixa, não apenas quando algo quebrar. Uma passagem trimestral pelas rotas de produção detecta rotas que deveriam ter sido desescaladas meses atrás.
Nunca permita que a preferência local de um único engenheiro defina o nível de uma rota compartilhada. O nível do modelo é uma decisão em nível de equipe com consequências de custo e confiabilidade - direcione-o através da mesma revisão que qualquer outra alteração de configuração de produção recebe.

FAQs

Qual é a maneira mais rápida de decidir o nível inicial de uma nova rota?

Combine a tarefa com sua categoria (classificação, chat geral, raciocínio em várias etapas, trabalho de agente de longo prazo).
Comece no nível padrão dessa categoria.
Só escale quando tiver evidências - uma revisão de amostra falha, não um palpite - de que o nível padrão não é suficiente.

Tarefas sensíveis à latência devem sempre usar Haiku?

Não - latência e complexidade são eixos separados. Uma tarefa sensível à latência que também é genuinamente complexa pode precisar de Sonnet ou de uma chamada Opus processada em segundo plano, em vez de forçar Haiku em uma tarefa que ele não consegue lidar bem.

Qual amostra é grande o suficiente antes de desescalar uma rota?

Grande o suficiente para ser representativa do tráfego de produção variado, não apenas do caminho feliz - 20-50 exemplos reais são um ponto de partida razoável, mais para rotas de maior risco. O objetivo é a confiança, não um número mágico específico.

É alguma vez correto executar a mesma tarefa através de dois níveis diferentes?

Sim - um padrão comum é um nível barato fazendo uma primeira passagem (triagem, extração) e um nível mais capaz engajado apenas para o subconjunto de casos que a primeira passagem sinaliza como incertos ou de alto risco.

Por que esta lista trata "sentir-se mais seguro" como uma razão ruim para escalar?

Porque não é falsificável - uma decisão tomada por cautela em vez de evidências medidas não pode ser revisitada posteriormente com dados, portanto, tende a se tornar permanente mesmo depois de deixar de ser justificada.

Quando Claude Fable 5 é o padrão correto em vez de um escalonamento?

Para tarefas que são inerentemente de longo prazo e autônomas desde o início - migrações de código em larga escala, execuções de pesquisa estendidas ou loops de agente esperados para rodar muitos minutos sem supervisão - em vez de tarefas que simplesmente acabaram precisando de mais raciocínio do que o esperado.

A seleção de modelo interage com as regras de controle de custos?

Diretamente - a escolha do nível é geralmente a maior alavanca no custo por solicitação. Veja Regras de Controle de Custos para como cache e batching se compõem com a seleção de nível.

Quem deve ser o responsável pela revisão trimestral de níveis?

Normalmente, quem é responsável pelas regras Claude da equipe em geral - veja Como Regras Opinativas Previnem Incidentes de Produção Claude para entender por que um único proprietário responsável é mais importante do que o título específico.

O que acontece se duas rotas com tarefas semelhantes acabarem em níveis diferentes?

Isso é um sinal de que a deriva de decisão se infiltrou - revise ambas contra os mesmos critérios de avaliação e reconcilie-as, em vez de assumir que a divergência foi intencional.

As decisões de nível devem ser codificadas ou configuráveis?

Configurável é geralmente mais seguro - um valor de configuração ou sinalizador de recurso permite que uma alteração de nível seja revisada e revertida sem uma implantação de código, o que é importante quando um novo modelo é lançado e o padrão correto muda.

Um nível mais alto está alguma vez errado, mesmo quando a equipe pode pagá-lo?

Sim - além do custo, um nível desnecessariamente pesado adiciona latência que degrada a experiência do usuário em caminhos síncronos e pode tornar o comportamento mais difícil de prever para tarefas que um modelo mais leve e restrito teria lidado de forma mais previsível.

Como esta lista se relaciona com o conteúdo mais aprofundado da família de modelos em outros locais do site?

Esta página é a forma condensada de regras; as seções de token-economia e família-de-modelos-claude cobrem os detalhes subjacentes de custo, latência e capacidade dos quais estas regras são derivadas.

Relacionados

Como Regras Opinativas Previnem Incidentes de Produção Claude - por que escrever estas regras é mais importante do que qualquer escolha de nível individual.
As Regras Principais do Claude: Uma Lista de Referência Rápida - a versão condensada destas regras ao lado de todas as outras categorias.
Regras de Controle de Custos: Cache, Batching e Disciplina de Orçamento de Tokens - como cache e batching se compõem com as escolhas de nível feitas aqui.
Melhores Práticas das Regras Claude - todas as regras nesta seção reestilizadas como uma checklist.

Versões de Stack: Escrito contra a linha de modelos Claude atual em ~junho de 2026 - Claude Fable 5, Claude Opus 4.8, Claude Sonnet 5 (o padrão), e Claude Haiku 4.5 - e o SDK oficial anthropic para Python (última versão 0.x). Nomes de modelos, preços e versões de SDK mudam rapidamente - verifique os detalhes atuais em platform.claude.com/docs antes de confiar neles.