Claude Sonnet 5.5 na codificação agêntica: por que um modelo mais rápido muda o resultado do agente?

Num agente de código, o tempo entre um passo e outro decide quantas vezes ele consegue errar, verificar e corrigir antes de você desistir de esperar

Fala aí, beleza? A Anthropic soltou o Claude Sonnet 5.5 em 28/09/2026, e o destaque não é só "ficou mais esperto": é que ele ficou mais RÁPIDO e mais barato por tarefa 😀

E se liga que isso não é só conforto pra quem fica olhando o terminal

A tese do post é essa: num fluxo agêntico, velocidade muda o desenho do fluxo e, com isso, muda o resultado que o agente entrega

Bora entender o porquê?

O que a Anthropic lançou com o Claude Sonnet 5.5?

O Claude Sonnet 5.5 é o segundo modelo da família Claude 5.5, lançado em 28/09/2026

Segundo a Anthropic, ele gera saída mais de 30% mais rápido que o Claude Sonnet 5

No Terminal-Bench 4.0, que mede codificação agêntica, o anúncio traz 70,6% pro Sonnet 5.5 contra 10,3% do Sonnet 5

Tome cuidado com esse número: ele vem do anúncio de lançamento, e não existe uma página de dados independente pra conferir

No CursorBench (tarefas tiradas de sessões reais do Cursor), a melhor pontuação do Sonnet 5.5 fica a cerca de 2 pontos do Opus 5.5

E o preço? Não mudou nada em relação ao Sonnet 5:

• US$ 2 por milhão de tokens de entrada
• US$ 10 por milhão de tokens de saída
• US$ 0,20 por milhão de tokens de leitura de cache
• US$ 2,50 por milhão de tokens de escrita de cache

Tem também relato de cliente, sempre na palavra de quem relatou

A Box disse que teve resultados 2,4x mais rápidos com 12% menos tokens no total

Já a Atlassian afirmou que os clientes rodam os Rovo Agents até 30% mais rápido que com o Sonnet 5

Por que um modelo mais rápido muda o resultado de um agente de código?

Aqui é o coração do post, então vou separar bem o que é dado da Anthropic e o que é raciocínio de desenho de fluxo, beleza?

Um agente de código não responde uma vez e pronto

Ele lê o código, roda um comando, lê a saída, decide, edita, roda de novo e por aí vai

O custo real de uma tarefa é a SOMA desses passos, tanto em tempo quanto em tokens

É tipo um dev fazendo TDD: quanto mais rápido o teste roda, mais vezes ele testa, e mais cedo ele pega o erro 🙂

Mais verificação no mesmo tempo:

Se cada etapa demora menos, cabe mais etapa de verificação na mesma janela de paciência

Na prática (e aqui é raciocínio de fluxo, não número da Anthropic), dá pra desenhar o agente pra rodar os testes depois de cada mudança, ler a saída e só então seguir

Com um modelo lento, a tendência é cortar essas checagens pra não esperar uma eternidade

Com um modelo mais rápido, verificar deixa de ser luxo

Ciclos curtos de tentativa e erro:

Agente bom não é o que acerta de primeira, é o que erra rápido e corrige rápido haha

Menos espera entre etapas permite ciclos curtos: tenta, quebra, lê o erro, conserta

Isso é melhor do que um passo gigante que tenta resolver tudo de uma vez e, quando dá errado, joga fora muiiito trabalho

Menos chamadas de ferramenta, menos passos:

Agora o dado da Anthropic: nas comparações diretas, o Sonnet 5.5 agrupa (batch) chamadas de ferramenta com mais frequência que o Sonnet 5

Que batch? É juntar várias ações numa rodada só, em vez de pedir uma, esperar, pedir outra, esperar…

Isso significa menos passos e custo menor

A própria Anthropic atribui a redução de até 30% no custo por tarefa justamente a dois fatores: maior velocidade e menos chamadas de ferramenta

Um lembrete do que vi testando um agente:

No vídeo abaixo tem um teste que fiz com um agente da Anthropic, e o comportamento que apareceu ali tem tudo a ver com esse assunto

Quando testei, pedi um simulador de tráfego urbano num único arquivo, com ruas, cruzamentos, semáforos e carros em movimento

Não chegou a 10 minutos, numa única interação, e funcionou bem: carros respeitando as regras e status na tela, só precisando de ajuste de zoom e visualização

No outro teste, pedi um sistema web com dashboard, três gráficos, busca, filtro por tag, autenticação por e-mail e senha e tema escuro, e pedi explicitamente um plano antes de executar

Levou cerca de 15 minutos e entregou conta demo, arrastar e soltar funcionando e autenticação ok (não testei todas as funcionalidades)

