Por que o Claude responde diferente para o mesmo pedido feito duas vezes?

Fala aí, beleza? Você colou o MESMO prompt duas vezes e o Claude devolveu duas respostas diferentes

Aí bate a dúvida: quebrou alguma coisa? A conta tá com problema? O modelo piorou hoje?

Nada disso

A resposta pra por que o Claude responde diferente é chata de aceitar e ótima de entender: variação é comportamento esperado de um modelo de linguagem, não defeito. Quem já apanhou de useEffect chamando duas vezes conhece bem a sensação de achar que é bug quando na verdade é comportamento previsto

O que muda o jogo é saber QUAIS partes dessa oscilação você controla, quais você não controla e em que hora ela joga a favor

Bora destrinchar isso?

As causas reais da variação (e o que fazer com cada uma)

O sintoma é sempre o mesmo: pedido igual, saída diferente

Só que ele tem origens distintas, e cada uma pede uma reação diferente

Causa 1: a amostragem, o tal do temperature

A Messages API tem um parâmetro chamado temperature, que controla a aleatoriedade da resposta

Ele aceita valores de 0.0 a 1.0 e o padrão é 1.0. A orientação da documentação é ficar mais perto de 0.0 em tarefas analíticas e mais perto de 1.0 em tarefas criativas

Traduzindo: no padrão, o modelo tá configurado pro lado mais solto da régua. Duas rodadas do mesmo pedido não têm por que sair idênticas

Como prevenir: essa alavanca existe na API, e mesmo lá ela tá sumindo nos modelos novos (falo disso na próxima seção). Então não conte com ela como plano A

Formação Recomendada

Formação Claude Code

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

• 120 aulas
• 4 projetos
• 9h 45min

Conhecer formação

Causa 2: nem em 0.0 o resultado é 100% determinístico

Essa aqui é a parte que a galera não sabe

A própria documentação da Anthropic afirma que, mesmo com temperature em 0.0, o resultado NÃO é totalmente determinístico: entradas idênticas podem produzir saídas diferentes entre chamadas de API

E vale tanto pra inferência da própria Anthropic quanto via provedores de nuvem terceiros

Como prevenir: não previne, e prometer determinismo total aqui seria mentira. O que dá pra fazer é reduzir a MARGEM: quanto menos espaço o pedido deixa, menos essa variação residual aparece no resultado final

Causa 3: o pedido deixou margem larga

Essa é a causa que mais pesa no dia a dia, e é 100% sua

"Cria uma landing page bonita" tem umas mil saídas válidas. "Extrai o CNPJ desse texto e devolve só os números" tem uma

Quanto mais interpretação você delega, mais o resultado balança entre rodadas

Como prevenir: clareza e formato explícito, que é o assunto da seção de passos mais abaixo

Causa 4: o contexto não era o mesmo

Aqui mora o falso positivo clássico

Você acha que repetiu o pedido, mas repetiu em outra sessão, com outro histórico, com outro conjunto de instruções carregado

O pedido é igual, o CONTEXTO não é. E o contexto faz parte da entrada

Como prevenir: garantir que as duas rodadas partam do mesmo estado. No Claude Code isso tem nome e comando, e eu mostro na seção específica

Nos modelos mais novos você não ajusta mais temperature

Se você tava contando com o temperature pra travar a saída, tenho uma notícia

Nos modelos Claude 4.7 e posteriores (e no Claude Mythos Preview), os parâmetros de amostragem temperature, top_p e top_k não são mais suportados

Mandar valor diferente do padrão devolve erro 400. A orientação oficial é omitir os campos e guiar o comportamento por prompt

Se liga nas regras que continuam valendo na API pra quem ainda usa esses parâmetros:

• temperature e top_p não podem ser especificados na mesma requisição: a recomendação é alterar um OU outro, e mandar os dois gera erro temperature and top_p cannot both be specified
• com extended thinking ligado, temperature precisa ficar em 1 (ou não ser definido) em todos os modelos
• extended thinking também é incompatível com modificação de top_k e com uso forçado de ferramenta

E o que sobrou de controle explícito? O effort

Ele é o parâmetro de profundidade de raciocínio hoje, com cinco níveis: low, medium, high (padrão), xhigh e max

É suportado por Claude Fable 5, Claude Mythos 5, Claude Opus 4.8, Claude Mythos Preview, Claude Opus 4.7, Claude Opus 4.6, Claude Sonnet 4.6 e Claude Opus 4.5. Detalhe: alguns modelos que suportam max não suportam xhigh

No Claude Opus 4.8 o effort tem padrão high em todas as superfícies, incluindo a API, o Claude Code e o claude.ai

