Claude Sonnet 5.5 encosta no Opus por 30% menos

O gargalo não é inteligência, é custo por tarefa

Claude Sonnet 5.5 chegou com uma promessa que interessa mais para quem opera do que para quem só testa chatbot. Não é sobre ser o modelo mais inteligente do mercado, é sobre entregar quase o nível do Opus 5.5 em tarefas diárias gastando muito menos tokens e respondendo mais de 30% mais rápido. Para quem roda agentes de código o dia inteiro, essa diferença entre acertar de primeira ou precisar de três retries é o que define se a conta fecha no fim do mês.

Quem já colocou um agente autônomo para corrigir bug em repositório grande sabe a dor. O modelo entra, lê dez arquivos, chama ferramenta, erra o caminho, chama de novo, estoura contexto, e o custo por tarefa explode sem que você perceba. A Anthropic diz que o Sonnet 5.5 ataca exatamente esse ponto, com uso de tokens mais eficiente e agrupamento de chamadas de ferramenta. Na prática, isso pode cortar o custo por tarefa em até 30%. Parece pouco no papel, mas em escala vira a diferença entre um piloto viável e um projeto cancelado.

O fato: Sonnet 5.5 quer ser o meio-termo que resolve

A Anthropic lançou o Claude Sonnet 5.5 como o segundo modelo da família 5.5. A proposta é clara na divisão interna. O Opus 5.5 fica com os trabalhos complexos que exigem julgamento cuidadoso, análise profunda e decisões de arquitetura. O Sonnet 5.5 mira o trabalho bem definido do dia a dia, como corrigir bugs, escrever documentação, montar apresentações e criar planilhas. Um Haiku 5.5 deve chegar nas próximas semanas focado em alto throughput e baixo custo.

O modelo já está disponível na AWS, Google Cloud e Azure, o que facilita para empresas que já operam nesses ambientes e precisam de conformidade e controle de região. A Anthropic também afirma ter adicionado novas proteções contra riscos de cibersegurança e contra ataques de destilação, quando terceiros tentam extrair comportamento do modelo para treinar concorrentes. É um detalhe importante para quem expõe o modelo via produto e se preocupa com abuso de API.

Nos números divulgados pela empresa, o salto maior está em código. No Terminal-Bench 4.0, teste para codificação agêntica, o Sonnet 5.5 marca 70,6% contra apenas 10,3% do Sonnet 5 anterior. No CursorBench 4.0, que reproduz sessões reais do editor Cursor, ele faz 55,5% contra 34,1% antes, ficando a apenas dois pontos do Opus 5.5 com 57,8%. No FrontierCode 1.1 em configuração High, ele fica dez pontos acima do Sonnet 5 com cerca de um quinze avos do custo por tarefa, segundo a Anthropic.

Como funciona na visão de quem opera API

Olhando como operador, o ganho não vem só de ser mais esperto. Vem de latência e de disciplina no uso de ferramentas. Saída mais de 30% mais rápida muda a experiência em agentes que fazem dezenas de iterações. Cada segundo economizado por geração se multiplica em loops de planejar, executar, observar e corrigir. Se um fluxo tinha 20 passos, economizar 2 segundos por passo já tira quase um minuto da tarefa completa.

O outro ponto é o batch de tool calls. O Sonnet 5.5 agrupa chamadas com mais frequência que o antecessor, o que reduz o número de idas e voltas. Isso sugere uma arquitetura de orquestração interna mais eficiente e um treinamento voltado para decidir em paralelo em vez de explorar em sequência. É plausível que a Anthropic tenha otimizado o formato de saída e o roteamento interno para tarefas de código e conhecimento, sem aumentar drasticamente o tamanho do contexto. Não há confirmação oficial desse detalhe, mas o comportamento descrito bate com modelos ajustados para função e não só para texto.

