Seus prompts do Claude Fable 5 continuam funcionando no Fable 5.1?

Trocar de versão de modelo é tipo trocar o motor do carro e manter o mesmo volante

Fala aí, beleza? A Anthropic anunciou hoje, 01/09/2026, o Claude Fable 5.1 (junto do Mythos 5.1), e a primeira pergunta de quem tem system prompt rodando em produção não foi sobre benchmark

Foi essa: aquele monte de instrução que eu ajustei no dedo pro Fable 5 continua valendo?

O medo é real e é bem específico: descobrir na marra, num turno qualquer, que a saída mudou de estilo ou de formato e ninguém sabe se a culpa é do prompt, do modelo ou de um parâmetro que veio diferente por padrão

A boa notícia vem da própria documentação: prompts do Fable 5 tendem a performar bem no 5.1 sem mudanças, com algumas diferenças de comportamento pra conhecer

A notícia chata é que "algumas diferenças" inclui dois erros 400 novos que derrubam integração

Bora destrinchar isso? 🙂

O que é o Fable 5.1 e onde ele já está disponível

O Claude Fable 5.1 foi anunciado em 01/09/2026, junto do Mythos 5.1, e já está disponível na Claude API e nas nuvens AWS, Google Cloud e Microsoft Azure

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

Na API, o identificador é claude-fable-5-1

E a migração vinda do Fable 5 é literalmente uma troca de model ID: claude-fable-5 passa a claude-fable-5-1

O preço por token não mudou: US$ 10 por milhão de tokens de entrada e US$ 50 por milhão de tokens de saída, igualzinho ao Fable 5

O que mudou de valor foi o cache, e mudou pra baixo:

Ou seja: leitura de cache 75% mais barata no 5.1

A escrita de cache de 5 minutos fica em US$ 12,50 por milhão e a de 1 hora em US$ 20 por milhão

E o Fable 5? Ele passou a ser listado como modelo legado, mas continua disponível, com aposentadoria não antes de 09/06/2027 e a leitura de cache mantida em US$ 1 por milhão

Traduzindo: dá pra migrar com calma, sem correria e sem madrugada de deploy 😀

As duas mudanças de API que realmente quebram a sua integração

Aqui vale separar duas coisas que a galera mistura: comportamento diferente (a resposta sai com outro jeitão) e erro duro (a requisição nem passa)

Começa pelo erro duro, que é o que te acorda de madrugada

1. tool_choice forçado agora retorna 400:

No Fable 5.1, tool_choice com valor "any" ou apontando uma ferramenta nomeada retorna erro 400

A orientação oficial é usar tool_choice: "auto" com uso estrito de ferramentas

{
  "model": "claude-fable-5-1",
  "tool_choice": { "type": "auto" }
}

E por que travaram isso? Porque no 5.1 o thinking está sempre ligado

Uma chamada forçada puliria o raciocínio, e ele acabaria empurrado pra dentro dos argumentos da ferramenta

Se você tinha um fluxo que dependia de "chama essa tool agora, sem conversa", esse é o primeiro ponto da sua revisão

2. O raciocínio ficou preso ao contexto que veio antes dele:

Essa é mais sutil e derruba mais gente

Cada bloco de raciocínio do Fable 5.1 fica preso ao system prompt, ao array de ferramentas e ao histórico que vieram antes dele

Se qualquer um desses três for alterado e o bloco for reenviado, a requisição é rejeitada com erro 400

A recomendação é tratar a conversa como append-only: você acrescenta, não reescreve

"Mas eu PRECISO mudar as instruções no meio da conversa", você diz

Beleza, e a saída recomendada existe: adicionar instrução nova via mensagem de sistema no meio da conversa (mid-conversation system message) e trocar ferramentas via mid-conversation tool changes, em vez de editar o system prompt ou o array de tools

Os detalhes desses dois caminhos estão no guia de migração do Fable 5.1

Tome cuidado com um padrão muito comum: integração que remonta o system prompt a cada turno (injetando data, contexto de usuário, lista dinâmica de tools) passa nos testes locais de um turno só e explode no segundo turno de produção

Quais partes do seu prompt envelhecem na troca de versão

Agora o miolo: as instruções que faziam total sentido no Fable 5 e que hoje jogam contra você

Instrução de brevidade no texto de progresso

O Fable 5.1 escreve menos atualizações visíveis ao usuário durante turnos longos de chamada de ferramentas do que o Fable 5

O efeito é mais pronunciado em effort alto e em cadeias longas de ferramentas

A orientação é pedir o texto de progresso explicitamente e remover as instruções que mandam ser breve nesse texto

Olha a ironia: aquele "seja conciso, não narre o que você está fazendo" que você escreveu pra conter a tagarelice do 5 é justamente o que deixa o 5.1 mudo numa tarefa de vinte minutos

Regra de edição de arquivo

O 5.1 tem mais tendência que o Fable 5 a reescrever um arquivo de texto inteiro em vez de fazer uma edição pontual

Salvo arquivo curto ou mudança quase total, isso custa mais tokens de saída e mais tempo

Se o seu prompt não deixava explícito que edição pontual é o padrão, esse é um bom lugar pra ser chato e explícito

