Thinking blocks no Claude Fable 5.1: o modelo lê o raciocínio dos modelos anteriores?

Sua conversa troca de modelo no meio do caminho, por um retry, um fallback ou um roteador de custo, e o raciocínio que estava ali simplesmente some, sem erro e sem aviso nenhum na resposta…

A Anthropic lançou o Claude Fable 5.1 e o Claude Mythos 5.1, que são o mesmo modelo com níveis diferentes de salvaguardas: o Fable 5.1 é de disponibilidade geral e o Mythos 5.1 só sai por programas de acesso confiável

E junto do lançamento veio um detalhe pouco documentado em português, que é justamente o recorte deste post: o que acontece com os thinking blocks antigos quando a conversa muda de modelo

Bora destrinchar isso 😀

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 114 aulas
• 4 projetos
• 9h 18min

Conhecer formação

O que a Anthropic lançou e por que os thinking blocks entraram na conversa

O Claude Fable 5.1 chegou em disponibilidade geral, valendo para Pro, Max, Team e Enterprise

A própria Anthropic descreve ele como o modelo Claude mais avançado em disponibilidade geral, voltado a projetos longos e trabalho de código em toda a base

O Mythos 5.1 é o mesmo modelo, só que com outro nível de salvaguardas, e não sai pra qualquer um: acesso só por trusted access programs

Até aqui é notícia de lançamento normal

A parte interessante é o porquê da checagem de preserved thinking existir

A motivação declarada é barrar destilação ilícita em escala industrial: editar o contexto ao redor de um thinking block é técnica pública e documentada pra extrair o raciocínio do Claude, e isso é proibido pela Usage Policy e pelos Termos de Serviço da Anthropic

Ou seja, o que parece um detalhe chato de API é na verdade um mecanismo de proteção do raciocínio do modelo

Como funciona a preservação unidirecional dos thinking blocks

Primeiro o conceito, que é o que faz o resto encaixar

Todo thinking block registra qual modelo o produziu

E a preservação vale em UMA direção só: o Claude Fable 5.1 lê thinking blocks de modelos anteriores, e nenhum modelo anterior lê os thinking blocks do Fable 5.1

Na prática: conversa que migra PARA o Fable 5.1 mantém o raciocínio, conversa que volta do Fable 5.1 pra um modelo antigo não mantém

E o que a signature faz nisso?

Quando o thinking block é devolvido à API, a assinatura (signature) é usada pra checar duas coisas ao mesmo tempo:

• que a conversa anterior não mudou
• que o modelo atual pode ler aquele bloco

Se você conhece checksum de arquivo, a ideia é bem parecida: o bloco só vale se o que veio antes dele continuar igualzinho

Quais modelos o Fable 5.1 consegue ler:

O Claude Fable 5.1 lê os próprios thinking blocks e também os de:

• Claude Mythos 5.1
• Claude Opus 5
• Claude Fable 5
• Claude Mythos 5
• modelos Claude anteriores

A lista completa está no guia de migração do Fable 5.1

Bloco descartado, requisição rejeitada: o que cada comportamento significa

Aqui começa a parte que quebra pipeline em produção, então se liga nos dois cenários, porque eles são bem diferentes

Cenário 1: o modelo de destino não consegue ler o bloco

Acontece quando a conversa troca de modelo por router, por retry ou por fallback

O que a API faz: descarta o bloco antes de o modelo ver

A requisição continua funcionando, e os blocos descartados não contam como input_tokens nem são cobrados

Parece bom, e é, mas tem um efeito colateral silencioso: você perde o raciocínio sem receber nenhum aviso na resposta padrão

Pra enxergar o que foi descartado, é preciso enviar o beta header thinking-binding-controls-2026-08-01

Com ele, a resposta passa a trazer um array input_transformations nomeando cada bloco descartado, com o motivo:

"input_transformations": [
  { "reason": "model_binding_mismatch" }
]

O model_binding_mismatch indica exatamente isso: a conversa trocou de modelo

Cenário 2: o prefixo da conversa mudou

Esse é mais bruto

No Claude Fable 5.1, alterar turnos anteriores da conversa (system prompt, tools ou qualquer mensagem antiga) faz a API rejeitar a requisição com erro por padrão

O motivo correspondente é o prefix_binding_mismatch, que indica que algo antes do bloco mudou desde a requisição anterior

Tome cuidado aqui: não precisa ser uma mudança grande, basta o prefixo não bater mais

Se você prefere descartar o bloco e seguir em vez de tomar erro, dá pra mandar o mesmo beta header com o comportamento definido:

