Se você migrou um "agent harness" para o Claude Fable 5.1 e começou a ver um erro 400 cuja mensagem indica que um "bloco de pensamento" “está vinculado a uma conversa diferente”, seu código edita o histórico da conversa entre as requisições, e o Fable 5.1 é o primeiro modelo Claude que objeta a isso. Este guia explica o que é a verificação, a quem se aplica, exatamente o que a aciona, a solução de contorno e os padrões "append-only" que fazem o erro desaparecer enquanto também mantêm seu cache de prompt "quente".
A verificação está documentada em "pensamento preservado" e em "O que há de novo no Claude Fable 5.1". É a terceira das três mudanças drásticas do Fable 5.1, e a única que pode degradar um "harness" silenciosamente. 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.
É um erro 400 invalid_request_error, decidido antes de qualquer saída. Tentar novamente com o mesmo corpo falha da mesma maneira. O caminho (messages.5.content.0) aponta para o primeiro bloco de pensamento que não corresponde mais, e a mensagem pode terminar com uma frase adicional nomeando a primeira mensagem que foi alterada, que é o diagnóstico que você deseja. O endpoint de contagem de tokens executa a mesma verificação.
Uma falha diferente parece similar, mas não é esta: a mesma cláusula inicial sem a frase “vinculado a uma conversa diferente” significa que a própria assinatura foi adulterada ou é indecifrável, e prefix_mismatch_behavior não se aplica.
O que a verificação faz
Cada bloco de pensamento do Fable 5.1 carrega uma assinatura que registra duas coisas: qual modelo o produziu e o prefixo exato da conversa que o precedeu, ou seja, o prompt system de nível superior, o array tools e cada mensagem antes do bloco. Cada bloco também se encadeia ao bloco de pensamento anterior. Quando você envia a transcrição de volta, a API verifica se esse prefixo é byte a byte idêntico ao que produziu o bloco.
A Anthropic apresenta duas razões. A declarada é anti-destilação: a publicação de lançamento diz que novas contas de API não podem mais editar manualmente o contexto anterior de Claude em uma conversa multi-turno, preservando a transcrição do pensamento anterior, o que fecha uma técnica de destilação documentada. A razão prática é que as mesmas edições que quebram a verificação também reiniciam o cache de prompt, então o código que passa na verificação é também o código que obtém as leituras de cache de $0.25 por milhão a cada turno.
A quem se aplica
Imposto por padrão: contas criadas em ou após 31 de agosto de 2026. Isso abrange organizações da API Claude, contas do Amazon Bedrock, projetos do Google Cloud e recursos do Microsoft Foundry.
Registrado, mas não imposto: contas criadas anteriormente. A API nota a inconsistência, mas age sobre ela apenas quando a requisição define thinking.block_binding.prefix_mismatch_behavior para qualquer valor, incluindo "error". A Anthropic diz que modelos futuros o imporão para todos.
Não afetado: Claude Code, claude.ai, Claude Managed Agents e o Claude Agent SDK, que mantêm o prefixo intacto para você. O Claude Mythos 5.1 não executa a verificação, embora as edições no histórico ainda reiniciem seu cache.
Afetado: qualquer código que construa o array messages por si só. Isso inclui cada loop de agente personalizado, cada backend de chat e cada framework que encapsula a API de Mensagens.
A armadilha para autores de ferramentas: se você distribui algo que as pessoas executam com suas próprias chaves de API, sua chave provavelmente está em uma conta mais antiga e a delas pode não estar. Teste com o campo configurado, para que você encontre a verificação antes que seus usuários o façam. Para saber se sua própria conta é imposta, envie uma requisição que edite o histórico sem o cabeçalho beta; um 400 nomeando o cabeçalho significa que é imposta.
O que invalida cada bloco de pensamento posterior
- Editar, reordenar ou remover um turno anterior. Isso inclui apagar resultados antigos de ferramentas, cortar turnos do meio da transcrição e compactação no lado do cliente que mantém os turnos recentes literalmente por trás de um resumo.
- Injetar conteúdo que você não persiste. Um lembrete por turno anexado após os resultados da ferramenta e removido na próxima requisição. Uma linha de status. Uma contagem de tokens restantes que muda a cada turno.
- Reconstruir
systemoutoolsentre as requisições. Atualizar a data atual no prompt do sistema. Adicionar ou remover uma ferramenta no meio da sessão. - Uma URL de imagem ou documento que serve bytes diferentes mais tarde. Os bytes estão vinculados, não a string da URL, então uma URL assinada rotativa para o mesmo arquivo está ok.
- Remover um bloco de pensamento de qualquer lugar que não seja o início da execução. Blocos iniciais podem ser removidos, do mais antigo primeiro. Um bloco do meio não pode.
O que os mantém válidos
- Históricos "append-only", incluindo mensagens
role: "system"anexadas e mensagens com escopo de turno limpas que permanecem no lugar. - Remover uma sequência inicial de blocos de pensamento, do mais antigo primeiro.
- Alterar qualquer parâmetro fora de
system,toolsemessages:max_tokens,output_configincluindoeffort,tool_choice,metadata. - Adicionar, mover ou remover marcadores
cache_control. - Compactação no lado do servidor e edição de contexto, incluindo a limpeza de blocos de pensamento. Elas não contam como edições porque a verificação compara a conversa como você a enviou, não a cópia editada do servidor. Após uma compactação, o prefixo verificado começa a partir do bloco de compactação.
A solução de contorno: drop_block
Envie o cabeçalho beta thinking-binding-controls-2026-08-01 e defina o campo explicitamente:
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 não correspondente e cada bloco de pensamento subsequente, prossegue com a requisição e relata cada descarte em um array input_transformations de nível superior:
"input_transformations": [
{"type": "thinking_dropped", "path": "messages.1.content.0", "reason": "prefix_binding_mismatch"}
]
Três coisas a saber sobre o campo. Ele se aplica apenas a essa requisição, então continue enviando-o para o resto da sessão. Os padrões diferem por superfície: sem o cabeçalho, uma conta imposta gera erros; enviar o cabeçalho sozinho muda para o padrão beta, que é drop_block; portanto, defina-o explicitamente e nunca dependa de nenhum dos padrões. E enviar block_binding sem o cabeçalho resulta em um erro 400 que termina em block_binding: Extra inputs are not permitted.
O campo reason distingue dois casos. prefix_binding_mismatch significa que seu histórico mudou. model_binding_mismatch significa que a conversa mudou de modelo (um roteador, uma nova tentativa, um fallback de recusa) e o destino não pôde ler um bloco Fable 5.1. O segundo não é um bug em seu código. Com o cabeçalho, cada resposta contém o array, vazio quando nada foi descartado.
Descartar blocos uma vez, em um limite de compactação, custa pouco. Um "harness" que invalida seu próprio histórico em cada requisição perde o raciocínio do modelo a cada turno e reinicia o cache de prompt a cada turno, e a Anthropic adverte que isso aumenta o custo por tarefa. Trate drop_block como um diagnóstico e uma rede de segurança, não um estado estável.
A recuperação sem beta
Em uma plataforma sem os controles (o Microsoft Foundry não os oferecia no lançamento; Bedrock e Google Cloud estavam adicionando-os 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 responde a esse turno sem o raciocínio que esses blocos carregavam. Esta é uma recuperação única, não um padrão.
A auditoria em três etapas
- Capture os corpos exatos das requisições que seu "harness" envia em alguns turnos normais, incluindo uma compactação ou uma mudança de ferramenta, se seu produto as tiver. Para cada par de requisições consecutivas, compare (diff) o prompt
system, o arraytoolse o prefixo compartilhado demessages. Eles devem ser byte a byte idênticos até os turnos recém-anexados. - Execute uma sessão multi-turno normal contra
claude-fable-5-1com o cabeçalho beta eprefix_mismatch_behavior: "drop_block", registrandoinput_transformationsem cada resposta. Um array vazio a cada turno significa que o histórico está intacto. Uma entradaprefix_binding_mismatchsignifica que algo antes do bloco empathfoi alterado. Isso funciona a partir de qualquer conta, porque configurar o campo opta a requisição pela imposição. Em CI, defina"error"em vez disso, para que uma edição falhe na execução. - Escolha uma configuração de produção e defina-a explicitamente sob o cabeçalho:
"error"se uma inconsistência só pode significar um bug,"drop_block"para degradar em vez de falhar. Monitore os erros 400 ou as entradas deinput_transformationsde qualquer forma. Não deixe o campo indefinido em uma conta mais antiga, porque então a verificação apenas registra no lado do servidor e você não terá nada para monitorar.
No Apidog, a etapa 2 é um teste de duas requisições: envie um turno, edite o prompt do sistema, envie o próximo turno com o cabeçalho definido e verifique input_transformations. Mantenha-o na coleção para que cada mudança no "harness" o execute novamente. Baixe o Apidog para construí-lo.
Tornando um "harness" "append-only"
Cada linha substitui uma edição de histórico por algo que mantém o prefixo intacto e o cache "quente".
| Você estava fazendo | Faça isto em vez disso |
|---|---|
| Editando o prompt do sistema no meio da sessão (nova data, novo modo) | Congele system no início da sessão. Anexe {"role": "system", "content": "A data atual é 2026-09-14."} no ponto em que a mudança se torna verdadeira (mensagens de sistema no meio da conversa). Sem cabeçalho beta; ele obtém autoridade de prompt do sistema e se torna parte do prefixo ao qual blocos posteriores estão vinculados. |
Editando o array tools no meio da sessão |
Declare o conjunto completo no início da sessão (defer_loading: true nos que começam ocultos). Envie blocos tool_addition e tool_removal em uma mensagem role: "system" (beta mid-conversation-tool-changes-2026-07-01). |
| Injetando um lembrete por turno e deletando-o na próxima requisição | Envie-o como uma mensagem de sistema com escopo de turno: {"role": "system", "clear_at": "next_user_message", "content": "..."} (beta mid-conversation-system-clear-at-2026-08-21) após a mensagem de resultado da ferramenta, e deixe todas as cópias anteriores no lugar. Cópias limpas não renderizam nada e não custam nada. Sem o beta, coloque o lembrete em um bloco de texto após os blocos tool_result na mesma mensagem do usuário, mantendo as cópias anteriores. |
| Apagando resultados antigos de ferramentas no lado do cliente | Edição de contexto no lado do servidor com limpeza de resultados de ferramentas. |
| Compactando no cliente | Prefira a compactação no lado do servidor (beta compact-2026-01-12; seu parâmetro instructions aceita seu próprio prompt de sumarização). Se você permanecer no lado do cliente, use compactação simples: substitua todo o histórico por uma mensagem de resumo mais o novo turno do usuário e não reproduza mais nada. |
| Referenciando uma imagem ou documento por URL em vários turnos | Faça upload uma vez para a API Files e envie o file_id, ou envie base64. |
Duas formas de compactação no lado do cliente falham sob a verificação e necessitam de drop_block ou de blocos de pensamento removidos nos turnos retidos. A compactação "keep-tail" (resumir turnos mais antigos, manter os mais recentes literalmente) falha nos turnos retidos, porque seu pensamento foi produzido contra o histórico completo. A compactação em segundo plano (construir o resumo fora do caminho crítico e trocá-lo mais tarde) falha em cada turno produzido entre o início do resumo e a troca. Cortar turnos individuais do meio da transcrição invalida cada bloco posterior, e nenhuma forma de cliente a evita. Use uma mensagem de sistema no meio da conversa para a mudança de instrução que você estava fazendo, ou edição de contexto no lado do servidor para remoção seletiva.
Mais uma consideração de custo: como as leituras de cache agora custam $0.25 por milhão, compactar cedo para economizar dinheiro pode não ser mais a compensação ideal no Fable 5.1. A Anthropic sugere experimentar pontos de compactação posteriores.
Por que esta é também a história do cache
Tudo na tabela acima é também a lista de coisas que reiniciam um cache de prompt. O Fable 5.1 tornou os "cache hits" quatro vezes mais baratos que o Fable 5 e tornou os "misses" proporcionalmente mais dolorosos, então um "harness" "append-only" é recompensado duas vezes: o pensamento sobrevive, e cada turno lê o prefixo a $0.25 em vez de reescrevê-lo a $12.50. O detalhamento de preços tem os números; o guia da API mostra as formas de requisição com escopo de turno e esforço por mensagem em contexto, o guia de prompting cobre quais instruções por turno vale a pena enviar dessa forma, e o guia do Claude Code explica por que os usuários do Claude Code nunca veem este erro.
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 a ele mudou: o prompt do sistema, o array de ferramentas ou uma mensagem anterior. A API rejeita a requisição com um erro 400 em contas impostas.
Quais contas impõem a verificação de histórico do Fable 5.1? Contas criadas em ou após 31 de agosto de 2026, em todas as plataformas. Contas mais antigas a impõem apenas quando uma requisição define thinking.block_binding.prefix_mismatch_behavior. A Anthropic planeja impô-la para todos em modelos futuros.
Como faço para o erro desaparecer rapidamente? Envie o cabeçalho beta thinking-binding-controls-2026-08-01 com prefix_mismatch_behavior: "drop_block". A API descarta os blocos afetados e continua. Em seguida, corrija a edição do histórico, porque descartar blocos a cada turno custa raciocínio e reinicia seu cache.
Alterar effort ou max_tokens invalida blocos de pensamento? Não. Qualquer parâmetro fora de system, tools e messages pode mudar livremente, e o mesmo ocorre com 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 acontecem após a verificação, que compara a conversa como você a enviou. A compactação no lado do cliente que mantém os turnos recentes literalmente a quebra.
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 e as edições de histórico ainda reiniciem seu cache.