Como montar seu próprio teste comparativo antes de adotar o Claude Opus 5.5 no time

Ranking genérico diz qual modelo é bom em média

Ele não diz nada sobre o seu repositório, com a sua bagunça de seis anos e aquele módulo que ninguém quer tocar

A Anthropic lançou o Claude Opus 5.5 em 22 de setembro de 2026, primeiro modelo da família 5.5, e a pergunta dentro do time nunca é "quem ganhou o benchmark?"

A pergunta é: a gente troca o modelo padrão ou não?

Nenhum leaderboard responde isso pra você

Quem responde é um teste seu, com tarefas suas, critério escrito antes de rodar e custo medido

E a boa notícia: isso dura uma tarde e custa pouco, se você montar direito

Por que o ranking público não decide por você

Vamos dar crédito ao que o número diz, porque ele diz algo

No Artificial Analysis Intelligence Index, o Claude Opus 5.5 está em 1º lugar entre 173 modelos ranqueados, com score 58 na configuração Adaptive Reasoning, Max Effort, Default Fallback

A distância não é de empate: 58 contra 53 do GPT-6 Astra e do Claude Fable 5.1 (empatados) e 51 do Claude Opus 5

O GPT-6 Sol aparece com 48 na variante max

Em avaliações individuais medidas pelo Artificial Analysis, o Opus 5.5 fez 61,4% em Humanity’s Last Exam (o melhor anterior era 59,1%, do Claude Fable 5.1) e 66,9% em SciCode (anterior 63,1%)

Na tabela de lançamento da Anthropic, o resultado em Terminal-Bench 4.0 foi de 66,4%

O que esse índice mede, na real:

A versão v4.3.2 do índice é composta por 10 avaliações: AA-Briefcase v1.1, GDPval-AA v2.1, AutomationBench-AA, Terminal-Bench 4.0, SciCode, Humanity’s Last Exam, GDP.pdf, CritPt, AA-Omniscience e AA-LCR v1.1

Olha a lista de novo e procura o seu sistema ali

Não tem, né?

Nenhuma dessas avaliações conhece o seu padrão de nomenclatura, a sua camada de serviço, o seu ORM antigo, aquele teste que quebra na terça

Sinal é útil, veredito é outra coisa

A prova de que configuração muda tudo:

O mesmo Claude Opus 5.5 tem score diferente por nível de esforço no índice: Max 58, Xhigh 56, High 54, Medium 51

Ou seja: o modelo no Medium empata com o Opus 5 no ranking

É o MESMO modelo

Só mudou como você pediu

Então qualquer conversa de "o modelo X é melhor que o Y" sem dizer configuração, prompt e contexto é conversa vazia

É exatamente por isso que o teste precisa ser seu, e a lógica aqui é a mesma de quando você vai testar um modelo no seu próprio projeto antes de trocar o padrão do time

O que você precisa antes de rodar o primeiro teste

Antes de abrir o terminal, três coisas: acesso, preço de tabela e ID de modelo

Acesso ao modelo:

Pra quem constrói, o Claude Opus 5.5 está na Claude Platform (API nativa), Amazon Web Services, Google Cloud e Microsoft Foundry

Nas assinaturas, está disponível para usuários Pro, Max, Team e Enterprise

No Claude Code, ele entrou desde o dia do lançamento

E no GitHub Copilot também, desde 22 de setembro de 2026

Escolha UM ambiente pro teste e fique nele

Se você rodar metade das tarefas na API e metade no Claude Code, o resultado vira salada e você não sabe mais o que está medindo

Preço de tabela, pra orçar antes:

Por milhão de tokens, o Claude Opus 5.5 custa US$ 4 de entrada e US$ 20 de saída

No cache: leitura de cache US$ 0,20 por milhão (0,05x o preço base de entrada), escrita de cache de 5 minutos US$ 5 e escrita de cache de 1 hora US$ 8

Esse número do cache é importante pro seu teste, porque repetir a mesma tarefa com o mesmo contexto é justamente o cenário em que cache read aparece

