Metade do time no Sonnet 5 e metade no Sonnet 5.5: por que os resultados do Claude Code não batem?

Antes de culpar o prompt do colega, confere uma coisa: vocês dois estão usando o MESMO modelo? 😛

Fala aí, beleza? Desde 28/09/2026 o Claude Sonnet 5.5 virou o Sonnet padrão do Claude Code na API da Anthropic, a partir da v2.1.284

Ou seja: quem atualizou o Claude Code está num modelo, quem não atualizou está em outro, e ninguém percebeu

Aí começa a discussão clássica no time: "teu prompt tá ruim", "não, o teu que tá", "aqui funciona"… e por aí vai haha

Só que em muitos casos o prompt nem é o problema

O Sonnet 5.5 muda de comportamento em relação ao Sonnet 5, então o mesmo prompt pode render resultados bem diferentes dependendo da máquina onde roda

Bora ver os sintomas mais comuns e como resolver cada um?

Sintoma 1: o colega diz que o Claude Code "para e pergunta" e o seu segue direto

Por que isso acontece?

Segundo o guia de migração da Anthropic, o modelo novo em effort low e medium às vezes para pra confirmar o plano ou pergunta se deve continuar, em tarefas longas de código agêntico

E se liga nisso: no Claude Code o effort padrão dele é medium (na API do Claude o padrão é high)

Então quem já está no modelo novo dentro do Claude Code pode ver essas pausas, e quem ficou no Sonnet 5 não vê

Não é o prompt de um sendo "mais completo" que o do outro, é o modelo

Como resolver:

Antes de reescrever qualquer prompt, cada pessoa roda /status dentro da sessão

Ele mostra a versão do Claude Code, a conta, o modelo e os servidores MCP da sessão

Se os modelos forem diferentes, a discussão sobre prompt acabou ali mesmo xD

Como prevenir:

Combinar o modelo do projeto no .claude/settings.json, que vai pro controle de versão e vale pra todo mundo que clonar o repo (o passo a passo completo está mais abaixo)

Sintoma 2: as respostas de um vêm cheias de notas entre as ferramentas e as do outro não

Por que isso acontece?

O Sonnet 5.5 escreve notas pro usuário entre as chamadas de ferramenta, contando o que encontrou e o que vai fazer em seguida

Além disso, ele vem com adaptive thinking ativado por padrão, enquanto nos modelos anteriores o thinking vinha desligado por padrão

Os níveis de effort também foram recalibrados

Resultado: a mesma tarefa, com o mesmo prompt, gera uma sessão bem mais "falante" no modelo novo

Quem vê isso pela primeira vez acha que o colega escreveu um prompt pedindo explicação passo a passo, mas não, é comportamento do modelo 🙂

Como resolver:

/status de novo, sem polêmica

E na hora de comparar resultados, olhe o que realmente mudou no código, não o volume de texto da sessão

Saber revisar o diff do Claude Code diz muiiito mais sobre qualidade do que a conversa em volta dele

Como prevenir:

Registrar qual modelo é o oficial do repo, e deixar isso escrito no próprio arquivo de configuração do projeto, não só na cabeça das pessoas

Sintoma 3: "sonnet" no meu terminal não é o mesmo "sonnet" do seu

Por que isso acontece?

O alias sonnet não é uma versão fixa: ele acompanha o padrão atual da família

E esse padrão depende de duas coisas: a versão do Claude Code e o provedor que você usa

Na v2.1.284, sonnet resolve assim:

Então se parte do time usa a API da Anthropic e outra parte roda via Bedrock, o mesmo /model sonnet cai em modelos diferentes

E quem está numa versão do Claude Code anterior à v2.1.284 também não recebe o modelo novo pelo alias

Tome cuidado! É o tipo de coisa que ninguém lembra de checar

Como resolver:

Cada pessoa confere a versão instalada no terminal:

claude --version

E depois, dentro da sessão, confere o modelo que está rodando de verdade:

/status

Detalhe: o /status exige a v2.1.280 ou superior, então se ele não funcionar, o claude --version já te dá a primeira pista

Como prevenir:

Usar o ID completo do modelo (claude-sonnet-5-5) em vez do alias, e alinhar uma versão mínima do Claude Code pro time

O alias é prático pro dia a dia individual, mas pra consistência de equipe ele é justamente o que desalinha

Sintoma 4: o projeto define um modelo, mas um colega continua em outro

Por que isso acontece?

Precedência das configurações

O Claude Code lê vários arquivos e flags, e quem está mais acima ganha:

