Como testar o Claude Sonnet 5.5 nas suas próprias tarefas antes de migrar de vez

Fala aí, beleza? O Claude Sonnet 5.5 chegou e a timeline já tá cheia de gente dizendo que ele é "absurdo" 😀

Porém, impressão de uso solto não é critério pra trocar de modelo

A Anthropic lançou o Sonnet 5.5 em 28 de setembro de 2026, seis dias depois do Opus 5.5, e ele já substituiu o Sonnet 5 como modelo padrão nos planos Free e Pro

Ou seja: muita gente migrou sem nem perceber haha

A proposta aqui é outra: montar uma bateria caseira com tarefas reais do SEU repertório, guardando prompt, saída e critério de aprovação, e comparar tudo com o Sonnet 5, que segue disponível como legado

É a mesma lógica que vale pra testar o Fable 5.1 no seu projeto: o teste que importa é o seu, não o da vitrine

Bora ver na prática?

Por que não confiar só nos números do anúncio?

Os números do lançamento são bonitos, mas são afirmações do fabricante, não medição independente

Se liga no que a Anthropic divulgou no anúncio do Claude Sonnet 5.5:

Repara num detalhe: o preço de entrada e de saída por token é o MESMO do Sonnet 5 (e, no Sonnet 5.5, a leitura de cache sai a US$ 0,20 por milhão)

Então a promessa de economia vem do modelo gastar menos tokens pra mesma tarefa, e isso só dá pra confirmar rodando as SUAS tarefas

Onde o Sonnet 5.5 rende mais, segundo a Anthropic?

A própria Anthropic posiciona o Sonnet 5.5 como um complemento mais rápido e mais barato ao Opus 5.5

Segundo ela, ele é mais forte em tarefas do dia a dia com escopo bem definido, correção de bugs e criação de documentos, slides e planilhas caprichados

Isso pode bater certinho com o seu trabalho… ou não

Se o seu dia é refatorar monolito legado gigante, por exemplo, o perfil é bem diferente de "corrigir um bug com escopo fechado"

Por isso o teste precisa ser seu 🙂

O que você precisa antes de montar a bateria:

Nada de PC da Nasa aqui, o checklist é curtinho:

• Acesso ao Sonnet 5.5 por um dos canais disponíveis: Claude API, Claude in Amazon Bedrock, Claude Platform on AWS, Claude on Google Cloud, Claude in Microsoft Foundry, ou pelo Claude Code
• Claude Code instalado, se você quiser rodar a bateria por script (é o caminho que vou usar no passo a passo)
• O ID do modelo na API: claude-sonnet-5-5
• O Sonnet 5 disponível pro lado A da comparação: ele está como legado ativo e não será aposentado antes de 30 de junho de 2027, então dá tempo de sobra pra comparar
• Uma pasta ou planilha pra registrar prompt, saída e veredito de cada tarefa

Se ainda não tem o Claude Code configurado, resolve isso antes de seguir, beleza?

Passo a passo: bateria caseira de comparação do Sonnet 5.5

A ideia geral é simples: mesmo prompt, dois modelos, critério definido antes, resultado registrado

Parece óbvio, mas é exatamente aí que a maioria se perde e acaba decidindo no "achei mais esperto" haha

1. Escolha tarefas reais que espelhem o seu dia a dia:

A Anthropic recomenda que as avaliações espelhem a distribuição real das suas tarefas e incluam casos extremos (os famosos edge cases)

Traduzindo: se a maior parte do seu trabalho é corrigir bug e só de vez em quando você gera documentação, a bateria precisa ter mais ou menos essa cara

Pega tarefas que você REALMENTE fez nas últimas semanas, com o contexto que elas tinham

O erro comum deste passo: escolher só tarefas fáceis ou de vitrine, tipo "cria um todo list"

Qualquer modelo decente passa nisso, e você não aprende nada sobre a migração

2. Escreva os critérios de sucesso ANTES de rodar:

Segundo a Anthropic, bons critérios de sucesso são específicos, mensuráveis, alcançáveis e relevantes

Na prática, troca "o código ficou bom" por algo como "os testes da pasta X passam e nenhum arquivo fora do módulo Y foi alterado"

Escreve isso num arquivo junto com a tarefa, antes de abrir qualquer terminal

O erro comum deste passo: definir o critério depois de ver a saída

Aí você vira advogado do modelo e ajusta a régua pra caber no resultado… Tome cuidado!

3. Escolha a forma de correção de cada tarefa:

A doc da Anthropic separa três formas de avaliar uma saída:

A recomendação da doc é automatizar sempre que possível

Então: se dá pra corrigir com teste ou regex, corrige com teste ou regex, e deixa o olho humano pro que realmente exige nuance

O erro comum deste passo: usar LLM como juiz sem testar a confiabilidade dele antes

Se o juiz erra, a bateria inteira vira ruído bonito

4. Rode o mesmo prompt nos dois modelos no Claude Code:

Aqui o jeito mais limpo é abrir um terminal por modelo, usando claude --model, que vale só pra sessão aberta com ele

No terminal do Sonnet 5.5:

claude --model claude-sonnet-5-5

No outro terminal, abre o Sonnet 5 passando o ID dele no --model (confere o ID exato na página do modelo na Claude Platform Docs)

Outra opção é definir o modelo pela variável de ambiente ANTHROPIC_MODEL, apontando pra um alias ou nome de modelo

E o alias sonnet? No Claude Code ele aponta pro Sonnet mais recente: na versão v2.1.284, isso é o Sonnet 5.5 na Anthropic API

Pra bateria, prefiro deixar o nome explícito, assim você sabe exatamente qual modelo respondeu

O erro comum deste passo: trocar com /model <nome> digitado direto e esquecer de voltar

