Claude Sonnet 5.5 chega com foco em eficiência — e exige revisão da integração

A Anthropic lançou o Claude Sonnet 5.5 em 28 de setembro de 2026 como atualização de seu modelo intermediário para desenvolvimento, uso de ferramentas e trabalho de conhecimento. O ponto que mais importa para equipes é operacional: o preço de tabela permanece em US$ 2 por milhão de tokens de entrada e US$ 10 por milhão de tokens de saída, mas a empresa afirma que o novo modelo gera respostas mais de 30% mais rápido e pode reduzir o custo por tarefa em até 30% por precisar de menos tokens e chamadas de ferramentas.

O modelo está disponível como claude-sonnet-5-5 na Claude API, Amazon Bedrock, Google Cloud, Microsoft Foundry e Claude Platform on AWS. A troca não é apenas uma alteração de nome: aplicações que migrarem sem revisar o tratamento de blocos de resposta, pensamento adaptativo e escolha forçada de ferramentas podem receber erros HTTP 400 ou deixar de exibir atualizações entre chamadas de ferramentas.

O que a Anthropic anunciou

Claude Sonnet 5.5 é a segunda versão da família Claude 5.5 e ocupa a faixa de custo e velocidade abaixo do Claude Opus 5.5. Segundo a Anthropic, a proposta é atender tarefas cotidianas bem delimitadas — corrigir bugs, produzir documentos, planilhas e apresentações — enquanto o Opus continua sendo a opção para problemas abertos que pedem julgamento sustentado.

As especificações publicadas indicam janela de contexto de 1 milhão de tokens, saída máxima de 128 mil tokens e entrada por texto ou imagem, com saída em texto. O modelo usa pensamento adaptativo e o esforço padrão na API é high. A Anthropic informa conhecimento confiável e corte de dados de treinamento em junho de 2026; para fatos posteriores, aplicações ainda precisam fornecer contexto ou conectar ferramentas de busca.

Os números de desempenho precisam de contexto

A Anthropic relata 70,6% no Terminal-Bench 4.0, avaliação de tarefas profissionais em terminal, contra 10,3% para o Sonnet 5 e 66,4% para o Opus 5.5 no resultado citado. Em CursorBench 4.0, a empresa informa 55,5%, perto dos 57,8% do Opus 5.5. Para OSWorld 2.1, teste de uso de computador, o número divulgado é 80,1% na modalidade parcial, contra 57,0% do Sonnet 5.

Esses resultados são úteis como sinal de evolução, mas não devem ser tratados como previsão de produtividade em produção. A própria Anthropic ressalta que benchmarks medem apenas uma parte da capacidade e diz que o Opus 5.5 permanece melhor em trabalho complexo, aberto e com necessidade de julgamento. Além disso, os testes usam configurações de esforço diferentes: no FrontierCode 1.1, por exemplo, Sonnet 5.5 obteve 52,1% em Xhigh e 46,2% em Max. O segundo resultado menor ilustra um ponto importante para operadores de agentes: mais raciocínio ou mais subagentes não garante melhor desempenho quando a avaliação penaliza atrasos ou mudanças fora do escopo.

Por que custo por tarefa não é o mesmo que preço por token

A redução de até 30% anunciada não vem de um desconto na tabela. Ela depende da hipótese de que o Sonnet 5.5 complete a mesma tarefa com menos iterações, tokens de saída e chamadas de ferramenta. Há relatos de clientes selecionados pela Anthropic que apontam essa direção: a Balyasny Asset Management citou cerca de 121 mil tokens por resposta, contra 497 mil no Sonnet 5, em sua suíte privada; a Lovable relatou menos chamadas de ferramenta e de shell em seus testes. São dados de parceiros e não uma medição independente, portanto servem para definir uma hipótese de teste, não para aprovar uma migração automaticamente.

Para uma empresa brasileira que usa API, a unidade relevante é o custo por fluxo concluído: tokenização, duração de contexto, retrabalho, falhas de ferramentas, latência e cotação do dólar entram na conta. O caminho prudente é executar um conjunto de tarefas reais do negócio com orçamento e critérios de sucesso fixos, comparando Sonnet 5 e Sonnet 5.5 por taxa de conclusão, custo total, tempo até revisão humana e incidência de respostas recusadas.

Migração: cinco mudanças que podem quebrar integrações

A documentação da plataforma lista mudanças incompatíveis que merecem atenção antes de atualizar o ID do modelo.