A conclusão prática é meio poética: o botão virou o texto do pedido

Quem quer saída estável hoje não mexe em dial, escreve melhor 😀

Como escrever o pedido para reduzir a oscilação

Beleza, então vamos pro que tá sob seu controle

São cinco movimentos, do mais barato pro mais técnico

1. Aplique o teste do colega sem contexto. A regra de ouro do prompt claro, segundo a documentação, é mostrar o prompt pra um colega com pouco contexto: se ele ficar confuso, o Claude também vai ficar. E vale ser específico e prescritivo sobre COMO começar a resposta

O erro comum deste passo: achar que o modelo sabe o que tá na sua cabeça. Aquilo que você "deixou subentendido" é exatamente a fresta por onde a variação entra

2. Separe as partes do prompt com tags XML. A documentação recomenda usar tags pra separar instruções, contexto, exemplos e entrada variável, com nomes tipo <instructions>, <context>, <input>, <examples>, <thinking> e <answer>

A parte que quase todo mundo pula: usar os MESMOS nomes de tag entre prompts e se referir a eles no texto da instrução

<instructions>
Resuma o conteúdo de <input> em 3 bullets
Cada bullet com no máximo 15 palavras
Siga o padrão de <examples>
</instructions>

<context>
Público: devs que estão começando com IA
</context>

<examples>
- Bullet de exemplo no formato exato esperado
</examples>

<input>
(aqui entra o texto que muda a cada rodada)
</input>

O erro comum deste passo: misturar a entrada variável no meio da instrução. Aí o modelo tem que adivinhar onde termina a ordem e onde começa o dado

3. Dê de 2 a 5 exemplos. A documentação de multishot recomenda incluir de 2 a 5 exemplos diversos e representativos, todos no mesmo padrão de formatação e rotulagem. Qualidade importa mais que quantidade

O erro comum deste passo: escrever exemplos cada um de um jeito. Se o SEU padrão oscila, adivinha o que a saída faz

4. Use o prefill da resposta. Existe o recurso de prefill da resposta do Claude justamente pra maior controle da saída

É o equivalente a já deixar a primeira linha escrita pro modelo continuar em vez de escolher por onde entrar

5. Se o consumo é por máquina, restrinja a saída de verdade. Os structured outputs estão disponíveis de forma geral na API do Claude e funcionam compilando o JSON Schema em uma gramática que restringe a saída do modelo

Estão em GA pra Claude Mythos Preview, Claude Opus 4.7, Claude Opus 4.6, Claude Sonnet 4.6, Claude Sonnet 4.5, Claude Opus 4.5 e Claude Haiku 4.5

Detalhes que importam na migração: o parâmetro output_format passou a ser output_config.format, o header beta não é mais exigido (o antigo segue funcionando por um período de transição) e as gramáticas compiladas ficam em cache por 24 horas desde o último uso

Tem ainda o strict tool use, com strict: true, que garante validação de schema em nomes e inputs de ferramentas, e dá pra combinar com structured outputs na mesma requisição

O erro comum deste passo: pedir "me devolve um JSON" no texto e rezar. Se código vai consumir a saída, restringe a saída, não pede com jeitinho 🙂

A Anthropic mantém uma página de documentação dedicada só a isso, a Increase output consistency, que vale a leitura de ponta a ponta

No Claude Code: o que estabiliza o comportamento entre sessões

No Claude Code a variação que mais incomoda quase nunca é do modelo

É sessão nova sem as mesmas instruções carregadas, e a gente culpa o coitado do modelo

1. Coloque a regra no CLAUDE.md. Que arquivo é esse? É o arquivo de memória do projeto, aquele que guarda as instruções que você quer valendo SEMPRE, em vez de repetir a cada conversa

Ele é lido no início de toda sessão. E tem um detalhe ótimo: o CLAUDE.md da raiz do projeto sobrevive à compactação, sendo relido do disco e reinjetado na sessão depois do /compact

Ou seja: instrução no chat some quando o histórico é compactado, instrução no CLAUDE.md da raiz volta pra sessão sozinha

O erro comum deste passo: dar a instrução no chat, compactar, e depois estranhar que o comportamento mudou no meio da sessão

2. Não escreva um calhamaço. Arquivos de memória muito longos consomem mais contexto e podem reduzir a aderência às instruções: acima de 200 linhas o arquivo já pesa nessa conta

O erro comum deste passo: achar que mais regra é mais controle. Passou do ponto, o efeito inverte

3. Use escopo por caminho. Regras com escopo por caminho carregam instruções só para os arquivos correspondentes, em vez de despejar tudo em toda sessão

