Corrija um bloco de pensamento vinculado a uma conversa diferente

Enviar a mesma requisição novamente não pode funcionar, porque seu histórico ainda contém o que seu código alterou. Envie "drop_block" para interromper os erros agora. A correção de longo prazo é tornar seu código append-only (somente acréscimo).

Erro: The block is bound to a different conversation

O “thinking block” (bloco de pensamento) falhou na “prefix check” (verificação de prefixo): algo antes dele foi alterado depois que Claude o produziu (consulte O que conta como uma mudança), ou um bloco de pensamento entre outros foi omitido ou movido. O erro tem esta aparência e pode continuar para nomear o que foi alterado:

messages.1.content.0: Invalid `signature` in `thinking` block. The block is bound to a different conversation. Remove the block, or set `thinking.block_binding.prefix_mismatch_behavior` to "drop_block".

“A different conversation” significa conteúdo diferente antes do bloco: a verificação de prefixo não compara sessões nem usuários. A mensagem de erro diz para remover o bloco, mas remover apenas esse bloco não é suficiente. Outros erros podem parecer semelhantes.

Se o aplicativo não for seu, inicie uma nova conversa e avise o mantenedor dele. Se você removeu um segredo, dados pessoais ou texto injetado, ou se suas requisições desativam o pensamento, remova o pensamento manualmente em vez de seguir a etapa 1.

1. 1

   Interromper os erros agora

   Defina thinking.block_binding.prefix_mismatch_behavior como "drop_block" e envie o cabeçalho beta anthropic-beta: thinking-binding-controls-2026-08-01. Faça isso em todas as requisições posteriores da conversa, porque a API não armazena a configuração entre requisições. Uma conversa salva ainda contém a alteração, mesmo depois que você corrigir seu código, então armazene a configuração junto com ela. Defina type como "adaptive", conforme mostrado:

   {
     "thinking": {
       "type": "adaptive",
       "block_binding": {
         "prefix_mismatch_behavior": "drop_block"
       }
     }
   }

   

   No SDK, chame o método beta de Messages e passe o valor do cabeçalho, como faz o programa de teste. Se o erro ainda pedir o cabeçalho, o cabeçalho não chegou.

   Isso interrompe os erros descartando o pensamento inválido, mas pode custar mais e pode afetar a qualidade da saída e a latência. A próxima requisição é bem-sucedida, e seu array input_transformations lista cada bloco que a API descartou.

   Se suas requisições não definem o parâmetro thinking, adicioná-lo não altera mais nada, porque modelos com pensamento preservado pensam de forma adaptativa por padrão.

2. 2

   Correção de longo prazo

   Torne sua integração append-only:

   1. Encontre a alteração. O erro pode nomeá-la. Para encontrar onde seu código a faz, execute claude update e, em seguida, execute /claude-api preserved-thinking-migration no Claude Code, no repositório do seu código. Ou procure manualmente.
   2. Pare de fazer a alteração, ou novas conversas também podem receber o erro. Envie uma atualização no final em vez disso.
   3. Continue enviando a cada conversa em andamento o system e as tools de sua última requisição bem-sucedida.

Se a alteração foi recente, você pode desfazê-la em vez disso: restaure o que seu código alterou. O pensamento de antes da alteração volta a ser válido. O pensamento produzido desde então falha, então remova-o ou continue enviando "drop_block".

Quanto custa descartar pensamento

Claude pode gastar mais tokens de saída elaborando um raciocínio que não consegue mais ler. Descartar os blocos também invalida o “prompt cache” (cache de prompt) a partir do primeiro bloco descartado.

Quando algo muda a cada turno, cada turno perde o pensamento dos turnos anteriores, então o aumento se repete. Execute avaliações na sua própria carga de trabalho antes de depender de "drop_block".

