A Anthropic lançou o Claude Sonnet 5 em 30 de junho de 2026, e ele é um substituto direto para o Sonnet 4.6. Você muda o ID do modelo e, na maioria dos casos, seu código continua funcionando. Mas "na maioria dos casos" está fazendo algum trabalho nessa frase. O Sonnet 5 vem com um novo tokenizador, pensamento adaptativo ativado por padrão e alguns parâmetros de requisição que agora retornam erros em vez de serem executados. Este artigo detalha exatamente o que mudou, quanto custa e se a atualização vale a pena para sua carga de trabalho.
A versão resumida: mesmo preço por token, melhores pontuações em tarefas de codificação e agenticas, três pequenas mudanças de código e uma pegadinha não óbvia do tokenizador que afeta suas contagens e orçamentos de tokens. Leia os detalhes antes de ativar a mudança em produção.

A atualização em um piscar de olhos
O Sonnet 5 mantém o mesmo preço por token que o Sonnet 4.6, então, em uma base por token, nada em sua conta muda. Ele melhora nos benchmarks que importam para o uso de ferramentas e codificação. E ele muda o suficiente sobre o comportamento padrão para que uma troca cega possa surpreendê-lo.
Aqui está a comparação lado a lado.
| Atributo | Sonnet 4.6 (claude-sonnet-4-6) |
Sonnet 5 (claude-sonnet-5) |
|---|---|---|
| Lançado | Antecessor | 30 de junho de 2026 |
| Janela de contexto | Até 1M tokens | 1M tokens (padrão e máximo) |
| Saída máxima | 128K tokens | 128K tokens |
| Pensamento padrão | Desativado quando não há campo thinking |
Pensamento adaptativo ativado por padrão |
Pensamento estendido (budget_tokens) |
Obsoleto | Retorna erro 400 |
Parâmetros de amostragem (temperature, top_p, top_k) |
Aceito | Valores não padrão retornam 400 |
| Tokenizador | Tokenizador mais antigo | Novo tokenizador (~30% mais tokens por texto) |
| Preço padrão | $3 / $15 por M in/out | $3 / $15 por M in/out |
| Preço de introdução | n/a | $2 / $10 por M até 31 de agosto de 2026 |
Tudo o mais que funciona no Sonnet 4.6 funciona no Sonnet 5 sem outras alterações de código: saídas estruturadas, visão, cache de prompt, uso de ferramentas e lote são todos mantidos. O único recurso da plataforma que você perde é o Priority Tier, que não está disponível no Sonnet 5.
O que melhorou: benchmarks
O Sonnet 5 é posicionado como o modelo Sonnet mais agentico até agora, e os números relatados confirmam isso em trabalhos intensivos em ferramentas. Estes são os benchmarks de lançamento da Anthropic, corroborados em artigos de lançamento. Trate-os como números relatados, não como testes independentes.
| Benchmark | Sonnet 4.6 | Sonnet 5 |
|---|---|---|
| SWE-bench Pro (codificação agentica) | 58.1% | 63.2% |
| OSWorld-Verified (uso de computador) | 78.5% | 81.2% |
Isso é um salto real nas tarefas onde o Sonnet é mais usado: escrever e corrigir código com ferramentas em jogo, e operar um computador ou terminal. A Anthropic também relata que o Sonnet 5 se aproxima do Opus 4.8 uma vez que as ferramentas são envolvidas, com alguns pontos de diferença em tarefas agenticas, enquanto custa muito menos. Se seu aplicativo tem formato de agente, esta é a atualização que você estava esperando. Para o confronto direto contra o modelo premium, veja Sonnet 5 vs Opus 4.8.