{
  "thinking": {
    "block_binding": {
      "prefix_mismatch_behavior": "drop_block"
    }
  }
}

Como prevenir: conversa append-only

A recomendação da Anthropic pra manter o thinking válido em sessões longas é tratar a conversa como append-only

Ou seja: em vez de editar o system prompt ou as tools originais, você usa mensagem de sistema no meio da conversa e mudanças de tools no meio da conversa

É uma inversão de hábito, porque muito pipeline por aí reescreve o system prompt a cada iteração achando que é inofensivo

Agora não é mais

O que muda para quem migra conversas e pipelines já existentes

A pergunta óbvia: isso já pegou todo mundo?

Ainda não

A checagem de preserved thinking é aplicada por padrão apenas para contas de API novas, criadas a partir de 31 de agosto de 2026, 00:00 UTC

E a Anthropic afirma que isso vai valer para todas as contas em lançamentos futuros

Então a conta antiga que roda liso hoje pode virar um monte de erro amanhã, sem você ter mudado uma linha de código

Os pontos que sentem primeiro:

• roteadores de modelo por custo, que mandam a mesma conversa ora pra um modelo, ora pra outro
• camadas de retry e fallback, que trocam o modelo de destino sozinhas quando a primeira tentativa falha
• qualquer pipeline que reescreve system prompt ou tools no meio da conversa, que é o caso clássico de prefixo alterado

Se o seu projeto tem os três, a chance de encontrar um prefix_binding_mismatch é alta

Os detalhes de comportamento estão na documentação de preserved thinking

Quais modelos preservam thinking blocks de todos os turnos

Antes de migrar, vale olhar a retenção padrão por família de modelo

Tem modelo que carrega o raciocínio de todos os turnos anteriores e tem modelo que carrega só o do último turno:

Usa isso como checklist: se a sua conversa nasceu num modelo da metade de baixo da tabela, não espere encontrar raciocínio de turnos antigos pra preservar, porque ele já não estava lá

Situações em que a preservação de thinking blocks pesa no seu projeto

Nem todo projeto vai sentir isso na pele

Os que sentem, sentem muito:

• sessões agênticas longas de código, onde o modelo trabalha em várias etapas e o raciocínio acumulado é metade do valor da sessão
• roteamento entre modelos por custo, mandando tarefa leve pro modelo barato e tarefa pesada pro Fable 5.1
• retry automático em produção, que troca de modelo sem ninguém olhar
• migração de histórico de conversa de um modelo antigo pro Fable 5.1

Nesse último caso a notícia é boa: a via de ida funciona, o histórico chega com o raciocínio

E tem o lado da conta também

Na API, o Claude Fable 5.1 custa US$ 10 por milhão de tokens de entrada e US$ 50 por milhão de tokens de saída

O cache read está em US$ 0,25 por milhão, 75% mais barato que o Fable 5

A Anthropic estima com esse novo preço de cache read uma redução de custo de cerca de 25% em cargas típicas e até aproximadamente 45% em cargas altamente agênticas

Repare no encaixe: cache read barato premia justamente quem mantém a conversa crescendo sem mexer no que já passou, que é exatamente o padrão append-only

Quem trabalha com sessão longa e resposta grande também costuma esbarrar em o limite de resposta do Claude Fable 5, que é outra conta pra fazer antes de migrar

Vale migrar agora? O próximo passo

Recapitulando o que interessa:

A preservação é de via única

Para frente preserva (o Fable 5.1 lê o raciocínio dos modelos anteriores), para trás não preserva (nenhum modelo anterior lê o raciocínio do Fable 5.1)

Bloco ilegível pelo modelo de destino é descartado sem erro e sem cobrança

Prefixo alterado é erro por padrão no Fable 5.1

O passo prático, na ordem:

1. Audite se a sua conta de API cai na regra por data: a checagem já vale por padrão para contas criadas a partir de 31 de agosto de 2026, 00:00 UTC
2. Ligue o beta header thinking-binding-controls-2026-08-01 e observe o array input_transformations ANTES de mudar qualquer coisa no pipeline. O erro comum aqui é sair corrigindo no escuro, sem saber se o motivo é model_binding_mismatch ou prefix_binding_mismatch, que pedem soluções diferentes
3. Converta o pipeline para append-only, usando mensagem de sistema no meio da conversa e mudanças de tools no meio da conversa em vez de editar o original

É pouca coisa de código e muita economia de dor de cabeça depois

até o próximo post! 🙂