Use "drop_block" para manter conversas existentes em andamento enquanto elas contêm uma alteração que você está corrigindo, e para um descarte planejado, como após seu próprio resumo. Não o deixe ativado para esconder uma alteração que seu código continua fazendo. Você pode parar de enviá-lo assim que os blocos inválidos estiverem fora do histórico.

Encontre o que seu código alterou

A alteração está antes do primeiro bloco que a API nomeia. O erro 400 pode dizer o que foi alterado, como system, tools, um bloco de pensamento ausente ou a primeira mensagem que difere. Sem erro, ou com um que não diz, comece pelo que você tem, como uma entrada prefix_binding_mismatch ou mais tokens de saída.

Teste seu código para falhas na verificação de prefixo

Você pode confiar em um teste depois de vê-lo falhar. Primeiro, por meio do seu próprio código, execute uma sessão que faça Claude pensar e altere algo de propósito. Envie "drop_block" nesta etapa, para que a resposta liste todos os blocos inválidos em vez de parar no primeiro, como mostram cinco etapas e um programa.

Em seguida, remova essa alteração e execute suas sessões reais. Em cada requisição, envie o cabeçalho beta thinking-binding-controls-2026-08-01 e defina prefix_mismatch_behavior como "error", para que uma alteração que seu código faça nessas sessões faça o build falhar com o erro 400.

Teste sessões que compactam, adicionam ferramentas tardiamente, alteram instruções, trocam de modelo ou são retomadas: turnos simples não chegam a esse código.

Uma execução limpa não tem nenhuma entrada prefix_binding_mismatch e nenhum erro. Ela mostra apenas que os blocos que verificou são válidos, nas sessões que você executou. Ela não prova nada se:

• a sessão não tinha blocos de pensamento
• seu código remove todo o pensamento, ou o modelo não tem pensamento preservado
• você não enviou o cabeçalho beta, e o modelo pode deixar passar blocos que falharam sem um erro

Monitore a produção e encontre raciocínio perdido sem erro

Registre cada erro 400 e trate-o no código para que a conversa continue. Se, em vez disso, você deixar prefix_mismatch_behavior não definido, monitore o tráfego de produção em busca de pensamento que falhou na verificação de prefixo e chegou a Claude.

O raciocínio pode ser perdido sem erro por meio de "drop_block", um item de lote, uma troca de modelo, uma mudança para outra conta ou um código que não envia nenhum pensamento de volta. Com o cabeçalho beta, cada um deixa uma entrada, exceto o último. Para esse, verifique se suas requisições contêm blocos thinking.

Detalhes técnicos

O que mais a mensagem de erro pode dizer

A mensagem de erro continua nomeando o que foi alterado, quando a API consegue identificar, como system, tools, a primeira mensagem ou bloco que difere, conteúdo ausente ou novo, ou um bloco de pensamento anterior ausente ou fora de ordem. A redação dessa frase pode mudar, então não faça correspondência com ela. Se a requisição não tinha cabeçalho beta, a mensagem de erro adiciona esta frase:

That setting requires the `thinking-binding-controls-2026-08-01` value in the `anthropic-beta` header.

O erro ainda pede o cabeçalho ou diz Extra inputs are not permitted

Se o erro ainda pede o cabeçalho, o cabeçalho não chegou à API: um proxy ou biblioteca pode tê-lo removido. Um erro diferente, terminando em block_binding: Extra inputs are not permitted, significa o mesmo, ou que o pensamento está desativado.

Remova o pensamento inválido manualmente

Use isto onde você não pode enviar a configuração, ou em um destes casos:

• Depois de remover um segredo, dados pessoais ou texto injetado, porque "drop_block" deixa o pensamento no seu histórico armazenado.
• Quando o pensamento está desativado ("disabled" ou "between_tools"), porque "drop_block" requer "adaptive", o que ativaria o pensamento e adicionaria tokens de saída.