1. managed (a maior prioridade)
2. argumentos da linha de comando
3. local (.claude/settings.local.json)
4. projeto (.claude/settings.json)
5. usuário (~/.claude/settings.json)

Ou seja: se o colega tem um model no settings.local.json dele, ou passa o modelo por flag, isso sobrescreve o que está no settings.json do projeto

E como o settings.local.json é ignorado pelo Git por padrão, ninguém mais no time enxerga esse override 😛

Como resolver:

Revisar o .claude/settings.local.json e as flags de quem está destoando

Achou um model lá? Esse é o culpado

Como prevenir:

Combinar que o modelo fica só no arquivo do projeto, salvo exceção explícita e avisada pro time

Como alinhar o modelo do time inteiro no Claude Code

Beleza, agora o passo a passo pra deixar todo mundo no mesmo modelo

Nada de fórmula mágica, é só configuração bem combinada:

1. Cada pessoa confere versão e modelo. Roda claude --version no terminal e /status dentro da sessão, e manda o resultado no canal do time. O erro comum deste passo: olhar só o que aparece ao abrir a sessão e não confirmar com /status, que é quem mostra o modelo da sessão de verdade

2. Atualizar o Claude Code pra v2.1.284 ou superior. Isso é obrigatório se o time vai usar o modelo novo. O erro comum deste passo: uma pessoa ficar pra trás numa versão antiga e ninguém notar, por isso o passo 1 vem antes

3. Definir o modelo no .claude/settings.json do projeto e commitar. Use o ID completo:

{
  "model": "claude-sonnet-5-5"
}

Depois é commit e push normal, pra valer pra todo mundo que clonar o repo. O erro comum deste passo: colocar "model": "sonnet" achando que isso trava a versão. Não trava! O alias acompanha o padrão atual da família, e só o ID completo fixa o modelo

4. Remover override de model do settings.local.json. Cada pessoa abre o próprio .claude/settings.local.json e tira o campo model, se ele existir. O erro comum deste passo: esquecer que o local sobrescreve o projeto e passar horas achando que o settings.json "não funciona"

5. Pra testar outro modelo na hora, use /model. Por exemplo, /model sonnet. A troca vale na hora, sem reiniciar o terminal. O erro comum deste passo: fazer o teste, esquecer de voltar e depois abrir discussão de qualidade com base nessa sessão

Pronto, com isso o repo passa a dizer qual modelo é o oficial, e não a memória de cada um =)

Quando faz sentido manter parte do time no Sonnet 5

Tem cenário em que dividir o time faz sentido, sim

Mas só quando a diferença é INTENCIONAL e anotada, nunca por acidente

Período de transição:

Rodar o mesmo prompt nos dois modelos durante a migração, pra comparar o resultado com calma antes de virar a chave de vez

A/B controlado:

Duas pessoas, mesma tarefa, cada uma num modelo, com isso registrado no PR ou na tarefa

Aí a diferença de resultado vira dado útil, e não briga sobre prompt

E custo ou contexto, justificam a divisão?

Não justificam, se liga na comparação:

O preço por token é o mesmo e a janela também

A diferença aparece no total: segundo a própria Anthropic, mesmo com a tabela igual, o modelo novo é mais de 30% mais rápido e sai até 30% mais barato na maior parte do trabalho

Ou seja, se o custo pesa pra algum lado, pesa a favor de migrar, não de dividir o time

Outro ponto: o Sonnet 5 já é legado

Ele continua disponível, com aposentadoria não antes de 30/06/2027, mas a Anthropic recomenda migrar pro Sonnet 5.5

Então manter metade do time nele por tempo indeterminado só adia uma migração que vai acontecer de qualquer jeito…

Antes de discutir prompt, confira o modelo

Recapitulando: quando o Claude Code dá resultados diferentes pra pessoas diferentes, a primeira suspeita não é o prompt, é o modelo

O modelo novo pausa pra confirmar em tarefas longas, escreve notas entre ferramentas e vem com thinking ligado, e isso por si só já muda bastante a cara da sessão

O combinado mínimo do time fica assim:

• modelo travado por ID (claude-sonnet-5-5) no .claude/settings.json do projeto
• versão mínima do Claude Code alinhada (v2.1.284 ou superior pra usar o modelo novo)
• /status como primeiro passo em qualquer discussão sobre qualidade de resultado

É a mesma lógica de padronizar o time quando vocês usam Claude Code e Codex juntos: combinado escrito no repo vale mais que dez reuniões

Próximo passo? Abre um PR hoje com o campo model no .claude/settings.json e acaba com a discussão falsa de vez 😀

Até o próximo post!