IDs de modelo (copia e cola):

Na Claude API, o ID é claude-opus-5-5

No Amazon Bedrock, é anthropic.claude-opus-5-5, com perfis de inferência us.anthropic.claude-opus-5-5 e global.anthropic.claude-opus-5-5 (também existem eu., au. e jp.)

E o Opus 5, morreu?

Não

O Claude Opus 5 continua disponível na Claude Platform, com página de modelo ativa na documentação

Isso é o que torna o teste comparativo possível de verdade: você não está comparando "Opus 5.5 contra a lembrança que eu tenho do Opus 5"

Você roda os dois, na mesma tarde, com o mesmo prompt

Como montar o teste comparativo passo a passo

1. Selecione tarefas reais do repositório, com tipos variados

Pega de 5 a 8 tarefas do último sprint, coisas que já foram feitas (você já sabe como é o resultado certo, isso é ouro)

Mistura os tipos: bug pequeno, refactor grande, script de terminal, escrita de teste

O erro comum deste passo: escolher só tarefa fácil, porque dá gosto de ver funcionando. Teste onde tudo passa não decide nada

2. Congele o prompt e o contexto entregue

Mesmo texto, mesmos arquivos anexados, mesma ordem, pra todas as rodadas

Salve o prompt num arquivo e leia de lá, porque reescrever de memória é o jeito mais rápido de invalidar o teste

bench/
  tarefa-01-bug-legado/prompt.md
  tarefa-02-refactor-servico/prompt.md
  tarefa-03-script-terminal/prompt.md
  tarefa-04-teste-unitario/prompt.md
  resultados.csv

O erro comum deste passo: "melhorar" o prompt na segunda rodada porque o primeiro modelo entendeu mal. Aí você não está comparando modelo, está comparando prompt

3. Escreva o critério de acerto ANTES de rodar

Isso não é burocracia, é o que separa teste de impressão

A orientação da Anthropic em definir critérios de sucesso é clara: critérios devem ser específicos e mensuráveis, com métrica quantitativa ou escala qualitativa bem definida, e a maioria dos casos precisa de avaliação multidimensional

Multidimensional porque "funcionou" é pouco

O patch pode funcionar e ainda assim inventar uma dependência nova, ignorar o padrão do projeto, quebrar o lint

Escreve assim, antes: passa nos testes existentes, não adiciona dependência, segue o padrão da camada, diff abaixo de X linhas

O erro comum deste passo: decidir o critério depois de ver a saída. Aí o critério viraceitação do que já saiu 😅

4. Fixe o modelo de cada rodada sem contaminar o resto do time

No Claude Code, o /model salva o valor escolhido como padrão para novas sessões

Pra testar sem mexer no padrão do seu usuário: no seletor do /model, pressione a tecla s, que troca de modelo sem salvar como padrão

E tem a precedência, que é o que resolve script de teste: a variável ANTHROPIC_MODEL sobrepõe a configuração de model, e a flag –model sobrepõe as duas para a sessão

# rodada A: fixa o modelo só nesta sessão
claude --model claude-opus-5-5

# rodada B: mesma tarefa, modelo anterior
claude --model claude-opus-5

Sobre alias: existem aliases como opus e sonnet, pra selecionar modelo sem decorar número de versão, mas a versão que cada alias resolve depende do provedor

Em deploy via Amazon Bedrock, Google Cloud, Microsoft Foundry ou Claude Platform na AWS, dá pra fixar a versão que cada alias resolve com ANTHROPIC_DEFAULT_OPUS_MODEL, ANTHROPIC_DEFAULT_SONNET_MODEL, ANTHROPIC_DEFAULT_HAIKU_MODEL e ANTHROPIC_DEFAULT_FABLE_MODEL

O erro comum deste passo: rodar tudo com alias e anotar "opus" na planilha. Semanas depois ninguém sabe qual versão foi testada. Anote sempre o ID completo

5. Isole as sessões e leia o consumo de cada rodada

