Como fazer o rollout gradual do Claude Fable 5.1 em produção sem quebrar seu app?

Trocar de modelo em um produto com usuário real não é um commit, é uma operação

Fala aí, beleza? Em 1 de setembro de 2026 saiu o Claude Fable 5.1 como a versão de acesso público (API da Anthropic e plataformas de nuvem), enquanto o Mythos 5.1 ficou restrito a programas de acesso confiável

E a boa notícia é que, na base, migrar é uma troca de model ID: sai o claude-fable-5, entra o claude-fable-5-1

A má notícia é que existem mudanças que quebram, e elas não aparecem no seu "hello world", elas aparecem no loop de agente às 3 da manhã 😅

Então se liga: este post não é review de modelo, é um roteiro de adoção por etapas pra quem tem gente usando o produto do outro lado da tela…

Fable 5 x Fable 5.1: o que muda e afeta seu plano de rollout

Antes de mexer em qualquer coisa, vale olhar só o que muda DECISÃO de rollout, não o que muda no marketing

<table> <thead> <tr><th>Ponto</th><th>Fable 5</th><th>Fable 5.1</th></tr> </thead> <tbody> <tr><td>Model ID</td><td><code>claude-fable-5</code></td><td><code>claude-fable-5-1</code></td></tr> <tr><td>Preço de entrada</td><td>US$ 10 por milhão de tokens</td><td>US$ 10 por milhão de tokens (igual)</td></tr> <tr><td>Preço de saída</td><td>US$ 50 por milhão de tokens</td><td>US$ 50 por milhão de tokens (igual)</td></tr> <tr><td>Leitura de cache</td><td>sem dado nesta comparação</td><td>US$ 0,25 por milhão de tokens em cache reads</td></tr> <tr><td>Economia estimada pela Anthropic</td><td>sem dado nesta comparação</td><td>custo menor em cargas típicas, e a economia cresce em cargas altamente agênticas</td></tr> <tr><td>Limites</td><td>sem dado nesta comparação</td><td>1M de tokens de contexto por padrão, máximo de 128k de saída, mínimo de 512 tokens para prompt caching</td></tr> <tr><td><code>tool_choice</code> forçado (<code>any</code> ou <code>tool</code>)</td><td>usado hoje em muito código de agente</td><td>não suportado, retorna erro 400</td></tr> <tr><td>Thinking blocks entre modelos</td><td>sem dado nesta comparação</td><td>lê os thinking blocks do Claude Opus 5, mas o Opus 5 não lê os do 5.1</td></tr> <tr><td>Disponibilidade</td><td>sem dado nesta comparação</td><td>Pro, Max, Team e Enterprise, GA no Amazon Bedrock e na Claude Platform na AWS, e modelo parceiro no Gemini Enterprise Agent Platform do Google Cloud</td></tr> <tr><td>Aposentadoria anunciada</td><td>não antes de 1 de março de 2027 no Google Cloud</td><td>não antes de 1 de setembro de 2027</td></tr> </tbody> </table>

Formação Recomendada

Formação Claude Code

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

• 120 aulas
• 4 projetos
• 9h 45min

Conhecer formação

Lendo a tabela de forma prática: o preço por token de entrada e saída não muda, então a conta do rollout não é "vou gastar mais", é "o que quebra e quanto eu economizo no cache"

O que quebra está concentrado em duas linhas: tool_choice forçado e thinking blocks

E a linha de aposentadoria é a mais subestimada de todas, porque ela te dá permissão pra ir devagar 🙂

O que você precisa ter pronto antes de ligar o Fable 5.1

Antes do primeiro byte de tráfego real, essa é a lista do que precisa estar de pé:

• Acesso ao modelo no canal que você já usa: API da Anthropic, Amazon Bedrock ou Claude Platform na AWS, ou o Gemini Enterprise Agent Platform no Google Cloud
• Plano compatível: o Fable 5.1 está disponível para usuários Pro, Max, Team e Enterprise
• Logging de requisição e resposta funcionando, e funcionando nas DUAS versões, porque comparar sem log é achismo
• Suíte de evals existente, mesmo que pequena: a doc oficial de migração pede pra re-rodar as evals depois da troca
• Mapa das rotas do produto separadas por risco: o que é interno, o que é leitura, o que executa ação no mundo real
• Fallback para o model ID antigo configurado e testado, não só escrito no README

Sobre esse último item, um lembrete que não é paranoia: em 12 de junho de 2026 o Claude Fable 5 foi retirado do ar por uma diretiva de controle de exportação do Departamento de Comércio dos EUA, e voltou em 1 de julho, depois que o bloqueio caiu em 30 de junho

Ou seja, modelo sumir do seu app pode não ter nada a ver com o seu código

Tome cuidado com mais uma coisa: effort por mensagem, system messages com escopo de turno e thinking.display: "updates" estão em beta, atrás de headers