• Pensamento passa a ser adaptativo por padrão. Uma chamada sem campo thinking não equivale mais a uma execução sem raciocínio. Tokens de pensamento contam no limite de max_tokens e na cobrança de saída.
• O modo disabled não é aceito. Para desativar o pensamento inicial, a substituição é thinking: {"type": "between_tools"}, disponível até o esforço high.
• Escolha forçada de ferramenta falha. Os tipos any e tool retornam erro. A recomendação é tool_choice: {"type": "auto"} e, quando suportado, ferramentas estritas com validação de esquema.
• Blocos devem ser lidos pelo tipo. A resposta pode começar por blocos thinking; código que assume content[0].text pode quebrar.
• Parâmetros de amostragem não padrão foram removidos. Enviar temperature, top_p ou top_k fora do padrão produz erro. Orçamentos antigos de pensamento também devem ser substituídos por níveis de esforço.

O guia também orienta manter conversas de uso de ferramentas como histórico apenas acrescentado. Blocos de pensamento são associados ao modelo e à conversa; editar o histórico anterior pode gerar erro em contas onde a verificação já é imposta. Em loops de ferramenta, esses blocos devem voltar sem alteração quando a documentação exigir preservação.

Exemplo mínimo de chamada atualizada

from anthropic import Anthropic

client = Anthropic()
response = client.messages.create(
    model="claude-sonnet-5-5",
    max_tokens=4096,
    output_config={"effort": "medium"},
    messages=[{
        "role": "user",
        "content": "Resuma os riscos e as decisões deste contrato."
    }],
)

for block in response.content:
    if block.type == "text":
        print(block.text)

O exemplo percorre os blocos por tipo em vez de pressupor que o primeiro contém texto. Em produção, a equipe deve adicionar tratamento explícito para uso de ferramentas, recusas e limites de contexto conforme o fluxo da aplicação.

Segurança e limitações

A Anthropic afirma que Sonnet 5.5 recebe salvaguardas cibernéticas semelhantes às do Opus 5.5 e usa os mesmos controles de biologia do Sonnet 5. A empresa diz que solicitações cibernéticas de maior risco podem sofrer fallback visível para Sonnet 5, enquanto desenvolvimento rotineiro não deveria ser afetado. Isso é uma camada de mitigação, não uma garantia de que toda resposta é correta ou segura: a própria documentação reconhece que avaliações não capturam todas as falhas possíveis.

Há também uma limitação comercial e técnica: Sonnet 5.5 tem pesos fechados. Não é opção para organizações que precisam hospedar o modelo em infraestrutura própria, controlar integralmente a retenção ou operar sem dependência de uma plataforma externa. A Anthropic anuncia disponibilidade com zero data retention, mas requisitos de contrato, região, integração de nuvem e governança devem ser confirmados pela organização antes de enviar dados sensíveis.

Análise do NoticIA: a mudança relevante é o contrato de integração

Na análise do NoticIA, o lançamento é mais relevante para quem já opera agentes do que para quem procura apenas um chatbot mais veloz. A tabela de preço não mudou; o ganho prometido vem da eficiência do comportamento do agente. Isso desloca a decisão de compra de uma comparação abstrata de benchmarks para uma disciplina de avaliação: qual modelo conclui o fluxo com menos intervenções, menos custo e menos mudanças indevidas?

As alterações de API reforçam esse ponto. Pensamento automático, blocos assinados e rejeição de escolha forçada de ferramenta tornam integrações mais explícitas sobre como controlam um agente. Equipes que apenas substituírem o identificador do modelo podem descobrir tarde que uma interface deixou de mostrar progresso, um orçamento ficou subdimensionado ou um endpoint passou a retornar 400. A adoção responsável é uma migração com testes de regressão, métricas próprias e plano de fallback — não uma troca cega motivada pelo número de um benchmark.

O que fazer agora

1. Mapeie onde o Sonnet 5 é chamado e identifique código que usa thinking: disabled, escolha forçada de ferramenta ou leitura fixa do primeiro bloco.
2. Monte uma avaliação com tarefas reais, incluindo casos de erro, dados longos, uso de ferramentas e revisão humana.
3. Teste pelo menos os esforços medium e high, registrando custo total, latência, taxa de conclusão e alterações fora do escopo.
4. Valide recusa, fallback e tratamento de blocos antes de liberar para usuários finais.
5. Mantenha o modelo anterior como rota de contingência até a nova linha de base demonstrar ganho no seu fluxo.

Claude Sonnet 5.5 já está ativo; o benefício concreto, porém, dependerá de a eficiência declarada aparecer nas tarefas, dados e políticas de cada implementação.