Opus, Sonnet ou Haiku: qual modelo da Claude API usar em cada tarefa?

Fala aí, beleza? Escolher errado o modelo padrão da sua aplicação é aquele tipo de erro que não aparece no code review, aparece na fatura no fim do mês 😅

A linha de modelos da Claude API hoje tem gente demais na mesa: Claude Fable 5, Claude Opus 5, Claude Opus 4.8, Claude Opus 4.7, Claude Opus 4.6, Claude Sonnet 5, Claude Sonnet 4.6 e Claude Haiku 4.5

E aí bate a dúvida clássica: vou de topo de linha pra não passar vergonha, ou vou de barato pra não quebrar?

A ideia deste post é te dar um critério de decisão por tipo de tarefa, com preço, contexto e as alavancas que mudam o custo sem você trocar de família de modelo

Bora?

Fable 5, Opus 5, Sonnet 5 e Haiku 4.5: preço, contexto e ID de API

Primeiro os números secos, que é o que a maioria das pessoas vai olhar antes de qualquer papo filosófico

Os preços são por milhão de tokens:

Se liga na distância: o Fable 5 custa dez vezes o Haiku 4.5 na entrada e dez vezes na saída

Isso não é detalhe, isso é decisão de arquitetura

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 114 aulas
• 4 projetos
• 9h 18min

Conhecer formação

E a janela de contexto de cada um?

Aqui é onde muita gente escolhe errado, porque olha só o preço e esquece que contexto curto vira retrabalho:

Repara numa coisa massa: o Sonnet 5 tem a mesma janela de 1M do Opus 5, pagando US$ 2 na entrada

Ou seja, contexto grande deixou de ser privilégio de modelo caro

Qual modelo usar em cada tipo de tarefa

Agora o que interessa: como distribuir o trabalho

Raciocínio profundo e tarefas longas: Claude Opus 5

O Opus 5 foi lançado em 24 de julho de 2026 e é posicionado como próximo da capacidade do Fable 5 pela metade do preço

A própria documentação descreve ele como um salto sobre o Opus 4.8, forte em raciocínio profundo, tarefas agênticas de longo horizonte e escala de computação em tempo de teste

Traduzindo pro nosso dia a dia: é o cara pra refatoração grande, pra agente que roda muitos passos sem supervisão, pra decisão de arquitetura

E ele está disponível em basicamente todo lugar: Claude, Claude Code, Claude API, Amazon Bedrock, Google Cloud Vertex AI e Microsoft Foundry

Uso geral e agentes em produção: Claude Sonnet 5

O Sonnet 5 saiu em 30 de junho de 2026 como o Sonnet mais agêntico até então, com foco em rodar agentes mais barato

E tem um detalhe que mudou o jogo em agosto: o preço promocional de lançamento virou permanente

A Anthropic cancelou o aumento que estava marcado pra 1º de setembro de 2026, então os US$ 2 de entrada e US$ 10 de saída seguem valendo, e o reajuste pra US$ 3 / US$ 15 não vai acontecer

Com 1M de contexto padrão e esse preço, o Sonnet 5 é o candidato natural a modelo padrão da sua aplicação

A lógica é bem parecida com a de escolher o modelo no Claude Code: o padrão resolve quase tudo, o caro entra por exceção

Volume alto, classificação e extração: Claude Haiku 4.5

O Haiku 4.5 continua sendo o Haiku mais recente da Anthropic, lançado em 15 de outubro de 2025

Não existe Haiku 5, e nem Haiku 4.6, então quem esperava um sucessor pode parar de atualizar a página do changelog 😀

O que ele entrega: 200 mil tokens de contexto, até 64 mil de saída, entrada de texto e imagem, e ele foi o primeiro Haiku com extended thinking, computer use e context awareness

Onde ele brilha: classificar ticket, extrair campo de documento, moderar conteúdo, rota de alto volume onde latência importa mais que sutileza

E aqui vai a recomendação oficial, que muita gente ignora: a documentação sugere começar pelo modelo mais rápido e barato (o Haiku 4.5), testar o seu caso de uso e só subir de modelo se o desempenho não atender

É o contrário do que a gente faz por instinto, né?

E o Fable 5, entra quando?

O Fable 5 é o modelo mais capaz de ampla disponibilidade da Anthropic, geralmente disponível desde 9 de junho de 2026 na Claude API, Amazon Bedrock, Google Cloud e Microsoft Foundry

Ele é o teto do que dá pra você chamar por API hoje

E tem o Claude Mythos 5, que não é de disponibilidade geral: fica restrito a clientes aprovados no Project Glasswing, por convite

Ou seja, pro desenvolvedor comum ele nem entra na conta de escolha

Antes de trocar de modelo: effort, cache de prompt e Batch API

Essa é a parte que separa quem só troca o nome do modelo na env de quem realmente controla custo

Existem alavancas que mudam preço e latência SEM você mexer na família do modelo:

Destaque pra última linha, que é fácil de passar batido: uma requisição de 900 mil tokens é cobrada na mesma taxa por token de uma de 9 mil

Não tem mais sobretaxa de contexto longo

E a documentação é bem direta: ajuste o effort ANTES de trocar de modelo

Muita gente sobe de Sonnet pra Opus quando na real precisava só de um nível a mais de esforço no mesmo modelo