Coisa em beta é ótima pra testar, péssima como dependência de um rollout que precisa dar certo

Passo a passo do rollout gradual do Claude Fable 5.1

A ideia aqui é simples: rota pequena, comparar, logar, ampliar

Bora ver na prática?

1. Trocar o model ID em ambiente isolado

Primeiro movimento é o mais barato de todos, e ele NÃO acontece em produção:

- model: "claude-fable-5"
+ model: "claude-fable-5-1"

Com a troca feita, roda as cinco verificações que a documentação oficial de migração lista:

• remover chamadas com tool_choice forçado
• garantir que o histórico de mensagens seja append-only
• re-ajustar o parâmetro effort, que agora pode ser alterado no meio da conversa
• observar o novo padrão de uma chamada por turno nos loops de agente
• re-rodar as evals

O erro comum deste passo: tratar a troca como find and replace e ir direto pra produção porque "é só o ID". É só o ID até o primeiro agente com ferramenta forçada estourar

2. Escolher as rotas de baixo risco pro primeiro tráfego real

Aqui você olha aquele mapa de rotas e escolhe a MENOR fatia possível que ainda seja tráfego de verdade

Tráfego sintético mente, tráfego real conta a verdade

O erro comum deste passo: começar pela rota mais visível do produto porque é a que "todo mundo vai sentir a melhora". É também a que todo mundo vai sentir o incidente

3. Rodar comparação lado a lado das duas versões

Mesma entrada, os dois model IDs, saídas guardadas para leitura humana

Não precisa de framework da Nasa pra isso, precisa de disciplina: mesma entrada, mesmo prompt, mesma ferramenta disponível

O erro comum deste passo: comparar saídas de prompts diferentes e concluir qualquer coisa. Se o system prompt mudou junto, o teste morreu

4. Guardar log das duas versões com o model ID no registro

O campo mais importante do seu log durante o rollout é qual modelo respondeu aquela linha

E junto dele vão stop_reason e stop_details, porque é ali que mora a resposta que chega com status bonito e conteúdo vazio:

logger.info({
  model: response.model,
  stop_reason: response.stop_reason,
  stop_details: response.stop_details,
  request_id: requestId
})

O erro comum deste passo: logar só erro. Recusa não é erro HTTP, ela chega como 200 e passa batido no seu dashboard

5. Ampliar o tráfego por etapas, com critério de parada definido ANTES

O rateio de tráfego entre os dois model IDs fica por conta da sua aplicação: uma flag, um percentual, um grupo de usuários, o que já existir na sua stack

E o critério de parada precisa estar escrito antes de subir a fatia: qual métrica, qual limite, quem aperta o botão

O erro comum deste passo: definir o critério de parada no meio do incidente, quando todo mundo já está com o coração a mil e negociando consigo mesmo se "isso aí é ruído"

6. Acompanhar o custo, não só a qualidade

O preço de entrada e saída não mudou (US$ 10 e US$ 50 por milhão de tokens), então a diferença vem do cache read, que ficou em US$ 0,25 por milhão de tokens

A estimativa oficial da Anthropic é de custo menor em cargas típicas, e a economia fica maior ainda em cargas altamente agênticas

Só lembra do mínimo de 512 tokens para prompt caching: prompt curtinho não entra na brincadeira

O erro comum deste passo: comemorar economia olhando o total da fatura. Enquanto o tráfego está dividido entre dois modelos, o número que interessa é custo por requisição, quebrado por model ID

7. Se você usa Claude Code, defina o modelo de forma explícita

O Claude Code tem quatro formas oficiais de apontar o modelo:

# no start da sessão
claude --model <alias|nome>

# por variável de ambiente
ANTHROPIC_MODEL=<alias|nome>

Dentro de uma sessão que já está rodando, dá pra usar /model <alias|nome>, e pra deixar fixo existe o campo model no arquivo de settings

Na dúvida, use o nome completo claude-fable-5-1 em vez de apelido, assim o seu log não fica ambíguo depois

O erro comum deste passo: cada dev do time apontando o modelo de um jeito diferente, aí o "funciona na minha máquina" volta com roupa nova. Vale a mesma lógica de fazer o Claude Code perguntar antes de codar: combinar o comportamento antes evita retrabalho depois

8. Manter o caminho de volta ativo até o fim do rollout

Fallback não é o plano B que você escreve e esquece, é código que roda

Enquanto o rollout não fechar, o claude-fable-5 continua configurado e testado, e a rota de volta é um deploy de configuração, não uma refatoração

O erro comum deste passo: apagar o caminho antigo no dia em que o tráfego chega a 100%. O Fable 5.1 não será aposentado antes de 1 de setembro de 2027, tu tem tempo de sobra pra limpar isso com calma