Digitar o nome direto funciona como o Enter do seletor, ou seja, salva como padrão nas suas configurações de usuário

Se quiser trocar só na sessão atual, roda /model sem argumento, escolhe o modelo no seletor e aperta a tecla s (o Enter troca E salva como padrão)

E tem mais um detalhe que pega muita gente: depois de trocar com /model, a requisição seguinte relê todo o histórico sem aproveitar cache

Resultado: a primeira resposta fica mais lenta, e se você está medindo tempo, a comparação fica distorcida

Mais um motivo pra preferir um terminal por modelo 🙂

5. Automatize com claude -p e saída em JSON:

Rodar na mão funciona pra 3 tarefas, mas pra uma bateria séria o ideal é script

O claude -p (ou --print) executa um prompt e sai, sem interação

O exemplo da documentação do modo headless é este:

claude -p "Summarize this project" --output-format json

Combinando com o --model, você roda a mesma tarefa em cada modelo:

claude -p "Summarize this project" --model claude-sonnet-5-5 --output-format json

Com --output-format json, a resposta vem estruturada com result, session ID, metadados, total_cost_usd e o custo por modelo

Ou seja: dá pra jogar o result direto na sua correção por código e guardar o custo de cada execução sem fazer conta nenhuma

O erro comum deste passo: comparar custo no olho ("parece que gastou menos") em vez de usar o total_cost_usd

A promessa de custo menor do Sonnet 5.5 depende justamente de quantos tokens ele gasta, então o número exato é o que importa

6. Registre tudo por tarefa e consolide:

Pra cada tarefa, guarda uma linha com tudo que precisa pra decidir depois

Um modelo de planilha que funciona bem:

No fim, consolida a taxa de aprovação e o custo total de cada modelo

Esse mesmo esquema de registro serve pra testar uma skill nova no Claude Code, aliás

O erro comum deste passo: não versionar o prompt e mudar o texto entre as rodadas

Se o prompt do Sonnet 5 era um e o do 5.5 ficou "só um pouquinho diferente", você não está mais comparando modelo, está comparando prompt

Já vi muita comparação ir pro lixo por causa disso

Seu código quebrou ao trocar para o Sonnet 5.5? As mudanças incompatíveis

Essa parte é pra quem testa pela API, com código que já roda no Sonnet 5

A Anthropic lista cinco mudanças incompatíveis, e qualquer uma delas pode derrubar sua bateria antes mesmo de avaliar a qualidade:

E como prevenir?

Inclui na bateria pelo menos UMA chamada de cada recurso que seu código usa: thinking, tools, computer use, advisor, o que for

Assim o erro aparece no teste, e não em produção às 3 da manhã haha

Depois, passa no guia oficial Migrating to Claude Sonnet 5.5, na Claude Platform Docs, antes de virar a chave

Que tarefas colocar na bateria (exemplos por perfil)?

Aqui vão categorias pra montar a sua, sem promessa de resultado nenhum, beleza?

O que cada uma vai mostrar depende do seu código e do seu contexto

Correção de bug com teste que precisa passar:

É a categoria mais fácil de corrigir por código: o teste passou ou não passou

Também casa com um dos pontos onde a Anthropic diz que o Sonnet 5.5 rende mais, então vale ver se isso se confirma no SEU repositório

Caso extremo: um bug que envolve dois módulos, ou que só aparece com um input esquisito

Refatoração com escopo fechado:

Algo como "extrair essa lógica pra uma função sem mudar o comportamento"

Critério possível: os testes continuam passando e só os arquivos combinados foram alterados

Caso extremo: um trecho de código legado sem teste nenhum, onde o modelo precisa ser conservador

Geração de documento ou planilha com checklist humano:

Documentos, slides e planilhas também estão na lista de pontos fortes que a Anthropic citou

Aqui a correção costuma ser humana, então monta um checklist objetivo antes (seções obrigatórias, dados que precisam aparecer, formato)

Caso extremo: um documento com informação faltando, pra ver se o modelo inventa ou sinaliza a lacuna

Uma tarefa longa que use a janela de 1M tokens:

O Sonnet 5.5 tem janela de contexto de 1M tokens, então vale incluir uma tarefa que realmente encha o contexto

Pode ser uma análise que precisa cruzar muitos arquivos do projeto, por exemplo

Caso extremo: a informação crucial escondida lá no meio do material, longe do começo e do fim

Como decidir a migração com base na sua bateria?

Recapitulando: tarefas reais, critérios escritos antes, correção automatizada quando der, um terminal por modelo e tudo registrado

Com isso em mãos, a decisão sai da taxa de aprovação e do custo registrados, não da sensação

Se o Sonnet 5.5 aprova igual ou mais e o total_cost_usd fica menor, a migração tem dado pra se sustentar

Se não, você também tem o dado pra segurar a troca 🙂

E fica de olho nos prazos:

• Ainda no Sonnet 4.5? A Anthropic anunciou a depreciação dele, com aposentadoria na Claude API marcada para 30/11/2026, e recomenda migrar pro Sonnet 5.5, então teu teste é prioridade
• No Sonnet 5? Ele segue ativo até pelo menos 30/06/2027, então dá pra testar com calma

No Claude Code, se quiser travar pra onde o alias sonnet aponta, usa a variável ANTHROPIC_DEFAULT_SONNET_MODEL (por exemplo, com claude-sonnet-5-5)

Assim uma atualização futura do alias não muda teu modelo sem você perceber

Próximo passo? Separa HOJE 5 tarefas reais do teu repertório e escreve os critérios antes de rodar qualquer prompt

É o jeito mais rápido de testar o Claude Sonnet 5.5 de verdade, sem depender do hype de ninguém

Até o próximo post! 😀