4. Recomece limpo quando for comparar duas rodadas. Esse é o tal comando que eu prometi lá em cima: o /clear devolve uma janela limitada sem custo de inferência

Com o /clear antes de cada rodada, as duas partem do mesmo estado, e aí sim dá pra dizer que o pedido foi "o mesmo"

O erro comum deste passo: comparar uma resposta do começo da sessão com outra depois de um monte de idas e vindas no chat e chamar isso de "mesmo pedido"

5. Saiba o que tá carregado. O comando /memory abre a pasta de memória automática, e o /config abre a interface de configurações da sessão, incluindo a escolha de modelo

O erro comum deste passo: rodar o teste em modelos diferentes sem perceber e atribuir a diferença à sorte

Juntando os cinco: regra no CLAUDE.md da raiz pro que precisa valer sempre, arquivo curto e com escopo, /clear pra zerar a comparação e /memory mais /config pra saber exatamente o que tá em jogo

O que aconteceu quando repetimos os pedidos no teste do Opus 4.5

Agora a parte prática, com material meu mesmo

No vídeo do teste completo do Claude Opus 4.5, eu fui atrás de cenários fora do padrãozinho de demo justamente pra ver o quanto o modelo sustenta o pedido. Testei até SVG de cidade e lua, que é o tipo de coisa que não tá no exemplo pronto de ninguém

O placar de prompts ficou assim:

• cidade 3D navegável: 1 prompt
• simulador de dominós com física: 3 prompts, com erros no caminho, até ficar do jeito que eu queria
• JRPG estilo Final Fantasy: 2 prompts e resultado que eu considerei ruim, com batalha que não terminava e controles trocados

Teve também o capítulo das falhas de geração

Os prompts muito elaborados falhavam repetidamente, sem devolver resposta, e a tentativa perdida ainda comia o meu limite de uso (bati no limite várias vezes ao longo do dia e tive que esperar a janela liberar 😛)

Quando eu encurtei o pedido e reescrevi o mesmo prompt em inglês, sobrou 1 falha e a geração passou

E teve o caso que mais me pegou: rodei o mesmo prompt de página de portfólio no Claude e no Gemini e vieram propostas visualmente MUITO diferentes, uma mais ousada e com acabamento irregular, outra mais contida e encaixada

Não dava pra eleger vencedor: eram propostas diferentes, não versões melhores ou piores da mesma coisa

Isso me surpreendeu, porque na minha experiência prompts parecidos costumam devolver resultados parecidos

A leitura honesta de tudo isso: a variação não é aleatoriedade pura. Ela CRESCE onde o pedido deixa espaço, e refazer faz parte do processo. Por isso eu insisto que cada um teste por conta própria, em cenários variados, em vez de confiar só em gráfico bonito

Quando a variação é exatamente o que você quer

Se liga nisso, porque tem uma armadilha aqui

Tem gente gastando energia pra travar a saída em tarefa que só melhora com variação

Onde a oscilação joga a favor:

• gerar várias opções de título, nome, headline ou texto e escolher a melhor
• explorar abordagens de arquitetura ou de solução ANTES de decidir qual seguir
• destravar um resultado empacado rodando de novo, em vez de reescrever tudo do zero
• brainstorm e variações criativas, onde a resposta "certa" nem existe

E onde ela é problema mesmo:

A regra é simples: quando a saída é lida por gente, variação é opção. Quando é lida por código, você restringe a saída em vez de esperar sorte

Conclusão

Recapitulando o que interessa

A oscilação entre respostas é característica do modelo, não defeito da sua conta: a documentação da Anthropic é explícita ao dizer que nem em temperature 0.0 o resultado é totalmente determinístico

E o controle mudou de lugar: em Claude 4.7 e posteriores os parâmetros de amostragem nem são mais suportados, com erro 400 pra valor fora do padrão e orientação de guiar por prompt. Sobrou o effort pra profundidade de raciocínio, com high como padrão

No Claude Code, o que estabiliza é o contexto: regra no CLAUDE.md da raiz (que volta pra sessão depois do /compact) e /clear antes de comparar duas rodadas

Seu próximo passo é bem concreto: pega UM prompt que você repete toda semana, aplica o teste do colega sem contexto, separa instrução, contexto, exemplos e entrada em tags e coloca de 2 a 5 exemplos no mesmo padrão de formatação

Só isso já derruba boa parte da variação que te irrita

Ah, e se você ainda aponta pra um modelo antigo: o Claude Opus 4.1 foi aposentado em 5 de agosto de 2026, com migração recomendada pro Claude Opus 4.8. Vale conferir onde seu código tá apontando antes de culpar a variação por algo que é só modelo velho…

Faça o teste e me conta como foi, até o próximo post! 😀