Trocou de versão do Sonnet e a resposta piorou? O que revisar no seu prompt antes de culpar o modelo

Fala aí, beleza? Tu trocou pro Sonnet 5, rodou exatamente o mesmo prompt de sempre e a resposta veio… pior

Mais curta, ou mais longa, ou aplicando a regra só no primeiro item, ou estourando no meio da saída

A sensação é sempre a mesma: "nerf silencioso, lançaram versão nova e degradaram"

Só que antes de culpar o modelo vale olhar pro texto que tu manda pra ele

A Anthropic descreve o Sonnet 5 como upgrade drop-in do Sonnet 4.6, mas com três mudanças de comportamento declaradas: adaptive thinking ligado por padrão, extended thinking manual retornando erro 400 e parâmetros de sampling (temperature, top_p, top_k) com valor não padrão retornando erro 400

"Drop-in" quer dizer que tu troca o ID do modelo e a coisa roda, não que o prompt afinado na versão anterior continua ótimo

Ele foi lançado em 30/06/2026, é o padrão dos planos Free e Pro e está disponível também no Max, Team e Enterprise, com o ID claude-sonnet-5 na API

Então bora fazer o diagnóstico direito: sintoma, causa e o que revisar no seu prompt no Sonnet 5 😀

A resposta ficou curta demais (ou longa demais) depois da troca

O sintoma: mesma tarefa, mesmo prompt, e o tamanho da resposta mudou de patamar

Umas ficam secas demais, outras viram um textão que ninguém pediu

A causa: o Sonnet 5 calibra o tamanho da resposta pela complexidade da tarefa, em vez de manter uma verbosidade fixa

Consulta simples tende a resposta mais curta, análise aberta tende a resposta mais longa

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 114 aulas
• 4 projetos
• 9h 18min

Conhecer formação

Se o seu prompt antigo controlava tamanho "por acidente" (porque a versão anterior tinha um tamanho médio previsível), esse controle sumiu

A solução: pedir concisão de forma explícita, do jeito que a própria doc sugere

Provide concise, focused responses. Skip non-essential context, and keep examples minimal.

E tem um detalhe que muita gente inverte: a doc afirma que exemplos positivos mostrando o nível de concisão desejado tendem a ser mais eficazes do que exemplos negativos ou instruções sobre o que não fazer

Ou seja, em vez de "não escreva parágrafos longos", mostra um parágrafo do tamanho que tu quer

Como prevenir: defina tamanho por EXEMPLO, não por adjetivo

"Seja breve" é opinião, um trecho de saída modelo é contrato 🙂

A instrução vale só para o primeiro item: o modelo parou de generalizar

O sintoma: tu pede um formato, ele aplica lindamente na primeira seção e larga o resto no formato antigo

Parece desatenção, mas não é

A causa: o Sonnet 5 interpreta o prompt de forma literal e explícita

Ele não generaliza silenciosamente uma instrução de um item para outro, nem infere pedido que não foi feito, e isso aparece principalmente em níveis de effort mais baixos

É como um dev novo no time que faz exatamente o que está no card: se o card falava da primeira seção, ele fez a primeira seção

A solução: escrever o escopo dentro da própria instrução, igual ao exemplo da doc

Apply this formatting to every section, not just the first one

Quando a resposta não vem como tu quer, reescrever o pedido rende muito mais que repetir o mesmo pedido em voz mais alta, mesma lógica de reescrever o prompt depois de uma recusa

Como prevenir: passa instrução por instrução perguntando "a quem isso se aplica?"

Se a resposta for "a tudo", isso precisa estar escrito

Instrução redundante virou overtriggering: a ferramenta dispara demais

O sintoma: chamada de ferramenta pra tudo, resposta inflada, custo subindo sem tu ter mexido em nada

A causa: aquelas linhas defensivas que tu escreveu porque o modelo antigo disparava DE MENOS

A orientação oficial é direta: remover o over-prompting

Ferramentas que disparavam de menos em modelos anteriores agora disparam adequadamente, e instruções tipo If in doubt, use <tool> causam overtriggering

A solução: trocar padrão genérico por instrução direcionada

# antes
Default to using <tool>

# depois
Use <tool> when it would enhance your understanding of the problem

Repara que a correção não é apagar a menção à ferramenta, é dizer QUANDO ela ajuda

Como prevenir: cada linha defensiva do prompt precisa justificar por que ainda existe

Muita coisa que a gente chama de prompt bom é só cicatriz de um modelo que não existe mais, e isso é um dos erros mais comuns de engenharia de prompt

O formato de saída quebrou: prefill e parâmetros que agora retornam erro 400

O sintoma: erro 400 na cara, ou saída fora do formato que o seu parser esperava

Aqui não tem sutileza, são causas separadas e bem documentadas

