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

Claude Fable 5.1 introduces a preserved-thinking verification that rejects message histories edited between requests, returning a 400 error for thinking blocks bound to a different conversation. The check, designed to prevent distillation, compares the prefix of system, tools, and messages byte-for-byte, and can be bypassed by using an append-only history or setting the prefix_mismatch_behavior to 'drop_block' with the appropriate beta header.

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. A verificação está documentada em “pensamento preservado” https://platform.claude.com/docs/en/build-with-claude/preserved-thinking e em “O que há de novo no Claude Fable 5.1” https://platform.claude.com/docs/en/models/fable-5-1/whats-new-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 https://apidog.com/pt/blog/claude-fable-5-1-migration?utm source=dev.to&utm medium=wanda&utm content=n8n-post-automation . 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. Cada bloco de pensamento do Fable 5.1 contém uma assinatura que registra: system de nível superior. tools .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. Contas criadas em ou após 31 de agosto de 2026, incluindo: 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. A verificação não é executada por: 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. Qualquer aplicação que construa o array messages manualmente, como: 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. As seguintes alterações quebram a vinculação: system ou tools entre requisições. Os padrões seguros incluem: role: "system" anexadas no ponto em que se tornam verdadeiras. system , tools e messages , como: max tokens . output config , incluindo effort . tool choice . metadata . cache control . 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" } } drop block ; ainda assim, defina o valor explicitamente. 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. 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. Capture os corpos exatos enviados pelo harness em vários turnos normais, incluindo: Para cada par de requisições consecutivas, compare: system . tools . messages .Tudo deve ser byte a byte idêntico até os turnos recém-anexados. 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. 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: input transformations .Mantenha o teste na coleção para executá-lo novamente a cada alteração no harness . Baixe o Apidog https://apidog.com/download?utm source=dev.to&utm medium=wanda&utm content=n8n-post-automation para construir esse fluxo. 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 compact-2026-01-12 . O parâmetro instructions aceita seu próprio prompt de sumarização. | file id , ou use base64.Duas estratégias de compactação no cliente falham sob a verificação: keep-tail 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. 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: Consulte o detalhamento de preços https://apidog.com/pt/blog/claude-fable-5-1-pricing?utm source=dev.to&utm medium=wanda&utm content=n8n-post-automation , o guia da API https://apidog.com/pt/blog/claude-fable-5-1-api?utm source=dev.to&utm medium=wanda&utm content=n8n-post-automation , o guia de prompting https://apidog.com/pt/blog/prompting-claude-fable-5-1?utm source=dev.to&utm medium=wanda&utm content=n8n-post-automation e o guia do Claude Code https://apidog.com/pt/blog/claude-fable-5-1-claude-code?utm source=dev.to&utm medium=wanda&utm content=n8n-post-automation . 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. 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. 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. 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 . 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. 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.