Tem um detalhe curioso que reforça essa leitura. No nível máximo de esforço de raciocínio, chamado de Max, o Sonnet 5.5 pontua pior no FrontierCode do que no nível Xhigh. A explicação da Anthropic é que no Max o modelo aciona com mais frequência uma função de revisão de código que divide o trabalho entre vários subagentes. Em alguns casos isso causou timeouts ou alterações fora do escopo, que o benchmark penaliza. Para quem opera, isso é um sinal clássico de overthinking agêntico. Mais agentes nem sempre significam melhor resultado, principalmente se a coordenação custa latência e tokens.

O que isso muda na prática

Em trabalho de conhecimento, o resultado é ainda mais provocativo. No GDPval-AA, benchmark criado pela OpenAI com tarefas de 44 profissões e nove indústrias, o Sonnet 5.5 faz 1.844 pontos, praticamente empatado com o Opus 5.5 com 1.846 e bem acima do Sonnet 5 com 1.449. O GPT-6 Sol aparece com 1.487 nos números da Anthropic. No teste visual Chartography, de leitura de gráficos, ele salta de 15,6% para 61,6%. Testadores iniciais falam de um parceiro de conversa mais natural, com senso de design melhor para interfaces e slides que quase não precisam de ajuste.

Quem ganha com isso é o time que vive no meio termo. Startups que rodam suporte com RAG, agências que geram docs e apresentações, times de engenharia que usam copiloto para refatorar e escrever testes. Quem perde, pelo menos por enquanto, é quem justificava pagar o tier mais caro para tudo. Se o Sonnet entrega 95% do resultado por 70% do custo, fica difícil manter o Opus como padrão para tarefas rotineiras. A briga com a linha GPT-6, com Astra, Sol e Luna, também entra nessa conta. As diferenças entre tiers equivalentes estão pequenas, então preço e latência viram critério de desempate.

Uma ação prática para esta semana é simples. Separe seus prompts em duas filas. Mantenha no Opus apenas o que exige julgamento ambíguo, como revisão arquitetural, decisão de segurança e análise de incidente complexo. Mova todo o resto para o Sonnet 5.5 e meça custo por tarefa resolvida, não custo por milhão de tokens. Acompanhe três métricas por sete dias:

• taxa de resolução na primeira tentativa sem intervenção humana
• número médio de tool calls e de retries por tarefa concluída
• latência ponta a ponta e custo total por tarefa com contexto incluído

Se o Sonnet mantiver a taxa de acerto com menos passos, a troca se paga sozinha. Se ele precisar de mais retries, o desconto de 30% evapora rápido.

Será que escala ou só move o gargalo?

Aqui fica a tensão real. Quase empatar com o Opus em benchmark controlado não garante o mesmo comportamento em repositório legado, com dependência quebrada e teste flaky. O salto de 10,3% para 70,6% no Terminal-Bench parece ótimo, mas também mostra como o modelo anterior era fraco nesse cenário específico. É evolução genuína ou parte do ganho veio de melhor adaptação ao formato do teste. Sem avaliar no seu próprio código, com seus próprios MCPs e permissões, o número é só referência.

Outro ponto é o custo escondido da velocidade. Gerar mais rápido incentiva loops mais longos e subagentes mais agressivos, como vimos no modo Max. Você economiza por token, mas gasta mais tokens porque o sistema tenta mais caminhos. O resultado pode ser uma conta parecida, só que com resposta mais rápida. Isso ainda é bom para produto, porque latência vende, mas não é exatamente a economia prometida. Vale testar com limites rígidos de passos, timeout por subagente e trava de escopo para evitar que o modelo saia alterando arquivo que não deveria.

Conclusão

Sonnet 5.5 parece ser o modelo de trabalho que faltava na família Claude, rápido o suficiente para agente e bom o suficiente para quase aposentar o Opus no dia a dia. A pergunta que fica é direta. No seu workload, ele resolve com menos passos ou só responde mais rápido enquanto continua errando igual.