Claude Fable 5.1 Pensamento Preservado: Solução para o erro "The Block Is Bound to a Different Conversation"

Se você migrou um agent harness para o Claude Fable 5.1 e começou a receber um erro 400 informando que um bloco de pensamento “está vinculado a uma conversa diferente”, o código provavelmente está editando o histórico entre requisições. O Fable 5.1 é o primeiro modelo Claude que rejeita esse padrão. Este guia mostra o que é a verificação, quando ela se aplica, o que a dispara, como contorná-la e como usar um histórico append-only para preservar o raciocínio e manter o cache de prompt aquecido.

Experimente o Apidog hoje

A verificação está documentada em “pensamento preservado” e em “O que há de novo no Claude Fable 5.1”. Ela é uma das três mudanças importantes do Fable 5.1 e a única que pode degradar silenciosamente um harness. Para as outras duas, consulte o guia de migração.

O erro

messages.5.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". That setting requires the `thinking-binding-controls-2026-08-01` value in the `anthropic-beta` header.

Esse é um erro 400 invalid_request_error, retornado antes de qualquer saída. Repetir a mesma requisição com o mesmo corpo falha novamente.

O caminho (messages.5.content.0) aponta para o primeiro bloco de pensamento que deixou de corresponder. A mensagem pode incluir uma frase adicional indicando a primeira mensagem alterada — esse é o diagnóstico mais útil. O endpoint de contagem de tokens executa a mesma verificação.

Uma falha parecida tem uma causa diferente: se a mensagem não contém a frase “vinculado a uma conversa diferente”, a assinatura pode ter sido adulterada ou estar ilegível. Nesse caso, prefix_mismatch_behavior não se aplica.

Como funciona a verificação

Cada bloco de pensamento do Fable 5.1 contém uma assinatura que registra:

• O modelo que produziu o bloco.
• O prefixo exato da conversa anterior ao bloco:
  • O prompt system de nível superior.
  • O array tools.
  • Cada mensagem anterior.
• O encadeamento com o bloco de pensamento anterior.

Ao reenviar a transcrição, a API compara esse prefixo byte a byte com o prefixo original.

A justificativa declarada pela Anthropic é anti-destilação: contas novas da API não podem editar manualmente o contexto anterior de Claude em uma conversa multi-turno enquanto preservam a transcrição do pensamento. A consequência prática é igualmente importante: as mesmas edições que quebram a verificação também reiniciam o cache de prompt.

A quem a regra se aplica

Imposta por padrão

Contas criadas em ou após 31 de agosto de 2026, incluindo:

• Organizações da API Claude.
• Amazon Bedrock.
• Google Cloud.
• Microsoft Foundry.

Registrada, mas não imposta

Contas criadas antes dessa data. A API registra a inconsistência, mas só a aplica quando a requisição define thinking.block_binding.prefix_mismatch_behavior, inclusive com o valor "error".

A Anthropic afirma que modelos futuros aplicarão a verificação a todas as contas.

Não afetados

A verificação não é executada por:

• Claude Code.
• claude.ai.
• Claude Managed Agents.
• Claude Agent SDK.

Essas superfícies mantêm o prefixo intacto. O Claude Mythos 5.1 também não executa a verificação, embora alterações no histórico ainda reiniciem o cache.

Afetados

Qualquer aplicação que construa o array messages manualmente, como:

• Loops de agentes personalizados.
• Backends de chat.
• Frameworks que encapsulam a API de Mensagens.

Se você distribui uma ferramenta que usa as chaves de API dos usuários, teste com a verificação habilitada. Sua conta pode ser antiga, enquanto a conta de quem usa sua ferramenta pode estar sujeita à imposição.

O que invalida os blocos posteriores

As seguintes alterações quebram a vinculação:

• Editar, reordenar ou remover um turno anterior.
  • Apagar resultados antigos de ferramentas.
  • Remover turnos intermediários.
  • Resumir apenas os turnos antigos e manter os recentes literalmente.
• Injetar conteúdo que não é persistido.
  • Lembretes por turno.
  • Linhas de status.
  • Contagens variáveis de tokens restantes.
• Reconstruir system ou tools entre requisições.
  • Atualizar a data atual no prompt do sistema.
  • Adicionar ou remover uma ferramenta durante a sessão.
• Usar uma URL de imagem ou documento que entregue bytes diferentes posteriormente.
  • A vinculação ocorre pelos bytes, não pela string da URL.
  • Uma URL assinada rotativa para os mesmos bytes é válida.
• Remover um bloco de pensamento que não esteja no início da execução.
  • Blocos iniciais podem ser removidos do mais antigo para o mais recente.
  • Um bloco intermediário não pode ser removido sem invalidar os posteriores.

O que mantém os blocos válidos