Instrução de chamadas paralelas

A chamada paralela de ferramentas ficou mais variável no 5.1

Ele pode emitir uma chamada por turno em situações em que o Fable 5 agrupava várias

Em loops longos de agente, a orientação é enviar a instrução de chamadas paralelas como mensagem de sistema com escopo de turno após cada rodada de resultados de ferramenta

Ou seja: falar uma vez lá no topo do system prompt não segura o comportamento a conversa inteira, tu precisa relembrar a cada rodada

Antes de culpar o prompt, confira o nível de esforço

Essa aqui é a variável que mais é confundida com regressão de prompt

O parâmetro de esforço fica dentro de output_config na Messages API e aceita cinco valores: low, medium, high, xhigh e max

{
  "model": "claude-fable-5-1",
  "output_config": { "effort": "high" }
}

E o padrão muda conforme o produto: high no Claude Code e na API, medium no Claude Cowork e no claude.ai

Se liga no que isso significa: o MESMO prompt, palavra por palavra, pode render diferente dependendo de onde tu rodou ele

Antes de sair reescrevendo instrução, iguala o effort dos dois lados e roda de novo

A boa notícia é que no 5.1 dá pra trocar o nível de esforço no meio da conversa sem invalidar o cache de prompt, e o esforço por mensagem está em beta

A resposta mudou de estilo ou de formato: como isolar a causa

Roteiro de diagnóstico por sintoma, começando pelo mais barato de checar

Sintoma: erro 400 quando a conversa é retomada

Causa provável: a sua integração está editando histórico, system prompt ou array de tools entre turnos

Existe um controle pra isso: prefix_mismatch_behavior tem "error" como padrão (falha com 400) e aceita "drop_block" pra descartar os blocos afetados em vez de falhar

O truque de diagnóstico é rodar uma sessão com drop_block e ler o relatório:

1. Habilite o header beta thinking-binding-controls-2026-08-01 na requisição
2. Configure prefix_mismatch_behavior como "drop_block" numa sessão de teste
3. Rode um fluxo real, com vários turnos e chamadas de ferramenta (um turno só não reproduz o problema, esse é o erro comum aqui)
4. Leia o array input_transformations na resposta: ele nomeia cada bloco descartado com reason: "model_binding_mismatch"
5. Volte pro padrão "error" depois de corrigir, pra não mascarar o problema em produção

{
  "prefix_mismatch_behavior": "drop_block"
}

Cada bloco que aparecer nesse relatório é uma dedo-duro de onde a sua integração mexe no que já foi enviado

Sintoma: o agente ficou calado em tarefas longas

Causa provável: instrução de brevidade sobrevivendo do prompt antigo, somada a effort alto e cadeia longa de ferramentas

Solução: pedir o texto de progresso explicitamente e tirar a regra de "seja breve" desse trecho específico

Sintoma: custo e latência subindo sem explicação

Causa provável: reescrita de arquivo inteiro onde bastava edição pontual, ou perda de paralelismo nas chamadas de ferramenta

Solução: os dois ajustes da seção anterior, e olhar tokens de saída por turno antes e depois

Como prevenir tudo isso: muda UMA variável por vez

Primeiro só o model ID

Depois o effort

Só no fim o texto do prompt

Se você mexer nos três de uma vez, boa sorte pra saber quem causou o quê haha

E a mesma disciplina de comparar saída antes e depois vale pro seu dia a dia com agente: é o mesmo espírito de revisar o código gerado por outro modelo antes de confiar nele

O que muda fora do prompt: salvaguardas e desempenho

Tem coisa que tu vai sentir sem ter mexido em absolutamente nada

As salvaguardas de cibersegurança do Fable 5.1 disparam cerca de 60% menos intervenções por sessão, em média, dentro do Claude Code, em relação às salvaguardas anteriores do Fable 5

Pra quem trabalha com segurança e vivia sendo interrompido no meio de uma tarefa legítima, isso muda o humor do dia

Relembrando como era no Fable 5: requisições sinalizadas pelos classificadores (cibersegurança, biologia e química, destilação de modelo) são respondidas pelo Claude Opus 4.8, e o usuário é informado quando isso acontece

E no quesito desempenho, o número que a própria Anthropic divulgou no Terminal-Bench-Science 0.1:

Mais que o dobro, com o mesmo preço por token

Conclusão

Na prática, migrar é bem menos dramático do que o feed sugere

Troca o model ID de claude-fable-5 pra claude-fable-5-1 e revisa três coisas: tool_choice (nada de forçar), conversa append-only (raciocínio preso ao contexto anterior) e as instruções antigas de brevidade e de paralelismo

O resto do seu prompt tende a continuar funcionando, e o Fable 5 segue de pé como legado até pelo menos 09/06/2027 se você quiser rodar os dois lado a lado por um tempo

Próximo passo concreto antes de sair reescrevendo o seu system prompt: dá uma lida na página Claude Fable 5.1 system prompts, que traz os system prompts que a própria Anthropic usa no claude.ai e nos apps de iOS e Android

É uma referência de estilo boa demais pra ignorar, e é de graça 😀

Abraço e até o próximo post!

Matheus Battisti