1. Remova o bloco que o erro nomeia e todos os blocos thinking e redacted_thinking depois dele, ou o mesmo erro então nomeia o próximo inválido. Mas se seu histórico contém mensagens role: "system", ou duas mensagens do mesmo papel seguidas, remova todos os blocos thinking e redacted_thinking. O erro conta tal mensagem como parte da mensagem anterior, então a posição que ele nomeia pode ser menor que o índice no seu array. O path de uma entrada input_transformations conta cada mensagem separadamente.
2. Mantenha todos os outros blocos e envie a requisição novamente. Não coloque de volta os blocos removidos.

Erros parecidos com este

Estes erros não dizem que o bloco está vinculado a uma conversa diferente, e definir prefix_mismatch_behavior pode não resolvê-los:

• Uma mensagem que termina após “Invalid signature in thinking block”, diz “cannot be modified” ou trata de budget_tokens: Solução de problemas do pensamento
• Uma mensagem sobre temperature ou uma resposta pré-preenchida: Limites e compatibilidade de recursos

Quando você pode parar de enviar "drop_block"

Para parar de enviar "drop_block", remova os blocos que ele descarta e mantenha o pensamento produzido desde então. Se nada mais tiver mudado, a conversa então passa com "error".

Trate o erro no código

Para tratar o erro no código, envie o cabeçalho beta e "error" em cada requisição, para que uma falha seja um erro 400 em todos os modelos. Quando ele ocorrer, mude apenas essa conversa para "drop_block" em todas as requisições posteriores, armazene essa escolha junto com ela, envie novamente uma vez e registre o erro. Se o mesmo erro voltar, a configuração não chegou à API: consulte O erro ainda pede o cabeçalho ou diz Extra inputs are not permitted.

Seu código precisa reconhecer este erro pelo campo message, a exceção ao conselho geral de não fazer correspondência com o texto de um erro. Todo erro 400 tem o tipo invalid_request_error, e este não tem error.details.error_code. Faça correspondência apenas com “The block is bound to a different conversation”, porque o restante da mensagem pode mudar.

Você não tem erro, ou tem um que não diz o que foi alterado

• O erro 400, e ele não nomeia nenhuma alteração: Compare as requisições você mesmo. Uma causa é um bloco de compactação enviado sem remover as mensagens que ele resume.

• Uma entrada prefix_binding_mismatch: Compare system, tools e messages até o path da primeira entrada com a conversa como estava quando esse bloco foi produzido. Se todos os blocos estiverem listados, comece por system e tools.

  Se nada diferir, procure uma URL de imagem ou documento cujo conteúdo mudou, uma lista de ferramentas alterada de um servidor MCP (consulte Fixe a lista de ferramentas de um servidor MCP), ou um bloco de pensamento omitido, movido ou colocado de volta. Sem logs de requisições, envie a requisição novamente com "error" e leia a frase que diz o que difere, se houver uma.

• Um proxy ou biblioteca que não é seu, no meio do caminho: Compare o que ele envia com o que você enviou e indique ao mantenedor dele Bibliotecas, proxies e gateways.

• Apenas uma suspeita, e sem Claude Code: Capture os corpos das requisições de uma conversa, uma com uma compactação ou uma alteração de ferramentas. Compare cada um com o anterior, deixando de fora seus novos turnos.

Cinco etapas para um teste que pode falhar e um programa que as executa

1. No seu próprio código, envie o cabeçalho beta e "drop_block" em cada requisição de uma sessão, para um modelo com pensamento preservado.
2. Use prompts que façam Claude pensar e verifique se a primeira resposta tem um bloco thinking. Com o pensamento adaptativo, Claude pode pular o pensamento em um prompt fácil.
3. Falhe apenas em uma entrada input_transformations cujo motivo seja prefix_binding_mismatch. Um teste que espera um array vazio também falha após uma troca de modelo, porque entradas com model_binding_mismatch ou organization_binding_mismatch são esperadas nesse caso.
4. Altere algo de propósito, como adicionar um prompt system apenas na terceira requisição.
5. Verifique se input_transformations lista os blocos de pensamento que ficam depois da alteração. Se não listar nenhum, verifique se o histórico contém um bloco de pensamento.