Uma tarefa por sessão, sempre

O /clear inicia uma nova sessão, e os totais de uso zeram nesse momento

O bloco Session, no topo do /usage, mostra as estatísticas de uso de tokens da sessão atual

/clear
# cola o prompt da tarefa, trabalha até aceitar ou desistir
/usage
# anota o que aparece no bloco Session

O erro comum deste passo: fazer três tarefas na mesma sessão e depois tentar dividir o custo por cabeça. Não dá, o contexto de uma vaza pra outra e o número perde sentido

6. Avalie com LLM como juiz, e com régua fechada

Pra avaliação automatizada, a recomendação da Anthropic é instruir o modelo a responder apenas correct ou incorrect, ou julgar numa escala de 1 a 5

E tem um detalhe que muda qualidade: pedir que o modelo raciocine antes de dar a nota, e depois descartar o raciocínio, melhora o desempenho da avaliação

Você é juiz de uma avaliação de código.
Critérios (todos obrigatórios):
1. passa nos testes existentes
2. nenhuma dependência nova
3. segue o padrão da camada de serviço do projeto

Raciocine dentro de <analise></analise>.
Depois responda SÓ com uma linha final: correct ou incorrect

O erro comum deste passo: usar juiz com pergunta aberta ("o código está bom?"). Resposta aberta não vira coluna de planilha

7. Conte o retrabalho em número de prompts até o resultado aceito

Essa é a métrica que ninguém publica e que mais importa no dia a dia

Um modelo que acerta no primeiro prompt e um que acerta no quarto têm a MESMA nota de acerto na planilha

Mas custam diferente, demoram diferente e cansam o dev de forma bem diferente

Então anota: 1 prompt, 3 prompts, desisti no 6

O erro comum deste passo: contar só o prompt principal e esquecer os "agora conserta o import", "tira esse comentário", "volta o que você mudou no outro arquivo". Tudo isso é retrabalho e entra na conta

Planilha de comparação: o que registrar em cada rodada

Uma linha por tarefa por modelo

Se são 6 tarefas e 2 modelos, são 12 linhas, e a planilha decide sozinha no fim

De onde vem o valor em dólar que aparece:

Vale saber como o número é produzido, pra você não tratar ele como fatura

O Claude Code calcula o valor localmente a partir da contagem de tokens usando o preço de tabela, a menos que uma tabela modelPricing esteja em vigor, definida por administrador nas managed settings da organização

Se na sua empresa existe essa tabela, o valor que você vê pode refletir o acordo da organização e não o preço público

Anota isso num rodapé da planilha, porque alguém vai perguntar

O /usage também aponta o que está pesando:

Em planos Pro, Max, Team ou Enterprise, o detalhamento do /usage sinaliza comportamentos responsáveis por 10% ou mais do uso recente, como contexto longo ou cache miss, com dica pra reduzir cada um

Isso é diagnóstico de graça

Se o teste inteiro apontar cache miss, talvez o problema não seja o modelo, seja como você está montando o contexto a cada rodada

O que aprendi testando Opus na prática (e o que copiar disso)

Quando testei o Opus 4.5 pro vídeo, o que me ensinou mais não foi o resultado bonito

Foi o processo

Eu testei o modelo exaustivamente, ao ponto de esbarrar várias vezes no limite de uso durante os testes

Teve teste que não terminou por isso: tentei gerar uma landing page de portfólio pessoal (com hero e nome) e o limite chegou antes do resultado

Isso, na metodologia, é um dado também: parte do custo de adoção é você conseguir ou não terminar o trabalho na janela que tem

O teste que mais me mostrou maturidade foi uma simulação de campo de dominós com física

Deu pra escolher tipo de desenho e quantidade de peças, ver a derrubada, girar a câmera, dar zoom

E o zoom ficou malfeito, um fade azul que não ficou bom

Olha como isso entra na planilha do jeito certo: acerto no essencial, falha num critério visual específico

Não é "gostei" nem "não gostei", é critério