O Sonnet 5 também é mais seguro que o 4.6, de acordo com as medições da Anthropic: uma taxa menor de comportamentos indesejáveis, menor alucinação e bajulação, e melhor resistência à injeção de prompt. É o primeiro modelo da categoria Sonnet com salvaguardas de cibersegurança em tempo real. Um comportamento a ser observado: uma recusa de uma solicitação proibida retorna como um HTTP 200 bem-sucedido com stop_reason: "refusal", não como um erro. Lide com esse motivo de parada na sua análise de resposta.
As três mudanças reais de código
A maioria das migrações afeta apenas estas três coisas. Revise-as, ajuste onde for necessário, e o resto da sua integração permanecerá inalterado.
1. Pensamento adaptativo agora está ativado por padrão
No Sonnet 4.6, a ausência do campo thinking significava que não havia pensamento. No Sonnet 5, uma requisição sem o campo thinking é executada com o pensamento adaptativo ativado. O modelo decide o quanto pensar com base na tarefa, e você controla a profundidade com o parâmetro de esforço (low, medium, high ou xhigh).
Isso importa porque max_tokens é um limite rígido para a saída total, e a saída total agora inclui tokens de pensamento mais o texto da sua resposta. Um max_tokens que foi dimensionado apenas para o texto da resposta no 4.6 pode agora truncar sua resposta no Sonnet 5, porque o pensamento consome parte do mesmo orçamento.
Se uma carga de trabalho anteriormente funcionava sem pensamento e você deseja que continue assim, desative o pensamento explicitamente:
from anthropic import Anthropic
client = Anthropic()
response = client.messages.create(
model="claude-sonnet-5",
max_tokens=1024,
thinking={"type": "disabled"},
messages=[
{"role": "user", "content": "Return the OpenAPI 3.1 path object for GET /invoices/{id}."}
],
)
print(response.content[0].text)
Para usar o pensamento adaptativo com uma profundidade controlada, defina o esforço em vez de desativá-lo:
response = client.messages.create(
model="claude-sonnet-5",
max_tokens=8192,
thinking={"type": "adaptive"},
effort="medium",
messages=[
{"role": "user", "content": "Draft integration tests for the POST /orders endpoint."}
],
)
Observe o formato: thinking={"type": "adaptive"}, não um orçamento de tokens. Isso nos leva à próxima mudança.
2. O pensamento estendido manual foi removido
O antigo padrão thinking: {type: "enabled", budget_tokens: N} retorna um erro 400 no Sonnet 5. Já estava obsoleto no 4.6, então a maioria do código atual já migrou, mas verifique se há. Substitua qualquer orçamento manual por pensamento adaptativo e o parâmetro de esforço. Se você estava definindo um grande budget_tokens para tarefas difíceis, effort="high" ou effort="xhigh" é a alavanca de substituição.
3. Parâmetros de amostragem agora retornam 400
Definir temperature, top_p ou top_k para um valor não padrão retorna um erro 400 no Sonnet 5. Omiti-los ou deixá-los em seus valores padrão está ok. Essa restrição já existia no Opus 4.7 e posterior; é nova para a classe Sonnet.
Se você dependia de temperature=0 para uma saída com sensação determinística, remova-o e direcione o comportamento através do seu prompt do sistema. Seja explícito sobre formato, tom e restrições nas instruções, em vez de por meio da amostragem. Uma rápida busca por esses parâmetros em sua base de código economiza uma rodada de 400s em produção.
Uma coisa que não mudou em relação ao 4.6: o preenchimento de mensagens do assistente ainda não é suportado e retorna um 400. Se você estava forçando o início de uma resposta preenchendo a vez do assistente, use saídas estruturadas ou output_config.format ou instruções de prompt do sistema.
A pegadinha do tokenizador que ninguém te avisa
O Sonnet 5 usa um novo tokenizador. O mesmo texto de entrada produz aproximadamente 30% mais tokens do que produzia no Sonnet 4.6, cerca de 1.3x. Esta não é uma mudança na API. As formas de requisição, resposta e streaming são idênticas, e você não precisa escrever nenhum código novo para isso. Mas isso muda tudo o que você mede ou orça em tokens.
Aqui está o que você precisa reavaliar:
- Contagens de tokens e campos
usage. O mesmo prompt reporta mais tokens no Sonnet 5. Não reutilize suas contagens do 4.6. Reexecute a contagem de tokens em relação aclaude-sonnet-5para qualquer prompt que você rastreie. - Sua janela de contexto de 1M agora comporta menos texto. Cada token agora abrange menos texto em média, então a mesma janela acomoda menos caracteres do seu conteúdo. Se você estava compactando o contexto perto do limite, verifique se ele ainda cabe.
- Orçamentos
max_tokensdimensionados perto da saída esperada podem truncar. Um orçamento que comportava confortavelmente sua resposta típica no 4.6 pode agora cortá-la no Sonnet 5. Combinado com o pensamento adaptativo compartilhando esse orçamento, esta é a causa mais comum de respostas inesperadamente curtas após uma atualização. - O custo por requisição de texto equivalente pode ser maior. A taxa por token não foi alterada, mas mais tokens por requisição significa que você paga mais pelo mesmo texto.
Este último ponto merece um exemplo prático. Digamos que um prompt mais resposta era de 10.000 tokens no Sonnet 4.6. O mesmo texto é de aproximadamente 13.000 tokens no Sonnet 5. A uma taxa por token idêntica, essa requisição custa cerca de 30% mais, embora a tabela de preços pareça inalterada. Modele suas cargas de trabalho reais com a contagem de tokens antes de presumir uma paridade de custo plana. A análise de preços do Sonnet 5 aprofunda-se nisso com os cálculos de preço de introdução versus preço padrão.
Você pode medir a mudança você mesmo com o endpoint de contagem de tokens:
curl https://api.anthropic.com/v1/messages/count_tokens \
--header "x-api-key: $ANTHROPIC_API_KEY" \
--header "anthropic-version: 2023-06-01" \
--header "content-type: application/json" \
--data '{
"model": "claude-sonnet-5",
"messages": [
{"role": "user", "content": "Summarize the changelog for our billing API v3 release."}
]
}'
Execute a mesma chamada com claude-sonnet-4-6 e compare as contagens. Essa diferença é o impacto real no seu orçamento.
O que a atualização custa
Por token, o Sonnet 5 custa o mesmo que o Sonnet 4.6: US$3 por milhão de tokens de entrada e US$15 por milhão de tokens de saída a taxas padrão. Há uma taxa de introdução de US$2 por milhão de entrada e US$10 por milhão de saída em vigor até 31 de agosto de 2026, após a qual ele passa para o padrão de US$3 / US$15.
Assim, durante a janela de introdução, o texto equivalente é mais barato por token do que a taxa padrão do 4.6, o que compensa parcialmente o aumento de ~30% de tokens do tokenizador. Após 31 de agosto, as taxas por token correspondem novamente às do 4.6, e o efeito do tokenizador significa que uma requisição equivalente pode custar mais do que a mesma requisição custava no 4.6. Modele isso em relação ao seu tráfego real. Para taxas de lote e cache de prompt, verifique a página de preços da Anthropic em vez de assumir um desconto fixo.
Se você também está avaliando a geração anterior em termos de custo, os guias de preço do Sonnet 4.6 e custo da API Claude fornecem as bases para comparação.
Você deveria atualizar? Um veredito por usuário
A troca do ID do modelo é trivial. Se você a fará, depende do que você executa.
Atualize agora se você constrói agentes, ferramentas de codificação ou fluxos de trabalho com muitas ferramentas. Esta é a vitória mais clara. Os ganhos no SWE-bench Pro e OSWorld se encaixam exatamente onde os aplicativos agenticos vivem, e as melhorias de segurança reduzem comportamentos indesejáveis em ciclos autônomos. Faça a revisão dos três parâmetros, reavalie seus orçamentos de tokens e implante.

