Por que o Claude Opus dá respostas diferentes para o mesmo prompt?

Claude Opus respostas diferentes para o mesmo prompt
Resposta rápida

Claude Opus dá respostas diferentes para o mesmo prompt porque a inferência não é determinística: a documentação da Anthropic afirma que, mesmo com temperature 0, os resultados não são totalmente determinísticos e entradas idênticas podem gerar saídas diferentes entre chamadas de API, tanto no serviço da própria Anthropic quanto em provedores terceiros. Dá pra reduzir o estrago onde importa: Structured Outputs com json_schema, formato explícito com exemplos e strict: true nas ferramentas travam a forma da saída. No Claude Opus 5, mexer em temperature, top_p ou top_k fora do padrão retorna erro 400, então o controle mudou de lugar

Fala aí, beleza? Você roda o mesmo prompt duas vezes, mesmo modelo, mesmo contexto, e recebe duas respostas diferentes

Isso não é bug e nem prompt mal escrito

A própria documentação da Anthropic diz o seguinte: mesmo com temperature 0, os resultados não são totalmente determinísticos e entradas idênticas podem gerar saídas diferentes entre chamadas de API. E isso vale tanto para o serviço de inferência da própria Anthropic quanto para a inferência via provedores de nuvem terceiros

Ou seja: a pergunta certa não é "como faço o modelo parar de variar"

É "o que eu consigo travar e o que eu tenho que aceitar"…

De onde vem a variação entre execuções idênticas

A explicação técnica mais completa que existe hoje veio da Thinking Machines Lab

Eles apontaram a causa raiz da não determinismo na inferência de LLM: a falta de invariância de batch em kernels de normalização (RMSNorm), multiplicação de matrizes e atenção

Formação Claude Code
Formação Recomendada

Formação Claude Code

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

  • 114 aulas
  • 4 projetos
  • 9h 18min

Traduzindo pro português de gente: o servidor agrupa as requisições em batches diferentes conforme a carga do momento

Se você mandou o mesmo prompt às 10h e às 15h, o seu pedido caiu num agrupamento diferente, e isso muda o caminho numérico do cálculo

E aí? Aí em ponto flutuante o caminho importa, porque somar as mesmas parcelas em ordem diferente pode mudar o último dígito do resultado

Um dígito muda a probabilidade de um token, o token muda a frase, a frase muda o parágrafo inteiro. Efeito dominó, e olha que a gente ainda vai falar de dominó mais pra frente aqui 😄

Dá pra provar que é isso mesmo?

Dá, e eles provaram

A Thinking Machines publicou uma biblioteca com implementações batch-invariant, a batch_invariant_ops, e uma demonstração rodando em vLLM em que 1.000 execuções idênticas produziram 1.000 saídas idênticas

O preço disso não é de graça: o caminho determinístico não otimizado que eles mediram ficou aproximadamente 2x mais lento em uma única GPU com o Qwen 3 8B

Tome cuidado com a conclusão apressada aqui: o trabalho deles é sobre inferência de LLM em geral, e a demonstração foi feita em vLLM

A Anthropic não detalha publicamente a stack que ela usa pra servir os modelos, então isso é a melhor explicação disponível do fenômeno, não um raio-x da infraestrutura dela

O que mudou no Claude Opus 5 para quem tenta travar a saída

O Claude Opus 5 é o modelo Opus mais recente da Anthropic, anunciado e disponibilizado em 24 de julho de 2026

E ele mexeu justamente na gaveta onde todo mundo ia procurar determinismo: os parâmetros de amostragem

  • definir temperature, top_p ou top_k com valor diferente do padrão retorna erro 400
  • a orientação oficial é remover esses parâmetros e guiar o comportamento por instruções no system prompt
  • o prefill da resposta do assistente, aquela técnica clássica de começar a resposta pelo modelo pra forçar formato, não é suportado a partir do Claude 4.6 (nem no Claude Mythos Preview), e a recomendação é usar structured outputs ou system prompt no lugar

Se você tem um script antigo que setava temperature: 0 religiosamente, ele simplesmente para de funcionar

E, sendo honesto, ele nunca te deu determinismo mesmo: só te dava a sensação

E o thinking, entra nessa história?

Entra, e é bom saber

O Claude Opus 5 roda com thinking ligado por padrão, e o próprio modelo decide quando e quanto pensar a cada turno

O controle da profundidade é o parâmetro effort, que tem cinco níveis: low, medium, high, xhigh e max, com high como padrão

E tem uma pegadinha: desligar o thinking (thinking: {"type": "disabled"}) nos níveis xhigh ou max retorna erro 400

Então o raciocínio adaptativo é mais uma camada que muda de execução pra execução, e ela não é uma chavinha que você desliga pra tudo ficar previsível

Três sintomas de saída inconsistente e como resolver cada um

Agora a parte prática. Cada sintoma abaixo tem uma causa e uma solução que ataca a forma da saída, que é o que dá pra travar de verdade

1. O JSON às vezes vem quebrado ou com campo faltando