Os padrões seguros incluem:

• Histórico append-only.
• Mensagens role: "system" anexadas no ponto em que se tornam verdadeiras.
• Mensagens de sistema com escopo de turno que permanecem no histórico.
• Remoção de uma sequência inicial de blocos de pensamento, sempre do mais antigo para o mais recente.
• Alteração de parâmetros fora de system, tools e messages, como:
  • max_tokens.
  • output_config, incluindo effort.
  • tool_choice.
  • metadata.
• Adição, movimentação ou remoção de marcadores cache_control.
• Compactação e edição de contexto no lado do servidor, inclusive limpeza dethinking-binding-controls-2026-08-01` e defina o comportamento explicitamente:

`python
response = client.beta.messages.create(
model="claude-fable-5-1",
max_tokens=16000,
thinking={
"type": "adaptive",
"block_binding": {
"prefix_mismatch_behavior": "drop_block"
}
},
betas=["thinking-binding-controls-2026-08-01"],
messages=history,
)

for t in response.input_transformations or []:
print(t.type, t.path, t.reason)
`

Com "drop_block", a API descarta o primeiro bloco incompatível e todos os blocos de pensamento seguintes. A requisição continua e cada descarte aparece no array de nível superior input_transformations:

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


Detalhes importantes

• A configuração vale apenas para a requisição atual. Continue enviando-a durante o restante da sessão.
• Sem o cabeçalho beta, uma conta sujeita à imposição retorna erro.
• Enviar apenas o cabeçalho ativa o padrão beta, que é drop_block; ainda assim, defina o valor explicitamente.
• Enviar block_binding sem o cabeçalho retorna:

text
400: block_binding: Extra inputs are not permitted


O campo reason diferencia dois casos:

• prefix_binding_mismatch: o histórico foi alterado.
• model_binding_mismatch: a conversa mudou de modelo, por exemplo após roteamento, nova tentativa ou fallback de recusa.

O segundo caso não indica um bug no seu código. Com o cabeçalho habilitado, toda resposta contém input_transformations, vazio quando nada foi descartado.

Descartar blocos uma vez, em um limite de compactação, costuma ter baixo custo. Invalidar o histórico em toda requisição elimina o raciocínio do modelo a cada turno e reinicia o cache de prompt. Use drop_block como diagnóstico e rede de segurança, não como estado permanente.

Recuperação sem o beta

Em plataformas que ainda não oferecem esses controles — o Microsoft Foundry não os oferecia no lançamento, enquanto Bedrock e Google Cloud os adicionavam por modelo — remova todos os blocos thinking e redacted_thinking do histórico.

Mantenha os blocos text e tool_use de cada turno e tente novamente uma vez. O modelo responderá sem o raciocínio contido nesses blocos.

Essa é uma recuperação pontual, não um padrão de implementação.

Auditoria em três etapas

1. Compare requisições consecutivas

Capture os corpos exatos enviados pelo harness em vários turnos normais, incluindo:

• Uma compactação.
• Uma mudança de ferramenta.
• Qualquer outra operação específica do produto.

Para cada par de requisições consecutivas, compare:

• O prompt system.
• O array tools.
• O prefixo compartilhado de messages.

Tudo deve ser byte a byte idêntico até os turnos recém-anexados.

2. Habilite drop_block durante o teste

Execute uma sessão multi-turno normal com claude-fable-5-1 e registre input_transformations em todas as respostas:

json
{
"thinking": {
"type": "adaptive",
"block_binding": {
"prefix_mismatch_behavior": "drop_block"
}
},
"betas": [
"thinking-binding-controls-2026-08-01"
]
}


Um array vazio em todos os turnos indica que o histórico permaneceu intacto. Uma entrada prefix_binding_mismatch mostra que algo anterior ao bloco indicado em path foi alterado.

Como configurar o campo ativa a imposição para aquela requisição, o teste funciona em contas antigas e novas. No CI, use "error" para transformar qualquer edição em falha explícita.

3. Defina uma política de produção

Escolha e defina o comportamento explicitamente:

• "error": melhor quando uma inconsistência sempre indica um bug.
• "drop_block": melhor quando é preferível degradar em vez de falhar.

Monitore os erros 400 ou as entradas de input_transformations em ambos os casos. Não deixe o campo indefinido em contas antigas: a API pode apenas registrar a inconsistência no servidor, sem oferecer um sinal para monitoramento.

No Apidog, a etapa 2 pode ser criada como um teste de duas requisições:

1. Envie um turno.
2. Edite o prompt do sistema.
3. Envie o turno seguinte com o cabeçalho e o comportamento configurados.
4. Verifique input_transformations.

Mantenha o teste na coleção para executá-lo novamente a cada alteração no harness. Baixe o Apidog para construir esse fluxo.

Como tornar um harness append-only

Cada substituição abaixo mantém o prefixo intacto e ajuda a preservar o cache.

Você estava fazendo	Faça isto em vez disso
Editando o prompt do sistema no meio da sessão, como atualizar a data ou o modo	Congele system no início. Quando a mudança se tornar verdadeira, anexe {"role": "system", "content": "A data atual é 2026-09-14."} no ponto correto. Mensagens de sistema intermediárias tornam-se parte do prefixo.
Editando o array tools no meio da sessão	Declare o conjunto completo no início, usando defer_loading: true para ferramentas inicialmente ocultas. Envie blocos tool_addition e tool_removal em uma mensagem role: "system" com o beta mid-conversation-tool-changes-2026-07-01.
Injetando um lembrete por turno e removendo-o na próxima requisição	Envie o lembrete como uma mensagem de sistema com escopo de turno: {"role": "system", "clear_at": "next_user_message", "content": "..."}. Use o beta mid-conversation-system-clear-at-2026-08-21 e mantenha todas as cópias anteriores no histórico.
Apagando resultados antigos de ferramentas no cliente	Use edição de contexto no lado do servidor com limpeza de resultados de ferramentas.
Compactando no cliente mantendo a cauda literal	Prefira a compactação no lado do servidor, usando o beta compact-2026-01-12. O parâmetro instructions aceita seu próprio prompt de sumarização.
Compactando no cliente mantendo a implementação atual	Substitua todo o histórico por uma mensagem de resumo e o novo turno do usuário. Não reproduza os turnos antigos.
Referenciando a mesma imagem ou documento por URL em vários turnos	Faça upload uma vez para a API Files e envie o file_id, ou use base64.

Duas estratégias de compactação no cliente falham sob a verificação:

• Compactação keep-tail: resume turnos antigos, mas mantém os recentes literalmente. Os blocos recentes foram produzidos contra o histórico completo.
• Compactação em segundo plano: constrói o resumo fora do caminho crítico e o troca posteriormente. Todos os turnos produzidos entre o início do resumo e a troca ficam inválidos.

Cortar turnos individuais do meio da transcrição também invalida cada bloco posterior. Para mudanças de instrução, use mensagens de sistema intermediárias; para remoção seletiva, prefira edição de contexto no lado do servidor.

Há ainda uma consideração de custo: como leituras de cache custam agora US$ 0,25 por milhão de tokens, compactar cedo para economizar dinheiro pode não ser a melhor compensação no Fable 5.1. Experimente pontos de compactação mais tardios.

Por que isso também é uma questão de cache

Tudo que quebra a vinculação também pode reiniciar o cache de prompt.

O Fable 5.1 tornou os cache hits quatro vezes mais baratos que no Fable 5 e tornou os cache misses proporcionalmente mais caros. Um harness append-only oferece dois benefícios:

• Preserva o pensamento do modelo.
• Permite ler o prefixo a US$ 0,25 por milhão, em vez de reescrevê-lo a US$ 12,50.

Consulte o detalhamento de preços, o guia da API, o guia de prompting e o guia do Claude Code.

FAQ

O que significa “o bloco está vinculado a uma conversa diferente”?

Um bloco de pensamento do Claude Fable 5.1 foi reproduzido depois que algo anterior mudou: o prompt do sistema, o array de ferramentas ou uma mensagem anterior. Em contas sujeitas à imposição, a API rejeita a requisição com um erro 400.

Quais contas impõem a verificação de histórico?

Contas criadas em ou após 31 de agosto de 2026, em todas as plataformas. Contas mais antigas só a impõem quando a requisição define thinking.block_binding.prefix_mismatch_behavior. A Anthropic planeja aplicar a regra a todas as contas em modelos futuros.

Como faço o erro desaparecer rapidamente?

Envie o beta thinking-binding-controls-2026-08-01 com prefix_mismatch_behavior: "drop_block". A API descartará os blocos afetados e continuará. Depois, corrija a edição do histórico: descartar blocos a cada turno elimina raciocínio e reinicia o cache.

Alterar effort ou max_tokens invalida blocos de pensamento?

Não. Parâmetros fora de system, tools e messages podem ser alterados livremente. O mesmo vale para os marcadores cache_control.

A compactação no lado do servidor quebra a verificação?

Não. A compactação e a edição de contexto ocorrem após a verificação, que compara a conversa enviada. A compactação no cliente que mantém os turnos recentes literalmente quebra a vinculação.

O Claude Mythos 5.1 tem a mesma verificação?

Não. O Mythos 5.1 não executa a verificação de conversa, embora ainda vincule os blocos de pensamento ao modelo produtor. Alterações no histórico continuam reiniciando o cache.