Claude Sonnet 5.5: mesmo preço, menos tokens e 5 mudanças que quebram a compatibilidade

O que o Claude Sonnet 5.5 realmente é

O Claude Sonnet 5.5 é o modelo de nível intermediário da Anthropic e o segundo lançamento da família Claude 5.5, seis dias depois do Opus 5.5. A Anthropic o apresenta como "a faster, lower-cost complement" ao Opus: o Opus fica para o trabalho complexo que exige julgamento cuidadoso, e o Sonnet assume as tarefas do dia a dia bem delimitadas. Também há um Haiku 5.5 prometido "in the coming weeks".

Estas são as especificações, conforme a página de visão geral do modelo:

• O ID do modelo é claude-sonnet-5-5 na Claude API, Google Cloud, Microsoft Foundry e Claude Platform on AWS, e anthropic.claude-sonnet-5-5 no Amazon Bedrock.
• O contexto é de 1M de tokens de entrada e 128K de saída, ou 300K de saída na Batch API com um cabeçalho beta.
• A data de corte de conhecimento confiável é junho de 2026, a mesma do Opus 5.5 e do Fable 5.1.
• O thinking é adaptativo, e o esforço padrão é high na API, mas Medium nos apps do Claude e no Claude Code.
• A aposentadoria é "not sooner than September 28, 2027", o que dá pelo menos um ano antes de precisar migrar de novo.

O tokenizador é o mesmo do Claude Sonnet 5, segundo a página de novidades, o que significa que o mesmo texto gera a mesma contagem de tokens. Esse detalhe importa mais do que parece: toda a economia que a Anthropic alega vem de o modelo escrever menos, e não de uma forma mais amigável de contar.

A história real: mesmo preço, conta menor

No preço de tabela, nada mudou. O Sonnet 5.5 custa exatamente o que o Sonnet 5 custa: US$ 2 de entrada, US$ 10 de saída, US$ 0,20 por leituras de cache. O que mudou é quantos tokens ele gasta para terminar um trabalho.

Os números do acesso antecipado no post de lançamento são específicos de um jeito que não se costuma ver:

• A Balyasny Asset Management rodou 2.441 tarefas financeiras e viu o Sonnet 5.5 usar cerca de 121k tokens por resposta onde o Sonnet 5 usava 497k, com pontuação maior.
• O Slack viu resultados melhores em "almost all" as suas avaliações offline do Slackbot "with about 14% fewer output tokens", e sem mudar nenhum prompt.
• A Base44 terminava builds de apps em 3,6 iterações em média, onde o Opus 5 precisava de 7,7.
• A Lovable mediu "a third fewer tool calls and roughly half the shell runs to finish a task".

A comparação lado a lado da própria Anthropic mostra o mesmo, só que de forma visual. Quando os dois foram solicitados a construir um bando de 400 estorninhos em um único arquivo HTML, o Sonnet 5 ainda estava escrevendo código aos 4.520 tokens:

O Sonnet 5.5 já tinha terminado aos 4.158 tokens, e nesse ponto o bando dele já estava voando havia 12,5 segundos:

A diferença entre os clientes é onde está a leitura honesta. A queda de 4x em tokens da Balyasny e o corte de 14% do Slack são ambos reais, o que mostra que a economia depende muito de quão inchadas eram suas execuções com o Sonnet 5 desde o início. A manchete da Anthropic diz "up to 30% less per task", e o "up to" faz muito trabalho nessa frase. O Sonnet 5 tinha o hábito conhecido de se alongar: nos testes da Artificial Analysis ele levou 183 turnos por tarefa em esforço máximo, o pior do gráfico. Se a sua carga de trabalho caía aí, você pode esperar o número grande, e se seus prompts já mantinham as respostas curtas, espere algo mais próximo do Slack.

Quão perto ele chega do Opus 5.5

Para quem paga preço de Opus, esta é a parte em que o lançamento fica interessante. Na tabela de benchmarks do lançamento da Anthropic, o Sonnet 5.5 fecha a maior parte da distância para um modelo que custa o dobro por token.

Algumas coisas chamam a atenção. Primeiro, o salto no Terminal-Bench de 10,3% para 70,6% é enorme, e nele o Sonnet 5.5 na verdade supera o Opus 5.5. No GDPval-AA, um teste de trabalho real em 44 ocupações, ele fica dois pontos Elo atrás do Opus 5.5 e cerca de 400 à frente do Sonnet 5. Contra o GPT-6 Sol, o rival que a Anthropic escolheu graficar, o Sonnet 5.5 no seu melhor nível de esforço lidera em todas as linhas em que o modelo da OpenAI tem pontuação, e em esforço High iguala o melhor resultado do GPT-6 Sol no FrontierCode por cerca de um quinto do custo por tarefa.