Erros que aparecem no meio do rollout (e como resolver)

Erro 400 na chamada que usava ferramenta forçada

Sintoma: a requisição que funcionava volta com erro 400 depois da troca de model ID

Causa: uso forçado de ferramenta não é suportado no Fable 5.1, então tool_choice com any ou tool retorna 400 em claude-fable-5-1

Solução: a alternativa documentada é usar auto mais uma instrução explícita, com as tools declaradas com strict: true, ou trabalhar com saídas JSON

{
  "tool_choice": { "type": "auto" }
}

Prevenção: procure tool_choice no código inteiro ANTES de ligar a chave, e não só no arquivo que você lembra

Thinking blocks rejeitados ou descartados

Sintoma: o raciocínio some, ou a chamada seguinte reclama dos blocos que vieram antes

Causa: se o seu código edita mensagens anteriores, reconstrói system ou tools, ou faz compactação no cliente entre requisições, o claude-fable-5-1 rejeita ou descarta os thinking blocks seguintes

Solução: histórico append-only, sempre. Você adiciona ao fim, nunca reescreve o meio

Prevenção: esse é o clássico "funcionava antes", porque o Opus 5 não reclamava disso. Se o seu pipeline foi escrito assumindo que dava pra mexer no histórico, ele vai quebrar aqui

Resposta chega com HTTP 200 e sem o conteúdo esperado

Sintoma: status 200, latência normal, e o campo que a sua aplicação esperava simplesmente não está lá

Causa: recusa por classificador não vem como erro HTTP, a API retorna 200 com stop_reason: "refusal" e um objeto stop_details com a categoria da restrição, que quando presente é cyber, bio ou reasoning_extraction

Solução: tratar recusa no código, não só o status:

if (response.stop_reason === "refusal") {
  const category = response.stop_details?.category || "generica"
  return handleRefusal(category)
}

Prevenção: stop_details pode vir null, e nesse caso o certo é tratar como recusa genérica em vez de estourar exceção no seu parser

E tem o lado do bolso: recusa na etapa de prompt, bloqueada antes da inferência começar, não é cobrada, mas recusa no meio do stream é cobrada pelos tokens gerados antes do bloqueio

Quebra ao misturar modelos no mesmo histórico

Sintoma: a conversa funciona até o momento em que o roteamento manda aquele turno pro outro modelo, e aí desanda

Causa: a compatibilidade de thinking blocks é assimétrica: o Fable 5.1 lê os blocos do Claude Opus 5, mas o Opus 5 não lê os blocos do Fable 5.1

Solução: nada de roteamento cruzado DENTRO da mesma conversa durante o rollout. A divisão é por conversa, por rota ou por usuário, nunca por turno

Prevenção: aquele roteador esperto que escolhe modelo por complexidade da mensagem é exatamente o tipo de coisa que precisa ficar congelada enquanto o rollout roda

Por onde começar: rotas de baixo risco em produtos reais

Fluxos internos antes de fluxos com usuário final. Painel do time, ferramenta de suporte, script de triagem interna: se a saída ficar estranha, quem vê é gente que sabe o que está acontecendo. Observe formato de saída e uso de ferramenta, que são as duas coisas que mudam de comportamento aqui

Rotas de leitura antes de rotas que executam ação. Resumo, classificação, extração e busca falham de forma barata. Já o fluxo que dispara e-mail, cria cobrança ou altera dado do cliente falha caro, e esse entra depois, com log completo

Cargas com muito cache read primeiro, se o seu objetivo é custo. É nelas que o preço de US$ 0,25 por milhão de tokens aparece mais rápido na conta, lembrando do mínimo de 512 tokens para o prompt caching valer

Claude Code, se o seu time já usa no dia a dia. Aqui o ganho documentado é bem concreto: cerca de 60% menos falsos positivos de cibersegurança em relação à versão anterior, o que muda a vida de quem revisa código com o agente

Sessão de agente é longa por natureza, então vale combinar esse teste com o hábito de retomar a tarefa sem refazer tudo quando o trabalho passa de um dia pro outro

Conclusão

No fim das contas, o rollout gradual é justamente o que separa "troquei um model ID" de "tivemos um incidente na sexta à noite"

O ciclo é curtinho e repetível: rota pequena, comparar lado a lado, logar as duas versões com o model ID no registro, ampliar por etapas

O próximo passo concreto é bem menor do que parece: rode as cinco verificações da doc oficial de migração em ambiente isolado, e depois ligue o claude-fable-5-1 em UMA rota só

Como o Fable 5.1 não será aposentado antes de 1 de setembro de 2027, ninguém aqui está com faca no pescoço, então dá pra fazer certo em vez de fazer rápido 🙂

Me conta depois como foi o seu primeiro dia com tráfego real dividido, tenho curiosidade de saber o que quebrou primeiro haha

até o próximo post!