Atualize, mas teste cuidadosamente, se você executa cargas de trabalho de produção de alto volume. O mesmo preço por token é uma boa notícia, mas o tokenizador significa que seu gasto total de tokens e o comportamento de truncamento de max_tokens ambos mudam. Execute uma passagem de contagem de tokens e um conjunto de regressão antes de rotear o tráfego real. O preço de introdução até 31 de agosto oferece uma janela para validar a uma taxa menor.
Atualize deliberadamente se você depende de temperature, budget_tokens ou preenchimento. Estes agora retornam 400. A migração é simples, movendo o determinismo para o seu prompt do sistema e trocando orçamentos por esforço, mas não é um trabalho zero. Corrija isso antes da troca, não depois.
Mantenha se você precisa especificamente do Priority Tier. Ele não está disponível no Sonnet 5. Se o seu SLA depende dele, permaneça no 4.6 para esses caminhos até que seus requisitos mudem.
Para a maioria das equipes, a resposta é atualizar, e em breve, porque você obtém melhor desempenho agentico pelo mesmo preço principal. Trate isso como uma migração real com uma fase de testes, não uma edição de um caractere que você implementa em uma sexta-feira. Se você está comparando gerações de forma mais ampla, o guia da API Sonnet 4.6 documenta a superfície da qual você está migrando.
Detecte regressões com um conjunto de requisições salvas no Apidog
A maneira mais segura de atualizar é comparar o Sonnet 5 com o Sonnet 4.6 em seus próprios prompts, não em uma tabela de benchmarks. Esse é exatamente o tipo de teste de antes e depois para o qual uma plataforma de API é construída.
Apidog é uma ferramenta completa de desenvolvimento e teste de API. Ao chamar a API Claude, você está acessando um endpoint HTTP com cabeçalhos de autenticação, um corpo de requisição JSON e uma resposta JSON. O Apidog permite que você salve essa requisição uma vez e a execute novamente como uma coleção reutilizável, o que transforma uma migração de modelo em um teste repetível em vez de uma nova tentativa manual.