• prefill da mensagem do assistant não é suportado no Sonnet 5 e retorna erro 400 (mesmo comportamento do Sonnet 4.6)
• thinking: {type: "enabled", budget_tokens: N} foi depreciado no Sonnet 4.6 e no Sonnet 5 retorna erro 400
• temperature, top_p e top_k com valor não padrão retornam erro 400

A solução: as substituições documentadas pro prefill são structured outputs, instruções no system prompt ou output_config.format

E no lugar do extended thinking manual entra o adaptive thinking com o parâmetro effort

Se o seu formato dependia de começar a resposta com { pela boca do assistant, esse truque acabou

Como prevenir: trate formato como contrato do prompt, não como truque de API

Truque de API quebra em toda migração, contrato escrito sobrevive

A saída aparece cortada: o tokenizer novo mudou a sua conta

O sintoma: resposta truncada no meio, sem motivo aparente, com o mesmo texto de entrada de antes

A causa: o novo tokenizer gera aproximadamente 30% mais tokens para o mesmo texto em relação ao Sonnet 4.6

Aí todo max_tokens que tu dimensionou colado no tamanho esperado da saída passa a estourar

O texto não cresceu, a régua que mede ele mudou

A solução: recontar os prompts com token counting e revisar os limites de max_tokens dimensionados perto do tamanho esperado da saída

Espaço tu tem: a janela de contexto é de 1M tokens e a saída vai até 128k tokens

O Sonnet 5 mantém o mesmo conjunto de ferramentas e recursos de plataforma do Sonnet 4.6, com uma exceção: Priority Tier não está disponível

Como prevenir: nunca dimensione max_tokens colado no tamanho esperado da resposta

Margem folgada custa zero enquanto não é usada, truncamento custa a requisição inteira

Você herdou o nível de effort do modelo anterior

O sintoma: qualidade ou custo fora do esperado sem tu ter mexido uma vírgula no prompt

A causa: o nível de effort foi copiado da versão antiga, e o mesmo nome não significa o mesmo esforço

A doc de migração é clara na equivalência:

Ou seja, quem estava em high no 4.6 e manteve high no Sonnet 5 subiu de patamar sem perceber

Os níveis disponíveis são:

• low: tarefas curtas e sensíveis a latência
• medium: casos sensíveis a custo
• high: o padrão (igual ao padrão do Sonnet 4.6)
• xhigh: recomendado pras tarefas de código e agênticas mais difíceis
• max: capacidade máxima sem restrição de gasto de tokens

A solução: rodar um sweep novo de effort sobre os seus próprios evals, em vez de herdar o ajuste do modelo anterior

A recomendação é testar low e medium como controle de custo e latência, e max onde capacidade máxima importa mais que gasto de tokens

Como prevenir: compare pelo tamanho observado do raciocínio, não pelo nome do nível

O nome é rótulo, o comportamento é o que tu mede 😛

O que eu vi na prática usando o Sonnet 5

Eu também entrei nessa desconfiança de nerf silencioso, já aconteceu de sair versão nova e parecer que piorou

É por isso que eu refaço os testes a cada lançamento, em vez de confiar no post de anúncio

No teste eu criei três projetos do zero no Claude Code, rodando os três em paralelo pra acelerar: um quadro Kanban em React, um encurtador de URLs full stack e um jogo estilo Pac-Man em HTML5 Canvas

No Kanban apostei em prompt único (one shot), com todos os requisitos juntos, justamente pra ver se ele aguentava planejar tudo de uma vez sem perder funcionalidade: colunas por categoria, cards reordenáveis, arraste horizontal, contador de cards por coluna e limite configurável

Ficou pronto em cerca de 10 minutos, e na validação manual eu conferi mover colunas, mover tarefas, persistência, alteração de categoria, filtro, busca e exportação em JSON

O layout saiu de primeira, com todas as funcionalidades pedidas

No encurtador eu fiz o oposto do one shot: avisei logo no primeiro prompt que os requisitos viriam em etapas e exigi consistência de nomes, arquivos, rotas e esquema de banco entre um prompt e outro

Determinei a pasta do projeto dentro do próprio prompt, em vez de deixar o modelo escolher onde escrever

A primeira etapa pediu só o backend, com stack nomeada (Node com Express, Prisma e SQLite), esquema mínimo e estrutura de pastas, proibindo explicitamente criar front-end ali

A segunda pediu o front-end em TypeScript em pasta separada, consumindo a API recém-construída, com as telas listadas uma a uma: login, cadastro, dashboard e detalhe do link

Repara que isso é exatamente o escopo explícito que eu falei lá em cima, escrito no prompt e não deixado pra inferência

Quando eu comecei o segundo projeto, o primeiro já tinha cerca de 8 minutos decorridos e seguia trabalhando

No fim eu fiz cadastro na plataforma, encurtei um link e vi o clique ser registrado na hora

O jogo eu considero o teste mais duro, porque envolve mecânica, animação e física, coisas que aplicação web não exercita

Detalhei o gameplay em vez de pedir "um jogo": labirinto em grid, personagem controlado por WASD e setas, movimento suave entre células, colisão correta nas paredes, pac dots, power-ups, comportamento dos fantasmas perseguidores, estrutura de pastas e regras de execução, tudo em JavaScript puro pra não trazer framework demais pra jogada

Esse levou quase 30 minutos

E aqui está o ponto que interessa pro diagnóstico: tarefa complexa demorar MUITO mais não é sinal de piora

Com raciocínio calibrado pela complexidade, o mesmo modelo que resolve o Kanban em cerca de 10 minutos vai gastar quase 30 no jogo

Se tu mede "qualidade" por velocidade, tu vai confundir tarefa difícil com modelo ruim

Pra mim não houve nerf: parece upgrade real, entregando com qualidade e agilidade as tarefas rotineiras

Eu costumo delegar ao Sonnet justamente o rotineiro e menos crítico, pra economizar token e deixar o Opus pro resto

No vídeo abaixo eu mostro os três projetos rodando do zero, com os prompts na tela

Roteiro de revisão do prompt em 6 passos

Fechando os diagnósticos num checklist executável, na ordem que dá menos retrabalho

1. Rode a migração no código antes de mexer no texto. No Claude Code, /claude-api migrate invoca a skill Claude API embutida, que aplica troca de IDs de modelo e mudanças de parâmetros que quebram ao longo da base de código

/claude-api migrate

O erro comum deste passo: trocar só a string do modelo na mão e achar que acabou, deixando prefill e thinking antigos espalhados esperando pra estourar 400 em produção

2. Reconte os tokens e revise os max_tokens. Com cerca de 30% mais tokens pro mesmo texto, use token counting e olhe todo limite dimensionado perto do tamanho esperado da saída

O erro comum deste passo: revisar só o max_tokens da chamada principal e esquecer dos jobs secundários, que é onde o truncamento passa despercebido

3. Limpe as instruções defensivas herdadas. Sai Default to using <tool>, entra Use <tool> when it would enhance your understanding of the problem

O erro comum deste passo: apagar a instrução inteira em vez de direcionar, e aí a ferramenta para de ser usada quando realmente ajudaria

4. Escreva o escopo de cada instrução. Se a regra vale pra saída toda, diga isso: Apply this formatting to every section, not just the first one

O erro comum deste passo: repetir a mesma instrução três vezes achando que ênfase resolve, quando o que faltava era o escopo

5. Substitua o prefill. As opções documentadas são structured outputs, instruções no system prompt ou output_config.format

O erro comum deste passo: manter o parser antigo, que esperava a resposta já começada pelo assistant, e culpar o modelo pelo JSON "malformado"

6. Faça um sweep novo de effort nos seus evals. Teste low e medium como controle de custo e latência, e max onde capacidade máxima importa mais que gasto de tokens, lembrando que medium no Sonnet 5 é comparável a high no 4.6

O erro comum deste passo: rodar o sweep em dois prompts de brincadeira em vez dos seus casos reais, e sair com uma conclusão que não sobrevive ao primeiro dia em produção

Um detalhe de bolso pra essa faxina toda: mudar o prompt invalida cache de forma hierárquica, seguindo tools → system → messages

Mexeu em um nível, invalida aquele e todos os seguintes

Então agrupe as mudanças em vez de ficar catucando o system prompt de dez em dez minutos

E olho no tamanho: prompts a partir de 512 tokens já criam entrada de cache (antes eram 1.024 tokens no Claude Opus 4.8)

Ah, e se o seu fluxo dependia das APIs experimentais de prompt tools (gerar, melhorar e templatizar prompts), elas são aposentadas junto com o Workbench em 17/08/2026

Conclusão

Quando a qualidade cai logo depois de trocar de versão, a hipótese mais provável não é modelo pior, é prompt calibrado pra versão anterior

Resposta com tamanho estranho, regra aplicada só no primeiro item, ferramenta disparando demais, erro 400 no formato, saída truncada e effort herdado: são seis causas diferentes, cada uma com correção própria

Nenhuma delas se resolve escrevendo "por favor capriche" no fim do prompt, essas coisas toscas não existem

O próximo passo é ler a página oficial Prompting Claude Sonnet 5 na documentação da plataforma e rodar o sweep de effort nos SEUS casos antes de bater o martelo sobre o modelo

E guarda o hábito: toda vez que sair versão nova, refaz o teste em vez de confiar na sensação

A sensação erra bastante, o eval não 🙂

até o próximo post!