Claude 5 chegou: o que muda pra você dev

Introdução

Esse post foi escrito originalmente sobre a família Claude 4 (Opus 4.7, Sonnet 4.6, Haiku 4.5). Em agosto de 2026 o cenário mudou: a Anthropic lançou a família Claude 5, com Fable 5, Opus 5 e Sonnet 5 substituindo os modelos anteriores de maior porte. O Haiku 4.5 segue sendo o modelo de entrada, sem sucessor lançado até agora. Atualizei o post inteiro pra refletir o que realmente mudou.

Visão geral da família Claude 5

Existe ainda o Claude Mythos 5, com as mesmas capacidades e preço do Fable 5, mas disponível só pra quem participa do Project Glasswing da Anthropic. Pra praticamente todo mundo, o que importa são os quatro modelos da tabela acima.

Claude Haiku 4.5: sem mudanças, ainda o modelo de volume

O Haiku continua igual ao que era antes: rápido, barato, 200k de contexto, sem thinking estendido nativo. Segue sendo a escolha certa pra classificação de texto, triagem de tickets, geração simples de conteúdo e qualquer pipeline de alto volume onde custo pesa mais que profundidade de raciocínio.

Claude Sonnet 5: o novo padrão pra maioria dos casos

O Sonnet 5 substitui o Sonnet 4.6 como modelo do dia a dia, e a diferença mais sentida é em coding e tarefas agênticas, onde ele chega perto da qualidade que antes só o Opus entregava.

O que muda na prática:

• Thinking adaptativo ligado por padrão. Diferente do Sonnet 4.6, uma chamada sem configurar thinking já roda com raciocínio adaptativo. Se o seu código dependia do modelo responder sem pensar por padrão, isso muda o comportamento, e o max_tokens precisa dar espaço pro thinking, senão a resposta pode truncar no meio.
• Tokenizador novo. O mesmo texto gera cerca de 30% mais tokens que no Sonnet 4.6. O preço por token é o mesmo, mas o custo efetivo de uma chamada equivalente muda. Vale rodar count_tokens nos seus prompts reais antes de migrar workloads grandes.
• Todos os níveis de esforço, incluindo xhigh. Antes esse nível era exclusivo do Opus. Agora o Sonnet também tem a faixa completa (low, medium, high, xhigh, max), o que dá mais controle sobre o equilíbrio entre custo e profundidade de raciocínio.
• Visão de alta resolução. É o primeiro Sonnet com suporte a imagens de até 2576px no lado maior (antes o limite era 1568px). Útil pra quem processa screenshot, gráfico ou documento escaneado.

O preço promocional de $2/$10 por MTok vale até 31 de agosto de 2026. Depois disso volta pro valor cheio de $3/$15.

Claude Opus 5: pra coding pesado e trabalho agêntico longo

O Opus 5 é o sucessor direto do Opus 4.8, e o ponto forte continua sendo raciocínio profundo, trabalho agêntico de longa duração e coding complexo.

Principais diferenças na prática:

• Thinking ligado por padrão, com um limite novo. Assim como o Sonnet 5, uma chamada sem thinking configurado já roda em modo adaptativo. A pegadinha: desativar o thinking ({"type": "disabled"}) só funciona em esforço high ou abaixo. Combinar thinking desativado com xhigh ou max retorna erro 400.
• Faixa de rate limit separada. O Opus 5 não compartilha o pool combinado dos modelos Opus 4.x. Se você está deslocando tráfego de um Opus anterior, confere o limite do seu tier especificamente pro Opus 5 antes de migrar volume.
• Salvaguardas de segurança mais rígidas. Pedidos que tocam em conteúdo sensível (majoritariamente cyber e outras áreas de risco elevado) podem retornar stop_reason: "refusal" em vez de um erro. É uma resposta HTTP 200 normal, então o código precisa checar stop_reason antes de ler content, ou vai quebrar tentando ler um array vazio.
• Cache mais barato de configurar. O mínimo de tokens pra um prompt ser cacheável caiu de 1024 pra 512, então prompts que antes eram curtos demais pra cachear agora entram.
• Fast mode. Em preview, speed: "fast" roda até 2.5x mais rápido em tokens de saída por segundo, com preço premium ($10/$50 por MTok). Disponível só via API direta da Anthropic, não em Bedrock, Vertex ou Foundry.

Claude Fable 5: o modelo mais capaz, pra quando realmente precisa