Um fluxo de trabalho de migração prático se parece com isto:
- Salve suas requisições da API Messages de produção como uma coleção Apidog, uma para cada prompt representativo.
- Armazene sua
ANTHROPIC_API_KEYcomo uma variável de ambiente para que você nunca a cole em um corpo de requisição. - Configure dois ambientes que diferem apenas pelo valor de
model:claude-sonnet-4-6eclaude-sonnet-5. - Adicione asserções sobre a forma da resposta e sobre as contagens de tokens de
usage, e então execute a coleção contra ambos os ambientes. - Compare as duas execuções. As diferenças nas contagens de tokens mostram o impacto real do tokenizador em seus prompts, e qualquer asserção que falhar é uma regressão a ser investigada antes de você implementar.
Você também pode simular o endpoint Claude no Apidog para construir e testar sua integração circundante, incluindo o caminho stop_reason: "refusal", sem gastar tokens. Se seu aplicativo tem formato de agente e chama outras ferramentas, o Apidog é onde você testa e simula essas APIs a jusante também.
Baixe o Apidog para construir o conjunto de comparação, ou abra o Apidog no navegador para começar a partir de uma requisição. Se você está migrando do Postman para isso, o guia Teste de API sem Postman cobre o fluxo equivalente.
FAQ
O Claude Sonnet 5 é um substituto direto para o Sonnet 4.6? Na maioria das vezes. Você muda o ID do modelo de claude-sonnet-4-6 para claude-sonnet-5, e então revisa três coisas: o pensamento adaptativo agora está ativado por padrão (o que afeta max_tokens), o pensamento estendido budget_tokens retorna 400, e parâmetros de amostragem não padrão retornam 400. Todo o resto é mantido. Veja o guia da API Sonnet 5 para a configuração completa da requisição.
O Sonnet 5 custa mais que o Sonnet 4.6? Por token, não. Ambos custam US$3 por milhão de tokens de entrada e US$15 por milhão de tokens de saída a taxas padrão. Mas o novo tokenizador do Sonnet 5 produz cerca de 30% mais tokens para o mesmo texto, então uma requisição equivalente pode custar mais mesmo com a mesma taxa por token. Há uma taxa introdutória de US$2 / US$10 por milhão até 31 de agosto de 2026.
Por que minha resposta está sendo cortada após a atualização? O pensamento adaptativo está ativado por padrão no Sonnet 5, e os tokens de pensamento compartilham o mesmo orçamento de max_tokens que o texto da sua resposta. Um orçamento que comportava sua resposta no 4.6 pode truncá-la agora. Aumente max_tokens, ou defina thinking={"type": "disabled"} se você não quiser o pensamento nessa chamada.
Preciso mudar meu código para o novo tokenizador? Não. As formas de requisição, resposta e streaming são idênticas, então nenhuma alteração de código é necessária. Mas você deve reavaliar tudo o que é orçado em tokens: contagens de tokens, dimensionamento de max_tokens e estimativas de custo por requisição. Não reutilize suas contagens de tokens do Sonnet 4.6.
O que aconteceu com temperature e budget_tokens? Ambos agora retornam um erro 400 no Sonnet 5 quando definidos para valores não padrão. Remova temperature, top_p e top_k não padrão e direcione o comportamento através do seu prompt do sistema. Substitua o pensamento estendido de budget_tokens pelo pensamento adaptativo mais o parâmetro de esforço. O guia de alterações da API Fable 5 e Mythos cobre o mesmo padrão na camada superior.
