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” 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.
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 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_: 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, o guia da API, o guia de prompting e o guia do Claude Code.
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.