Tome cuidado com o tokenizador novo:

Esse aqui é o pega que estraga planilha de custo

O tokenizador introduzido a partir do Claude Opus 4.7 pode gerar mais tokens pro mesmo texto de entrada em comparação com o Opus 4.6

O mesmo texto pode virar de 1,0 a 1,35 vez mais tokens (até 35% a mais), dependendo do tipo de conteúdo

Ou seja: comparar preço por milhão de tokens entre gerações sem medir o consumo real da SUA carga é comparar coisa diferente

Mede na sua aplicação, com o seu prompt, beleza?

E não esquece da aposentadoria de modelo:

O Claude Opus 4.1 foi aposentado em 5 de agosto de 2026, com aviso prévio dado aos desenvolvedores em 5 de junho de 2026

Dois meses de janela pra migrar

Se a sua aplicação tem o ID do modelo cravado no código sem plano B, esse é o dia em que ela cai

Vale acompanhar as mudanças entre versões do Opus pra não descobrir isso pelo erro 404 em produção 😛

O que o topo da linha entrega na prática

Aqui eu falo do que eu vi com o olho, não do que li em release

Quando testei o Claude Fable 5, joguei nele dois desafios de peso, do jeito que eu faria num projeto de verdade

O primeiro teste foi um prompt pesado de aplicativo interativo em arquivo único: uma simulação de trânsito de uma cidade, com malha de ruas vista de cima, semáforos e carros em movimento

Veio funcionando em UMA única interação, em menos de 10 minutos

Os carros respeitavam os semáforos direitinho, o comportamento estava correto na prática

Faltou ajuste de zoom e de visualização pra dar pra ver tudo bem na tela, mas a lógica estava lá

O segundo teste foi mais parrudo: um sistema web completo, com CRUD de ideias de vídeo em kanban, dashboard com três gráficos, busca e filtro por tag, autenticação por e-mail e senha, seed de dados e tema escuro

Pedi explicitamente um plano antes de executar

E aqui vai a reclamação honesta: ele escreveu o plano e não parou pra pedir confirmação, seguiu direto pra execução por conta própria

Em cerca de 15 minutos o sistema estava entregue

Subi na máquina, ele levantou na porta 3001, login com a conta demo funcionou e o drag and drop do kanban respondeu

Quando o modelo caro se paga (e quando é desperdício):

O que eu notei é que a diferença do modelo mais caro aparece em tarefa longa e complexa, com menos idas e vindas do que eu costumo ter no Opus

E é exatamente aí que a conta fecha: se o modelo caro resolve de primeira o que o barato resolveria em cinco rodadas, o caro saiu mais barato

Agora, se a sua rota é classificar um texto de duas linhas, mandar isso pro topo de linha é queimar dinheiro sem ganho nenhum

São impressões de primeira viagem, ainda quero usar mais pra saber do que ele é capaz de verdade

No vídeo acima eu mostro os dois testes rodando na tela: a simulação de trânsito nascendo em uma interação e o sistema web sendo levantado e clicado ao vivo

Veredito: o modelo padrão que faz sentido para a maioria das aplicações

Se eu tivesse que resumir a decisão em quatro linhas, seria assim:

• Claude Sonnet 5 como padrão de partida da aplicação em produção: 1M de contexto, US$ 2 de entrada e US$ 10 de saída, foco declarado em rodar agentes mais barato
• Claude Haiku 4.5 nas rotas de alto volume e latência baixa, a US$ 1 de entrada e US$ 5 de saída, com a bênção da própria documentação de começar por ele e escalar se precisar
• Claude Opus 5 acionado por rota, só nas tarefas difíceis: raciocínio profundo, agente de longo horizonte, refatoração grande
• Claude Fable 5 reservado pro que realmente exige o teto, porque US$ 10 e US$ 50 por milhão não é preço de rota padrão

E o Mythos 5 fica fora do jogo pra gente, por ser limitado a clientes aprovados no Project Glasswing

Não tem modelo certo, tem modelo certo PRA AQUELA rota

E antes de subir de família, mexe no effort: é mais barato e mais rápido de testar do que trocar o modelo inteiro

Conclusão

A escolha entre os modelos Claude API para de ser achismo no dia em que você separa as rotas da sua aplicação por dificuldade

Próximo passo prático, na ordem:

1. Liste as rotas da aplicação e classifique cada uma em fácil, média e difícil
2. Coloque o Haiku 4.5 nas fáceis, o Sonnet 5 como padrão e o Opus 5 só nas difíceis
3. Meça o custo real por requisição na sua carga, lembrando que o tokenizador a partir do Opus 4.7 pode gerar até 35% mais tokens pro mesmo texto
4. Ligue cache de prompt onde tem prefixo fixo (token em cache a 10% do preço de entrada) e Batch API onde o trabalho pode ser assíncrono (50% de desconto)
5. Ajuste o effort antes de promover qualquer rota pra um modelo mais caro
6. Revise essa escolha a cada lançamento da Anthropic, porque preço e linha de modelo mudam mais rápido que a sua env

E olha, esse último passo não é frescura: em poucos meses saiu Fable 5, saiu Sonnet 5, saiu Opus 5 e o Opus 4.1 foi aposentado

Quem cravou modelo no código e foi dormir, acordou com surpresa 😀

Até o próximo post!