Como migrar do Claude Fable 5 para o Claude Fable 5.1 sem quebrar sua aplicação

Trocar o modelo de uma aplicação que já está rodando parece um find and replace inocente, e é aí que mora o perigo

A Anthropic anunciou o Claude Fable 5.1 (e o Claude Mythos 5.1) no dia 1 de setembro de 2026

O Fable 5, que saiu em junho de 2026, continua ativo na API, não foi depreciado e não tem data de aposentadoria anunciada

Ou seja: migrar para o Claude Fable 5.1 é uma escolha tua, não uma corrida contra o relógio 🙂

Este post é um checklist de integração pra quem já tem código em produção: onde o nome do modelo aparece, o que quebra de verdade, como testar antes e quais sinais indicam que o comportamento mudou

Fable 5 e Fable 5.1: o que continua igual e o que muda

Antes de sair mexendo, vale ver o mapa lado a lado

A boa notícia é que a maior parte da migração é drop-in: superfície da API, limites, preço por token, tokenizer, thinking adaptativo sempre ligado, tratamento de recusas e as categorias de stop_details são iguais aos do Fable 5

A queda no cache read é o que mais mexe na conta no fim do mês: a estimativa é de cerca de 25% de redução em workloads típicos e de até aproximadamente 45% em workloads altamente agênticos

Se a tua aplicação já parou no meio do expediente alguma vez, vale entender como os créditos da Claude API se comportam antes de aumentar o volume de chamadas confiando na economia

Formação Recomendada

Formação Claude Code

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

• 118 aulas
• 4 projetos
• 9h 33min

Conhecer formação

Os três pontos que quebram código:

De tudo que muda, só três coisas quebram código de verdade na migração

Guarda esses três, porque o resto do post volta neles o tempo todo:

1. Uso forçado de ferramenta: tool_choice forçado agora retorna erro
2. Thinking blocks: modelos anteriores não conseguem ler os blocos de thinking do 5.1
3. Edição de turnos: editar turnos anteriores invalida os blocos de thinking

O resto é troca de string e recalibragem, beleza?

Sua integração precisa de ajuste? Três cenários

Antes do passo a passo, se identifica num destes três

Isso te diz de cara quanto trabalho tem pela frente

Cenário 1: quem não gerencia o histórico na mão

Se quem cuida do histórico da conversa é o Claude Code, o claude.ai, os Claude Managed Agents ou o Claude Agent SDK, o prefixo da conversa já é mantido intacto

Traduzindo: aquele item chatíssimo dos blocos de thinking não exige trabalho manual do teu lado

Sobra pra ti a troca do ID e a validação de comportamento

Cenário 2: quem monta o array de mensagens na unha

Aqui tu tem trabalho de verdade

É o cenário em que o teu código precisa garantir histórico append-only, porque cada bloco de thinking do 5.1 é válido só contra o system prompt, o array de tools e o histórico de mensagens exatos que vieram antes dele

Mexeu em qualquer um dos três, a requisição seguinte dá erro (ou o bloco é descartado, se tu escolher esse comportamento)

Cenário 3: quem consome via nuvem de terceiro

O Fable 5.1 está disponível na Claude API, no Amazon Bedrock, no Google Cloud e no Microsoft Foundry

Cada plataforma tem o seu formato de identificador, então a troca não é sempre a mesma string colada em todo lugar

Se tu consome o modelo por uma dessas plataformas, confirma o formato correto do ID ali antes de subir qualquer coisa

O que ter em mãos antes de trocar o ID do modelo

Nada de sair editando arquivo às cegas, se liga na lista de preparação:

• Mapa de onde a string aparece: código, variáveis de ambiente, arquivos de config, prompts salvos e os clientes de cada nuvem. claude-fable-5 tem o hábito de estar em mais lugar do que a memória lembra
• Um conjunto de evals rodável: sem isso tu não tem como afirmar que nada mudou de comportamento, só "achar"
• Ambiente de teste separado de produção: os três pontos que quebram código (uso forçado de ferramenta, thinking blocks e edição de turnos) quebram silenciosamente em alguns casos, e tu não quer descobrir isso com usuário na frente

O guia de migração oficial lista cinco checagens de follow-up: remover chamadas com tool_choice forçado, verificar que o código mantém o histórico append-only, re-calibrar o effort agora que ele muda no meio da conversa, observar o novo padrão de uma chamada de ferramenta por turno nos agent loops e rodar de novo o conjunto de evals

É exatamente esse o roteiro que o passo a passo abaixo segue

Passo a passo da migração do Fable 5 para o Fable 5.1

1. Trocar o ID claude-fable-5 por claude-fable-5-1

Dá pra fazer na mão ou usar a skill claude-api, que já vem embutida no Claude Code

/claude-api migrate this project to claude-fable-5-1

Ela confirma o escopo antes de editar, aplica a troca do ID e as mudanças de parâmetro, detecta os clientes de nuvem que ela cobre (Bedrock, Vertex, Claude Platform on AWS e Foundry) ajustando o formato do identificador, e no fim te devolve um checklist do que verificar na mão

O erro comum deste passo: aceitar a troca automática sem revisar o diff. A própria orientação da skill é revisar o diff e rodar os evals depois, porque troca automática de parâmetro ainda exige validação comportamental

2. Remover o uso forçado de ferramenta

Esse é o primeiro dos três pontos que quebram código

tool_choice com {"type": "any"} ou {"type": "tool", "name": "..."} retorna 400 invalid_request_error, com a mensagem de que os tipos "tool" e "any" não são suportados para esse modelo