Aprecio que a Anthropic seja franca sobre o limite. O post de lançamento diz que "in our own testing, and in that of external testers, Opus 5.5 remains clearly stronger at complex, open-ended work requiring sustained judgment". Benchmarks tendem a premiar tarefas com uma resposta certa clara. Decisões abertas, como decidir se um cliente enterprise irritado precisa de reembolso, de um pedido de desculpas ou talvez de uma escalada, são exatamente onde o gasto extra com Opus ainda se paga. A comparação Opus 5.5 vs GPT-6 Sol aprofunda esse nível de topo.

Mais uma nota que vale a leitura: as pontuações do FrontierCode caem em esforço Max (46.2%) frente a Xhigh (52.1%). A explicação da Anthropic é que, em Max, o Sonnet 5.5 dividia com mais frequência a revisão de código entre subagentes, o que causava timeouts ou edições além do escopo da tarefa. Pensar mais nem sempre é melhor, um padrão que o guia de esforço do Opus 5 também viu.

O que o Sonnet 5.5 significa para times de suporte

Se eu tivesse de pôr uma única citação do post de lançamento na frente de qualquer líder de suporte, seria esta. O Director of AI da Zendesk testou o modelo em tickets reais:

"We fed Claude Sonnet 5.5 hundreds of real support use cases across replies and escalation requests. It made fewer wrong decisions and resolved tickets faster than the Claude models we use in production today. Tickets were processed 20% faster, getting our customers the help they need without the wait."

Abhinay Kathuria, Director of AI na Zendesk, no anúncio da Anthropic

"Fewer wrong decisions" é a parte que importa aqui. Velocidade é bom, mas numa fila de suporte uma resposta rápida e errada custa mais que uma lenta e certa: cria um segundo ticket e um retorno irritado, e às vezes um reembolso por cima. O Zendesk AI já roda modelos Claude em produção, então quando afirma decisões de escalada melhores que a sua configuração atual, isso pesa de verdade. A Atlassian fez um comentário relacionado sobre escala, dizendo que times vão rodar seus agentes Rovo "up to 30% faster than they could with Sonnet 5", e o Slack AI já o está testando para o Slackbot.

Olhando pelo lado da fila, é assim que eu mapearia a linha Claude para as tarefas de suporte:

O Sonnet 5.5 é o padrão natural para a maior parte de uma fila: dúvidas sobre pedidos, respostas de como fazer, consultas de política e primeiros rascunhos para um agente aprovar. O Haiku continua sendo a opção barata para triagem de tickets e etiquetagem. O Opus 5.5 é para onde eu mandaria os tickets que precisam de julgamento, que são os que seus agentes seniores assumiriam de qualquer forma. Onde o ganho de velocidade de mais de 30% mais importa é no chat ao vivo, porque ali há um cliente olhando o indicador de digitação.

A ressalva honesta: um modelo melhor não conserta uma resposta que falta. Já vi um bot de suporte dizer com toda a confiança a um cliente que um produto era compatível porque a central de ajuda dizia "we support all models", e vi outro inventar respostas quando a recuperação voltava vazia. Nenhum dos dois era um problema de qualidade do modelo. Ambos eram problemas de fundamentação, e um modelo mais esperto pode até fazer uma resposta errada e confiante soar ainda mais convincente. É por isso que a eesel simula cada implantação em tickets históricos antes de uma IA responder a qualquer pessoa, seja qual for o modelo por baixo.

Antes de migrar: cinco coisas que agora retornam erros

A maior parte da cobertura do lançamento vai pular esta seção, e é a que vai comer sua tarde. Trocar claude-sonnet-5 por claude-sonnet-5-5 é uma linha. Por trás, a página de novidades lista cinco mudanças que quebram a compatibilidade, e há mais uma regra que pertence à mesma lista de verificação.

1. thinking: disabled retorna um 400. Envie thinking: {"type": "between_tools"} no lugar, que desliga o thinking inicial. Só funciona com esforço high ou abaixo; em xhigh ou max também dá erro.
2. O uso forçado de ferramentas acabou. tool_choice definido como any ou uma tool nomeada retorna erro. A correção é auto mais uso estrito de ferramentas.
3. Blocos de thinking estão atrelados ao modelo e à conta. Se você edita mensagens anteriores, o prompt do sistema ou as ferramentas e depois reproduz um bloco de thinking do Sonnet 5.5, contas mais novas recebem um 400. Então mantenha as conversas somente com acréscimos.
4. A antiga ferramenta computer_20251124 é rejeitada na Claude API e no Google Cloud. O Bedrock ainda a aceita.
5. Alguns pareamentos com advisor são rejeitados. Opus 4.8, Opus 4.7 e Sonnet 5 não podem mais assessorar um executor Sonnet 5.5.

Sobre essa regra extra, a documentação observa que definir temperature, top_p ou top_k com um valor fora do padrão retorna um 400 neste modelo.