Este programa executa as etapas 1, 2, 4 e 5. Ele imprime quantos blocos de pensamento e entradas input_transformations cada resposta tem e, em seguida, cada entrada, que é o que a etapa 3 verifica:

client = anthropic.Anthropic()

user_turns = [
    "How many positive integers below 500 have exactly 6 positive divisors?",
    "How many have exactly 8?",
    "How many have exactly 10?",
]

messages = []
for turn, user_turn in enumerate(user_turns, start=1):
    messages.append({"role": "user", "content": user_turn})
    response = client.beta.messages.create(
        model="claude-opus-5-5",
        max_tokens=16000,
        thinking={
            "type": "adaptive",
            "block_binding": {"prefix_mismatch_behavior": "drop_block"},
        },
        # Apenas a última requisição adiciona um prompt do sistema, o que altera o prefixo de propósito
        system="Answer briefly." if turn == len(user_turns) else anthropic.omit,
        messages=messages,
        betas=["thinking-binding-controls-2026-08-01"],
    )
    messages.append({"role": "assistant", "content": response.content})
    thinking_blocks = sum(block.type == "thinking" for block in response.content)
    entries = response.input_transformations or []
    print(f"thinking blocks: {thinking_blocks}, entries: {len(entries)}")
    for entry in entries:
        if entry.type == "thinking_dropped":
            print(entry.type, entry.path, entry.reason)

thinking blocks: 1, entries: 0
thinking blocks: 1, entries: 0
thinking blocks: 1, entries: 2
thinking_dropped messages.1.content.0 prefix_binding_mismatch
thinking_dropped messages.3.content.0 prefix_binding_mismatch

Com "error" no lugar de "drop_block", a terceira requisição recebe o erro 400.

O que cada entrada input_transformations significa e quais cabe a você corrigir

Com o cabeçalho beta, uma resposta de um modelo que suporta pensamento tem o array input_transformations ao lado de usage. Ele fica vazio quando nada foi descartado e nada inválido passou. Quando você faz streaming, ele está na message do evento message_start; após um fallback no meio do stream, o evento message_delta final traz o que vale. Diferentemente da posição do erro, path é sempre o lugar do bloco como você o enviou:

{
  "input_transformations": [
    {
      "type": "thinking_dropped",
      "path": "messages.1.content.0",
      "reason": "prefix_binding_mismatch"
    }
  ]
}

O type e o reason de cada entrada, e o que significam:

• thinking_dropped, prefix_binding_mismatch: O que veio antes deste bloco não é o que ele registrou. Cabe a você corrigir: Encontre o que seu código alterou.
• thinking_mismatch_allowed, prefix_binding_mismatch: O mesmo, mas Claude leu o bloco sem alterações, e ele é cobrado. Esta entrada aparece apenas onde a configuração não é definida, em alguns modelos. Cabe a você corrigir.
• thinking_dropped, model_binding_mismatch: Este modelo não consegue ler blocos do modelo que o produziu. Não cabe a você corrigir: continue enviando a conversa inteira.
• thinking_dropped, organization_binding_mismatch: Outra conta produziu o bloco, então a API o descartou. Não cabe a você corrigir.

Ignore uma entrada cujo type ou reason você não reconhece.

Lotes e contagem de tokens

• Lotes de Mensagens: Um item que deixa prefix_mismatch_behavior não definido nunca recebe o erro 400. A API descarta os blocos inválidos ou, em alguns modelos, pode deixá-los passar. Um item que define "error" é resolvido como errored quando um bloco falha na verificação de prefixo. block_binding vai em params.thinking do item.
• Contagem de tokens: Na Claude API, a contagem de tokens pode retornar o mesmo erro 400 e aceita prefix_mismatch_behavior com o mesmo cabeçalho. Ela deixa os blocos descartados fora da contagem e não retorna input_transformations.

Próximos passos