O Fable 5 é o modelo mais capaz que a Anthropic lançou publicamente até agora, pensado pra raciocínio muito difícil e trabalho agêntico de longuíssima duração. Não é o upgrade padrão de quem já usa Opus, é uma escolha deliberada quando o problema justifica o custo mais alto ($10/$50 por MTok, o dobro do Opus 5).

Pontos que fazem diferença de verdade na hora de decidir se vale usar:

• Thinking sempre ligado, sem opção de desativar. Tentar mandar {"type": "disabled"} retorna erro 400 em qualquer nível de esforço.
• O raciocínio bruto nunca é retornado. Você recebe um resumo (display: "summarized") ou nada ("omitted", o padrão), nunca a cadeia de pensamento completa.
• Turnos mais longos. Uma chamada numa tarefa difícil pode rodar muitos minutos. Vale planejar timeout, streaming e alguma forma de o usuário acompanhar o progresso de forma assíncrona.
• Exige retenção de dados de 30 dias. Organizações configuradas com retenção zero (ZDR) recebem erro 400 em toda chamada pro Fable 5. Isso é fácil de confundir com um problema no payload quando na verdade é configuração de conta.

Na prática, o Fable 5 compensa em cenários bem específicos: refatoração grande e autônoma de código, pesquisa profunda de várias etapas, ou qualquer tarefa onde você entregaria o problema pra um especialista sênior e deixaria ele trabalhar sem supervisão por um bom tempo.

Como escolher o modelo certo

A lógica de sempre continua valendo, só os nomes mudaram:

• Haiku 4.5: classificação, triagem, tarefas simples em alto volume
• Sonnet 5: a maioria das tarefas em produção, coding do dia a dia, RAG, chatbots
• Opus 5: agentes autônomos, coding complexo, tarefas que precisam de raciocínio mais profundo
• Fable 5: só quando o problema genuinamente exige o nível máximo e o custo se justifica

Um padrão que continua funcionando bem: Haiku pra filtrar ou pré-processar, Sonnet pra o grosso do trabalho, Opus quando precisa de mais capacidade, e Fable só nos casos extremos.

Migrando código que ainda usa os IDs antigos

Se seu código ainda referencia os modelos da família anterior, a troca direta é:

Duas coisas quebram se você só trocar a string do modelo sem revisar o resto do código:

1. budget_tokens não existe mais. Se seu código ainda configura thinking: {"type": "enabled", "budget_tokens": N}, isso retorna erro 400 no Opus 5 e no Sonnet 5. Troca pra thinking: {"type": "adaptive"} e controla a profundidade com effort dentro de output_config.
2. Parâmetros de sampling somem. temperature, top_p e top_k não são aceitos nesses modelos. Se seu código passa algum desses, remove e ajusta o comportamento por prompt em vez de sampling.

Chamada básica em Python

import anthropic
 
client = anthropic.Anthropic()
 
message = client.messages.create(
    model="claude-opus-5",  # ou claude-sonnet-5 / claude-haiku-4-5 / claude-fable-5
    max_tokens=4096,
    messages=[
        {"role": "user", "content": "Explica a diferença entre BFS e DFS em grafos."}
    ]
)
 
print(message.content)

Repara que não precisa configurar thinking explicitamente no Opus 5 ou no Sonnet 5, eles já rodam em modo adaptativo por padrão. Se quiser ver o resumo do raciocínio, adiciona thinking: {"type": "adaptive", "display": "summarized"}.

Vale migrar agora?

Se você está numa versão anterior da família Claude 4, sim, vale a pena migrar. O Sonnet 5 sozinho já justifica a troca pra quem usa o modelo em produção, com ganho de qualidade em coding e trabalho agêntico sem trocar de tier de preço. Pra quem depende de Opus pros casos mais difíceis, o Opus 5 mantém o mesmo preço do Opus 4.8 e entrega mais capacidade.

O ponto de atenção real é o tokenizador novo do Sonnet 5 e do Opus 5: se você tem max_tokens calibrado bem justo, vale revisar antes de migrar em escala, porque a mesma resposta agora pode consumir mais tokens.

Conclusão

A família Claude 5 mantém a estrutura que já funcionava (um modelo de volume, um de uso geral, um ou dois pra quando o problema é difícil de verdade), só que com um salto real de qualidade no Sonnet e no Opus, principalmente em coding e trabalho agêntico. Se seu projeto ainda está preso na família Claude 4, esse é um bom momento pra revisar model IDs, testar o novo comportamento de thinking adaptativo e ver onde faz sentido trocar.