A armadilha do suporte é a número dois. Muitos bots de helpdesk forçam uma chamada de ferramenta para garantir saída estruturada: "always call classify_ticket", "always call draft_reply". No Sonnet 5.5, esse pedido simplesmente falha. Se você construiu sua própria integração sobre a API da Anthropic, procure tool_choice com grep primeiro, antes de mexer no ID do modelo.

Há também uma mudança mais discreta, que não gera erro mas ainda vai confundir usuários. O texto que o modelo escreve entre chamadas de ferramenta agora volta dentro de blocos thinking, e no padrão display: "omitted" esse texto vem vazio. Se o seu widget de chat exibe "Checking your order status..." enquanto o agente trabalha, ele ficará mudo até você definir um valor de display. A Anthropic também recalibrou os níveis de esforço, então refaça seus testes de esforço em vez de levar as configurações do Sonnet 5. O guia de transferência de agentes de IA vale a leitura se uma troca de modelo mudar quando o seu bot escala.

Por último, a segurança. O Sonnet 5.5 é o primeiro Sonnet a ser lançado com salvaguardas cibernéticas, porque suas capacidades cibernéticas são comparáveis às do Opus 5. Solicitações de cibersegurança de maior risco "visibly fall back to Sonnet 5", e uma solicitação recusada retorna HTTP 200 com stop_reason: "refusal". Para um bot de suporte isso raramente vai disparar. Mas se você atende clientes de segurança ou de TI, vale tratar o caso de recusa em vez de mostrar uma resposta em branco.

Preço e acesso do Claude Sonnet 5.5

Esta é a tabela completa da documentação de preços da Anthropic, por milhão de tokens:

Algumas notas sobre essa tabela. O thinking é cobrado como tokens de saída, então uma execução com esforço high paga US$ 10 por milhão também pelo raciocínio. E o prompt mínimo passível de cache agora é de 512 tokens, segundo a visão geral do modelo, o que facilita colocar em cache um prompt de sistema de suporte estável.

Para pôr essas tarifas em termos de suporte, aqui vai uma conta ilustrativa que usa apenas preços publicados. Digamos que uma resposta de ticket envia 6.000 tokens de entrada (o ticket mais os artigos de ajuda recuperados) e recebe 800 tokens de saída. São US$ 0,012 de entrada e US$ 0,008 de saída, ou cerca de 2 centavos por ticket. Se 5.000 desses tokens de entrada forem um prompt de sistema em cache, o lado da entrada cai para cerca de US$ 0,003 e a resposta inteira fica perto de 1,1 centavo. Com 10.000 tickets por mês, isso dá aproximadamente US$ 200 sem cache contra US$ 110 com cache, antes dos tokens de thinking. Seus números variam conforme o esforço e o tamanho da recuperação, mas mostra por que a linha do modelo na fatura raramente é o grande custo de um agente de suporte com IA.

Aqui é onde você pode usá-lo:

• A Claude API, como claude-sonnet-5-5, com prompt caching e a Batch API. Retenção zero de dados está disponível.
• Apps do Claude. A Anthropic diz "anyone can chat with Claude using Sonnet 5.5 on Claude.ai" na web, iOS e Android. Os planos pagos são tratados no guia de preços do Claude Pro.
• Claude Code, onde o esforço padrão é Medium. O guia de preços do Claude Code cobre a conta de assinatura versus API, e fixar um modelo leva uma configuração.
• As nuvens: Amazon Bedrock, Google Cloud, Microsoft Foundry e Claude Platform on AWS, todas no primeiro dia.

Se o que você está pesando são provedores em vez de níveis, a comparação de três APIs e o detalhamento de preços do GPT-6 Sol são as verificações mais rápidas.

O que os desenvolvedores estão dizendo

O tópico do lançamento no Hacker News passou de 550 comentários em um dia, e a reação se divide de forma bem clara. As pessoas gostam da velocidade e respeitam os benchmarks, enquanto as críticas são principalmente sobre onde ele se encaixa ao lado do Opus 5.5.

"Playing around with it for a few minutes, Sonnet 5.5 feels very fast, much quicker than Opus 5.5. Can't tell yet if it's a lot worse but the speed is definitely welcome."

croemer, Hacker News

A crítica mais afiada tem a ver com os níveis altos de esforço. Simon Willison mediu seu teste habitual de SVG em cada nível de esforço e encontrou low a 1,6 centavo, medium a 1,8 centavo e high a 2,3 centavos, mas o max gastou todo o seu orçamento de thinking:

"Sonnet 5.5 has the same problem as Opus 5.5: on "max" thinking effort it burned through 128,000 thinking tokens (taking 15 minutes to do that) and ran out before it had produced the final SVG."

simonw, Hacker News