Sintoma clássico de quem automatiza: 9 execuções passam liso e a décima vem com uma vírgula sobrando, ou com o modelo escrevendo "Claro! Aqui está o JSON:" antes do objeto

Causa: você está pedindo JSON por texto, e texto varia

Solução: Structured Outputs, que estão em disponibilidade geral na Claude API desde 29 de janeiro de 2026

O Claude Opus 5 suporta o recurso via output_config, com o formato json_schema. O parâmetro antigo output_format continua funcional, porém está depreciado, então vale já migrar quem ainda usa ele

A documentação oficial recomenda exatamente isso: quando você precisa de JSON válido conforme um schema, use Structured Outputs em vez de tentar resolver por prompt

O erro comum aqui: ficar reescrevendo a instrução ("responda APENAS com JSON, sem texto antes ou depois, JURO") achando que é falta de ênfase. Não é. É camada errada

2. O formato do texto muda de execução pra execução

Uma hora vem em bullets, outra hora vem em parágrafo, outra hora vem com um título que você não pediu

Causa: o formato ficou implícito no prompt, e o que é implícito o modelo preenche do jeito dele

Solução: definir o formato com precisão (JSON, XML ou um template) e fornecer de 3 a 5 exemplos do resultado desejado

É o mesmo trabalho de transformar uma issue vaga em prompt: tudo que você não especificou, alguém especifica por você, e esse alguém é o modelo

Exemplo vale mais que adjetivo, sempre. "Seja conciso" é opinião, três amostras do tamanho que você quer é especificação

3. A ferramenta é chamada com argumento fora do esperado (ou nem é chamada)

Esse é o que mais dói em agente, porque quebra lá na frente e você só descobre pelo log

Solução: strict: true na definição da ferramenta

Com ele, a Anthropic garante que os inputs da tool sigam o JSON Schema restringindo a amostragem de tokens a saídas válidas (o famoso grammar-constrained sampling)

E se o problema é o modelo simplesmente não chamar a ferramenta, combine com tool_choice do tipo any, que garante que uma das ferramentas será chamada

{
  "tool_choice": { "type": "any" },
  "tools": [
    {
      "name": "salvar_resultado",
      "strict": true
    }
  ]
}

Repara na lógica das três soluções: nenhuma delas tenta fazer o modelo pensar igual duas vezes

Todas restringem o espaço de saídas possíveis, o que é uma briga MUITO mais fácil de ganhar

Prevenção: pare de caçar isso no parâmetro

A regra de bolso é: se a sua tentativa de consertar inconsistência começa com "vou baixar a temperature", provavelmente você está no caminho errado

Onde ainda existe esse controle, a documentação da API de Messages é clara: altere temperature ou top_p, nunca os dois ao mesmo tempo

E no Opus 5, como já vimos, valor não-default nesses parâmetros nem passa: volta 400

Quando vale exigir determinismo e quando aceitar a variação

Aqui é onde muita gente perde tempo: tenta travar tudo, inclusive o que não precisa

Cenário Vale caçar determinismo? Por quê
Avaliação de modelo Sim sem execução reprodutível você não sabe se melhorou o prompt ou se teve sorte
Teste A/B Sim se as duas pernas variam sozinhas, a diferença medida não significa nada
Trecho sensível de produção Sim saída que vira input de outro sistema não pode mudar de forma
Geração criativa e brainstorming Não a variação É o produto aqui
Rascunho e exploração de ideia Não você quer opções diferentes, não a mesma resposta de novo

O custo de tempo do caminho determinístico (aqueles aproximadamente 2x mais lento medidos no Qwen 3 8B com kernel não otimizado) compensa nos três primeiros e é desperdício puro nos dois últimos

E o custo em dinheiro, quando você roda o mesmo prompt em volume?

O Claude Opus 5 custa US$ 5 por milhão de tokens de entrada e US$ 25 por milhão de tokens de saída na Claude Platform

Quem roda avaliação repetida tem duas alavancas citadas no anúncio do modelo: economia de até 90% com cache de prompt e de 50% com processamento em lote

Faz sentido, né? Numa bateria de testes o prompt de sistema é sempre o mesmo, então é exatamente o cenário que o cache foi feito pra atender

A janela também ajuda: são 1M tokens de contexto (padrão e máximo, sem variante menor) e 128k tokens de saída máxima

E vale a pergunta honesta antes de subir tudo pro Opus: nem toda etapa da sua automação precisa do modelo mais caro, e escolher o modelo por tarefa costuma economizar mais que qualquer micro-otimização de prompt

O que a variação parece na prática: o teste com o Opus

Quando testei o Opus 4.5 no vídeo do canal, a variação apareceu do jeito mais concreto possível: na contagem de tentativas

A simulação de dominó com física só ficou boa depois de uns três prompts (por aí, não anotei o número exato), com errinhos no caminho

Já a cidade 3D com veículos e visão tipo street view saiu em um prompt

O SVG da espada e o outro desenho, um prompt cada