O dado mais útil do teste todo:

O campo de dominós NÃO foi one shot

Foram mais de um prompt, por volta de três, até chegar num resultado que eu considerei legal

Parece detalhe, mas é o coração do método

Se eu tivesse contado só "funcionou", o teste mentiria pra mim

Contando prompts, eu sei o preço real da tarefa: três rodadas de contexto, três rodadas de saída, três interrupções no meu foco

Essa é a métrica de retrabalho que eu levaria pra qualquer avaliação do Claude Opus 5.5 hoje

Outros testes seguiram o mesmo padrão: SVG de personagem de jogo (pedi o Cloud, de Final Fantasy 7, com a Buster Sword) e o resultado saiu parecido com o personagem, fugindo do padrão de cidade que eu via em todo teste por aí

Depois pedi uma cidade animada, com prompt em inglês, mais elementos e animação, e o resultado me surpreendeu

No teste lado a lado de portfólio de designer, com o mesmo prompt em dois modelos de empresas diferentes, o do Claude me pareceu mais ousado e alinhado à proposta, mas com detalhes malfeitos: fonte grande demais e um botão de voltar ao topo que não funcionava

Mesmo assim, eu usaria a página do Claude

E teve o teste que simplesmente não passou: um JRPG com poucos prompts

Saíram elementos em SVG, personagem andando no mapa, mas a batalha ficou ruim, controle confuso, batalha que não terminava

Não cheguei num JRPG satisfatório só com prompt, e isso ficou registrado como falha, não como "quase"

Teste honesto tem linha vermelha na planilha, senão não é teste

Quatro lotes de tarefa que valem a pena colocar no seu teste

Não invente tarefa sintética

Puxa do trabalho real, distribuído nestes quatro lotes:

1. Bug em código legado:

Um bug que você já corrigiu, num arquivo velho, com dependência esquisita

O que observar: o modelo entende o padrão do projeto ou reescreve tudo do jeito dele? O diff é cirúrgico ou é faxina não pedida?

Esse lote é o que mais separa modelo bom de modelo que só escreve código novo bonito

2. Refactor grande, que exige contexto amplo:

Aqui você usa o que o Claude Opus 5.5 tem de músculo: 1 milhão de tokens de contexto e 128 mil tokens de saída máxima

Joga um módulo inteiro e pede a reorganização

O que observar: coerência do começo ao fim da saída, e se ele perde o fio quando o contexto cresce

Esse lote é também o mais caro da rodada, então anote tokens de entrada com atenção

3. Tarefa de terminal e automação:

Script de migração, rotina de build, comando que encadeia passos

É o tipo de coisa que o Terminal-Bench 4.0 tenta medir, e onde o Opus 5.5 marcou 66,4% na tabela de lançamento

Mas o seu terminal tem as suas ferramentas, as suas permissões, os seus caminhos

O que observar: ele confere antes de destruir ou sai fazendo os rm -rf da vida? 😬

4. Geração de teste:

Pede teste pra uma função que já tem teste, e compara

O que observar: cobre caso de borda ou só o caminho felizinho? O teste passa por realmente testar ou por ser frouxo?

Esse lote tem critério de acerto fácil de escrever, então é ótimo pra calibrar o seu juiz antes dos lotes difíceis

Se esse for o seu primeiro teste organizado com o Claude Code, vale a mesma lógica de montar um sistema começando pequeno: um lote, um critério, uma planilha, depois cresce

Custo e velocidade: o que muda no orçamento do time

Agora traduz número pra decisão

Frente ao Opus 5, o Claude Opus 5.5 tem preço por token 20% menor, leitura de cache 60% mais barata e custo 40% menor pra rodar cargas típicas

Na velocidade, gera saídas mais de 30% mais rápido que o Opus 5

Por que isso importa mais do que parece: se o acerto empatar, um custo menor por carga típica já é argumento suficiente pra trocar, porque você não está pagando pela troca