// antes
"tool_choice": {"type": "any"}

// depois
"tool_choice": {"type": "auto"}

Só trocar o tipo não basta: o substituto oficial é tool_choice: {"type": "auto"} com instrução explícita (no turno do usuário ou em system message no meio da conversa) e ferramentas com strict: true, ou então partir pra structured outputs

O erro comum deste passo: mudar pra auto e não dar a instrução explícita, aí o modelo simplesmente não chama a ferramenta que o teu fluxo esperava

3. Validar o histórico append-only com a checagem de três passos

Aqui entram o segundo e o terceiro pontos que quebram código: modelos anteriores não leem os blocos de thinking do 5.1, e a edição de turnos anteriores invalida esses blocos

A Anthropic recomenda um caminho bem direto pra descobrir se o teu código está estragando o prefixo

Primeiro, rodar uma sessão normal com o header beta e prefix_mismatch_behavior: "drop_block":

anthropic-beta: thinking-binding-controls-2026-08-01

Segundo, logar input_transformations em toda resposta e corrigir cada entrada com prefix_binding_mismatch

Terceiro, escolher entre "error" ou "drop_block" pro que vai pra produção

O erro comum deste passo: rodar sem o header beta. Sem ele o descarte de bloco é silencioso, e tu vai ficar caçando fantasma

4. Re-calibrar o effort

No Fable 5.1 dá pra alterar o nível de effort no meio da conversa sem invalidar o cache de prompt: sobe num passo difícil, baixa nos rotineiros

O padrão é high

O erro comum deste passo: deixar tudo no padrão e estranhar a conta ou a latência depois. Se o teu uso passa pelo Claude Code, dá pra olhar quanto token a sessão gastou e calibrar com dado na mão em vez de feeling

5. Rodar o conjunto de evals no ambiente de teste

Só depois disso é que a coisa vai pra produção, beleza?

O erro comum deste passo: rodar os evals direto contra produção porque "é só uma string diferente". As três mudanças que quebram código não aparecem no diff, elas aparecem no comportamento

Sinais de que algo mudou de comportamento (e o que fazer)

Migração de modelo raramente falha com fogos de artifício

Ela falha com um sintoma esquisito que ninguém liga ao deploy da semana passada

Sintoma A: erro 400 citando os tipos "tool" e "any"

Causa: sobrou tool_choice forçado em algum lugar do código

Solução: trocar por tool_choice: {"type": "auto"} com instrução explícita e ferramentas com strict: true, ou migrar aquele fluxo pra structured outputs

Prevenção: buscar por tool_choice no projeto inteiro antes do deploy, não só nos arquivos que tu lembra

Sintoma B: a requisição falha ou o bloco de thinking simplesmente some

Causa: o vínculo do bloco com o prefixo exato. Editou system prompt, array de tools ou histórico de mensagens, o bloco perde a validade

Solução: ligar o header beta pra enxergar o que está acontecendo. Com ele, o descarte é reportado num array de topo input_transformations com reason: "prefix_binding_mismatch". Sem ele, o descarte é silencioso

Detalhe que tira um peso das costas: bloco de thinking descartado não conta pra input_tokens e não é faturado

Prevenção: o que mantém os blocos válidos numa sessão longa, segundo a documentação de preserved thinking, é histórico append-only, remover uma sequência inicial de blocos do mais antigo para o mais novo, compactação ou edição de contexto server-side, mover marcadores cache_control e mudar o effort entre requisições

Sintoma C: o agente fica em silêncio por minutos

Causa: por padrão o Fable 5.1 escreve menos updates visíveis ao usuário do que o Fable 5 durante turnos longos de chamada de ferramenta. O efeito é mais pronunciado em effort alto e cadeias longas de ferramentas

Não é travamento, é o modelo falando menos

Solução: o Fable 5.1 escreve updates curtos de progresso entre as chamadas, cada um como um bloco de thinking próprio. Com o header beta thinking-display-updates-2026-08-18 e a opção display: "updates", eles chegam como texto enquanto o raciocínio segue oculto

Prevenção: se a tua UI tem indicador de atividade, testa esse modo antes de o suporte receber ticket de "travou"

Sintoma D: agent loop mais lento ou com fluxo diferente

Causa: o comportamento do agent loop mudou em relação ao Fable 5, e a diferença mais visível é uma chamada de ferramenta por turno onde o Fable 5 agrupava várias

Solução: revisar as suposições do teu loop, principalmente contagem de turnos, timeouts e qualquer lógica que esperava várias tool calls chegando juntas

Prevenção: medir o loop antes e depois no ambiente de teste, com o mesmo cenário dos dois lados

Migração feita: o que checar depois

No fim das contas, a maior parte disso é troca de string

O risco de verdade mora nos três pontos de sempre: uso forçado de ferramenta que agora retorna erro, modelos anteriores que não conseguem ler os blocos de thinking do 5.1 e a edição de turnos anteriores que invalida esses blocos

Automação ajuda muito, mas não dispensa revisar o diff e rodar o conjunto de evals de novo

E se algo ficar estranho, lembra que o Fable 5 continua disponível como plano B enquanto os testes rodam, já que ele não foi depreciado nem tem data de aposentadoria anunciada

Vale saber também que o texto gerado pelo Claude Fable 5.1 e pelo Claude Mythos 5.1 carrega a marca d’água estatística de texto da Anthropic em toda plataforma onde o modelo está disponível

Próximo passo concreto: roda o teu conjunto de evals com o header beta ligado, olha o input_transformations de cada resposta e só então manda pra produção

Até o próximo post! 😀