A tentativa de JRPG estilo Final Fantasy foram dois prompts, e o resultado ficou pior que o de outro modelo que testei com o mesmo tipo de tarefa: controles e batalha bem inferiores

E teve uma falha de cenário depois que eu encurtei o prompt e passei ele pra inglês

Outra coisa que me marcou: rodei o mesmo prompt de portfólio em dois modelos diferentes esperando resultados parecidos, e vieram duas propostas de página completamente distintas

A do Opus foi mais ousada no design, com fontes grandes, animações e um scroll que ficou estranho. A outra ficou mais encaixadinha e utilizável

A comparação virou inconclusiva, porque não dava pra dizer quem foi melhor: eram propostas diferentes, não versões da mesma coisa

E olha, é isso que a inconsistência faz no seu dia a dia

Não é o modelo trocar uma palavra por um sinônimo. É o número de tentativas até funcionar deixar de ser previsível, e você não conseguir orçar tempo nem uso pra tarefa nenhuma

Inclusive bati no limite de uso várias vezes durante os testes e tive que esperar voltar. Tentei reportar as falhas e não rolou

Se quiser ver as tentativas acontecendo, com os erros no meio e tudo, é só dar play no vídeo acima 😀

Conclusão

O Claude Opus dá respostas diferentes para o mesmo prompt porque a inferência não é determinística, e isso está escrito na documentação da própria Anthropic, inclusive para temperature 0

Não é falha do seu prompt e não é coisa que você conserta com a instrução mágica da vez

O que dá pra fazer é atacar a forma, não o conteúdo: Structured Outputs com json_schema pra JSON, formato explícito com 3 a 5 exemplos pra texto, strict: true mais tool_choice any pra ferramenta

E deixar os parâmetros de amostragem de fora, até porque no Opus 5 eles voltam 400

Próximo passo bem concreto: escolhe UM fluxo automatizado seu que quebra de vez em quando, aquele que te obriga a olhar log de manhã, e migra a saída dele pra Structured Outputs com schema

Um só, hoje. Depois me conta se o log ficou mais quieto

até o próximo post!

Perguntas frequentes

Dá para usar temperature 0 no Claude Opus 5 para tentar travar a resposta?

Não. No Claude Opus 5, definir temperature, top_p ou top_k com valor diferente do padrão retorna erro 400. A orientação oficial é remover esses parâmetros e guiar o comportamento por instruções no system prompt, já que o determinismo por temperature nunca foi garantido de verdade.

Posso ajustar temperature e top_p ao mesmo tempo na API da Claude?

A documentação da API de Messages orienta alterar apenas um dos dois, temperature ou top_p, nunca os dois ao mesmo tempo. Misturar os dois parâmetros torna o comportamento do modelo mais difícil de prever, o oposto do que você quer ao tentar estabilizar a saída.

O prefill ainda funciona para forçar o Claude a responder em um formato específico?

Não a partir do Claude 4.6, o que inclui o Opus 5 e o Claude Mythos Preview: essa técnica de começar a resposta do assistente pelo próprio modelo deixou de ser suportada. A recomendação da Anthropic é usar Structured Outputs ou instruções claras no system prompt no lugar do prefill.

Como evitar que o Claude Opus 5 chame uma ferramenta com o argumento errado?

Definindo strict: true na ferramenta, o que restringe a amostragem de tokens a saídas que seguem exatamente o JSON Schema definido, o famoso grammar-constrained sampling. Combinar isso com tool_choice: {"type": "any"} garante que alguma ferramenta será chamada, tirando boa parte da variação de execução para execução.

É possível ter determinismo total na inferência de um modelo de linguagem?

Tecnicamente sim: a Thinking Machines Lab demonstrou em vLLM que 1.000 execuções idênticas produziram 1.000 saídas idênticas usando kernels batch-invariant. O custo é real, aproximadamente 2x mais lento em uma única GPU no teste com o Qwen 3 8B, e a Anthropic não divulga se usa essa abordagem na própria infraestrutura.

Quanto custa usar o Claude Opus 5 pela API?

O Claude Opus 5 custa US$ 5 por milhão de tokens de entrada e US$ 25 por milhão de tokens de saída na Claude Platform. Dá para reduzir esse custo em até 90% com prompt caching ou até 50% com processamento em lote, o que ajuda bastante quando você roda o mesmo prompt várias vezes só para comparar respostas.




Escrito por | Matheus Battisti

Matheus Battisti
Fundador da Hora de Codar

Programador apaixonado pelo mundo das tecnologias, sempre buscando em aprender e se aprofundar em linguagens, frameworks e o que mais for necessário para executar um bom trabalho. Agora tem uma nova missão que é de passar seu conhecimento adiante para formar novos programadores e especializar mais os que já são.

Subscribe
Notify of
guest

0 Comentários
Oldest
Newest Most Voted

Formações

Formação Vibe Coding

Formação Vibe Coding

Do Prompt ao Produto: Crie Software Real com IA

  • 474 aulas
  • 20 projetos
  • 39h 27min

Blog | Mais populares