E saída mais rápida mexe direto na experiência do dev naquelas tarefas de 128 mil tokens de saída, onde esperar é metade do trabalho

Fast mode: deixa fora da comparação base

O Claude Opus 5.5 tem um fast mode que entrega até 2,5x mais tokens de saída por segundo

Pra ligar, você define speed: "fast" com o header beta fast-mode-2026-02-01

speed: "fast"
anthropic-beta: fast-mode-2026-02-01

Tem duas pegadinhas importantes

A primeira é onde funciona: é research preview e está apenas na Claude API (incluindo Claude Managed Agents), não em Amazon Bedrock, Claude Platform na AWS, Google Cloud ou Microsoft Foundry

A segunda é o preço: US$ 8 por milhão de tokens de entrada e US$ 40 de saída, o dobro da tabela normal

Por isso ele não entra na comparação base

Se você misturar fast mode em algumas rodadas, a sua coluna de custo deixa de comparar modelo e passa a comparar configuração de velocidade

Teste ele depois, como um experimento separado, com pergunta separada: vale pagar o dobro pra esperar menos naquele caso específico?

Depois da decisão, mede a adoção

Quando o time trocar, o teste não acaba

A Claude Code Analytics API acompanha sessões, linhas de código, commits, pull requests e uso de ferramentas, com dados de tokens e custo estimado divididos por modelo Claude

É ali que você descobre se a economia prometida apareceu no fim do mês ou se o time só passou a pedir coisa maior 😄

Como ler o resultado e decidir a adoção

Com a planilha cheia, a regra de decisão fica simples e sem debate de gosto:

• Empate técnico em acerto, custo menor: troca. Não precisa de ganho de qualidade pra justificar pagar menos pela mesma entrega
• Ganho de acerto no lote crítico, custo igual: troca também. Se o lote de bug em legado sobe de nota, o retrabalho que você economiza vale mais que a diferença na fatura
• Perda em qualquer lote: não troca o padrão do time ainda. O Opus 5 segue disponível na Claude Platform, então rollback é decisão, não emergência
• Resultado embaralhado por lote: aí a resposta não é "um modelo", é modelo por tipo de tarefa, e você anota isso no guia interno do time

Se a decisão for migrar, existe um guia oficial na documentação, a página Migrating to Claude Opus 5.5, e vale ler antes de mexer em produção

Um detalhe que pode mudar sua conta logo: a Anthropic anunciou Claude Sonnet 5.5 e Claude Haiku 5.5 pra as semanas seguintes, com as mesmas melhorias de performance, eficiência e segurança

Se o seu teste mostrar que metade das tarefas nem precisava de Opus, essa metade tem chance de ficar bem mais barata em breve

Guarda a planilha, porque ela vai ser reaproveitada

Outro ponto pra tranquilizar quem decide: o Claude Opus 5.5 foi testado antes do lançamento por avaliadores externos, incluindo a METR, e é o modelo com melhor desempenho já testado pela Anthropic na auditoria comportamental automatizada dela

Isso não substitui o seu teste de qualidade, mas ajuda na conversa de risco com quem assina o contrato

Conclusão

O teste comparativo que decide adoção não é projeto de mês

São 5 a 8 tarefas reais, prompt congelado, critério escrito antes, /clear entre sessões, /usage anotado e prompts contados

Uma tarde, uma planilha, uma decisão que você consegue defender numa reunião sem citar ranking de internet

E o barato aqui é literal: com US$ 4 de entrada e US$ 20 de saída por milhão de tokens, um lote de teste sai por bem menos do que uma semana de time discutindo qual modelo é melhor

Próximo passo, hoje mesmo: abre o board do último sprint, escolhe 5 tarefas já resolvidas, escreve o critério de acerto de cada uma num arquivo

Só depois abre o terminal

Aí você roda o primeiro lote com o Claude Opus 5.5, o segundo com o Opus 5, e deixa a planilha falar

Bora testar? Depois me conta o que a sua deu, porque o resultado de cada repositório é uma surpresa diferente…

até o próximo post!