O que me incomodou: o modelo escreveu o plano e NÃO pediu confirmação, simplesmente saiu executando

E aí entra o ponto do post: quanto mais rápido o agente anda, mais importante é tu colocar o ponto de parada no desenho do fluxo, porque ele não vai necessariamente esperar por você

Sonnet 5.5 vs Sonnet 5 vs Opus 5.5: velocidade, custo e desempenho

Lendo a tabela: o Opus 5.5 custa o dobro por token, tanto na entrada quanto na saída

Já a distância de desempenho no CursorBench é pequena, cerca de 2 pontos

Ou seja, pra boa parte das tarefas, tu paga metade por token e ainda ganha velocidade, abrindo mão de pouca coisa em desempenho medido

Quando a velocidade compensa mais que capacidade bruta?

Velocidade do Sonnet 5.5 compensa em:

• Tarefas cotidianas bem delimitadas: escopo claro, começo e fim definidos
• Correção de bugs: é justamente um dos pontos fortes citados pela Anthropic
• Loops com muitos passos de verificação: rodar teste, ler saída, corrigir, repetir
• Criação de documentos, slides e planilhas: também listados entre as tarefas em que ele é mais forte
• Fluxos em que o custo por tarefa pesa: automação que roda o dia inteiro, por exemplo

Capacidade bruta do Opus 5.5 compensa em:

• Trabalho complexo e aberto: tarefa sem escopo fechado, que exige julgamento sustentado ao longo de muitas decisões

Tem mais um critério que vale MUITO a pena: o effort

Que effort? É o nível de esforço que o modelo coloca na tarefa, controlado pela API

Segundo a Anthropic, em vários benchmarks o Sonnet 5.5 em effort Low ou Medium supera a melhor pontuação do Sonnet 5 por cerca de um décimo do custo por tarefa

E effort mais baixo gera chamadas de ferramenta menos numerosas e mais enxutas

Então a pergunta não é só "Sonnet ou Opus?", é também "quanto esforço essa tarefa realmente precisa?"

E se o custo pesa tanto que tu já pensou até em rodar o modelo na sua máquina, vale comparar essa opção com o custo por tarefa de um modelo mais eficiente

O que muda para quem usa Claude Code, API e GitHub Copilot?

Cada produto tem sua realidade, então vou separar certinho pra não misturar as coisas

Na API:

O model ID é claude-sonnet-5-5, acessível pela Claude Platform

O parâmetro effort está documentado em Build with Claude > Effort, e é ali que tu consulta como usar

Nas nuvens:

O Sonnet 5.5 está disponível na AWS, no Google Cloud e no Microsoft Azure

No GitHub Copilot:

O Claude Sonnet 5.5 está em disponibilidade geral (GA) no GitHub Copilot

No Claude Code:

Hoje o Opus 5.5 é o modelo padrão no Claude Code em todos estes planos: Pro, Max, Team e Enterprise

No Pro e no Team Standard (a modalidade padrão do plano Team), o padrão era Sonnet até a versão 2.1.280 do Claude Code, que trocou pra Opus

Não tenho confirmação de que o Sonnet 5.5 já pode ser escolhido dentro do Claude Code, nem em quais planos, então não vou ensinar passo de troca de modelo aqui

O que dá pra dizer é: os critérios da seção anterior continuam valendo pra você decidir onde o Sonnet 5.5 faz sentido quando ele estiver no teu fluxo

E se tu usa outros produtos da Anthropic, vale entender também qual modelo roda no Cowork, porque cada produto tem seu padrão

Veredito: Claude Sonnet 5.5 é o modelo certo para o seu agente?

Pra maior parte do trabalho agêntico do dia a dia, sim, tem cara de ser a escolha de melhor custo por tarefa

Mais velocidade, batching de ferramentas, mesmo preço do Sonnet 5 e desempenho perto do Opus 5.5 no CursorBench: essa combinação é bem massa

Mas o Opus 5.5 continua sendo a aposta pra tarefas longas, abertas e que exigem julgamento sustentado

E lembrando: os benchmarks citados aqui vêm do anúncio da Anthropic, então o teste no teu próprio código é o que vai bater o martelo

Próximo passo:

Escolhe uma tarefa delimitada do teu fluxo: um bug conhecido, ou um conjunto de testes que precisa passar

Roda o agente com o Sonnet 5.5 e com o modelo que você usa hoje, e observa duas coisas: quantos passos ele deu e quanto tempo levou no total

Se tu usa a API, começa por um effort mais baixo, já que a própria Anthropic aponta ganho de custo nesse modo

E aí sobe o effort só se a qualidade não bater 😉

Faça o teste e depois me conta o que achou!

Até o próximo post!