Um usuário do Reddit tirou o mesmo padrão da Artificial Analysis, relatando que "sonnet 5.5 max has a cost per task of $7.60 while opus 5.5 max has $5.98", com o Sonnet usando 193k tokens por tarefa contra 119k do Opus (u/ex-procrastinator, Reddit). Outro comentarista resumiu o que os gráficos sugerem:

"Per the charts, there is largely no point to using Sonnet 5.5 at high+ as opus low generally will give similar performance at similar or lower cost."

usaar333, Hacker News

A Anthropic diz algo muito parecido no próprio post de lançamento: o Sonnet 5.5 "complements Opus 5.5 best when running at lower effort settings", e "at higher settings, it can perform comparably at a similar cost". Então a conclusão prática, e o que eu diria a qualquer time que esteja migrando, é esta: rode o Sonnet 5.5 em esforço Low ou Medium, onde a economia realmente está. A API usa high por padrão, então a versão barata deste modelo é uma que você precisa pedir. Respostas de suporte são exatamente o tipo de trabalho bem delimitado que o Medium resolve bem.

Há uma regressão que vale conhecer. Um desenvolvedor que roda um benchmark adversarial achou que o Sonnet 5.5 pontuou menos que o Sonnet 5 "mainly because it is more reluctant to keep going to get an answer, instead it returns to ask the user questions" (dom96, Hacker News). Para um agente de programação isso é chato, mas para um bot de suporte, parar para perguntar em vez de chutar costuma ser exatamente o que você quer.

Um modelo mais rápido ainda precisa de um colega ao redor

Todo lançamento de modelo provoca a mesma conversa com clientes técnicos: isso agora é barato e bom o bastante, então por que não construir nosso próprio bot de suporte na API bruta? É uma pergunta justa, e o Sonnet 5.5 torna a metade do modelo mais fácil do que nunca.

O que a tabela de preços deixa de fora é tudo em volta do modelo. O Sonnet 5.5 é um motor excelente. Não é um agente de suporte até que alguém construa a recuperação sobre a sua central de ajuda e tickets anteriores, além das regras de escalada e do tratamento de recusas, do ajuste de esforço e agora também do trabalho de migração para cinco mudanças que quebram a compatibilidade. O modelo é a infraestrutura, e o funcionário é o que você constrói em cima.

A eesel vende essa parte já pronta. O colega de helpdesk com IA entra na sua fila existente no Zendesk, Freshdesk, Gorgias e mais. Ele aprende com seus tickets anteriores e sua central de ajuda, depois redige ou envia respostas, com um modelo de fronteira por baixo. Quando a Anthropic lança um modelo como este, a troca e as mudanças que quebram a compatibilidade são problema da eesel, não seu.

Se você quer controle programático, a eesel tem uma CLI que opera o mesmo colega e workspace que o painel. Você pode usá-la num terminal ou automatizá-la com scripts, e também pode deixar um agente de programação como o Claude Code executá-la, de modo que você obtém o fluxo agêntico que as pessoas constroem sobre modelos brutos sem ser dono da pilha de fundamentação e novas tentativas. Meus textos sobre a CLI de agentes de IA e os servidores MCP mostram como isso se encaixa.

O preço funciona com créditos mensais fixos: um ticket ou chat atendido é um crédito, o plano gratuito inclui 100 créditos sem cartão, e os planos pagos começam em US$ 299 por 500. Você pode simular o colega nos seus próprios tickets históricos antes que ele responda a um único cliente. Teste a eesel grátis na sua fila do Zendesk e veja o ganho de velocidade da classe Sonnet em tickets cujas respostas você já conhece.

O Claude Sonnet 5.5 vale a pena?

Se você usa o Sonnet 5 hoje, sim, e é uma das atualizações mais fáceis que a Anthropic já lançou. Você paga a mesma tarifa por um modelo que pontua bem mais alto e termina com menos tokens, e ainda roda mais rápido. O único custo real é o trabalho de migração, e é uma lista conhecida de cinco itens, não um mistério.

Se você usa o Opus 5.5 para o trabalho do dia a dia, teste o Sonnet 5.5 no seu próprio tráfego em esforço Medium antes de renovar esse hábito. Para tarefas bem delimitadas, a diferença de benchmark é de alguns pontos e a diferença de preço por token é de 2x. Depois de passar do esforço high, essa vantagem desaparece, então se uma tarefa precisa de raciocínio máximo, mande-a para o Opus. Reserve o Opus para as decisões abertas de julgamento em que a própria Anthropic diz que ele ainda é claramente mais forte. Um comentarista do Hacker News descreveu um padrão, "80% Sonnet 5.5, Opus 5.5 to finish the last 20%", e é também uma forma sensata de dividir uma fila. Para o restante do cenário, minha resenha do Sonnet 5 e o resumo de alternativas ao Opus 5.5 são as próximas leituras.