Claude Fable 5 com Fallback para Opus 4.8 Explicado

Sou a Dora. Tenho roteado tráfego de produção para o Claude Fable 5 há cerca de uma semana. Tempo suficiente para observar o comportamento de fallback disparar, curto o suficiente para que eu ainda me lembre do que me surpreendeu. Este texto é para quem acabou de integrar o Fable 5 e viu stop_reason: "refusal" retornar em um prompt perfeitamente inocente — ou para quem está prestes a integrar e prefere não descobrir isso às 2 da manhã.

A versão curta: um fallback do Claude Fable 5 não é um erro. É uma parte documentada de como o modelo é lançado. Quando um classificador de segurança recusa uma requisição, a API retorna HTTP 200 com um stop reason de recusa, e a Anthropic oferece três maneiras de retentar essa requisição no Claude Opus 4.8 sem perder o usuário. Se você tratar isso como uma exceção a ser capturada, vai lidar mal com a situação. Se tratar como uma decisão de roteamento, encaixa de forma limpa.

Vou explicar o que desencadeia um fallback, o que a API realmente retorna, como implementar o retry e o que isso significa para o faturamento.

Por que o Opus 4.8 importa no roteamento do Fable 5

Salvaguardas do Fable 5 e comportamento de fallback

O Fable 5 é o modelo mais capaz amplamente lançado pela Anthropic, e ele vem com classificadores de segurança que ficam na frente do modelo. Quando um classificador sinaliza uma requisição, o Fable 5 não responde. A requisição pode ser executada novamente no Claude Opus 4.8, e o usuário é informado sobre isso. Isso está documentado no anúncio da Anthropic sobre Claude Fable 5 e Mythos 5.

A Anthropic afirma que os classificadores disparam em menos de 5% das sessões em média. Esse número corresponde ao que tenho visto até agora. Na maioria das vezes, você não percebe que o mecanismo de fallback está lá.

Contexto de acesso restrito ao Mythos 5

O Mythos 5 é o mesmo modelo subjacente ao Fable 5, sem os classificadores. Ele não está disponível para o público em geral. O acesso é feito através do Projeto Glasswing, que atualmente é limitado a parceiros de cibersegurança e um conjunto menor de pesquisadores de biologia sob um programa de acesso confiável separado. Se você ainda não tem acesso, está construindo sobre o Fable 5. A nomenclatura anthropic mythos pode ser confusa aqui — Mythos é a classe do modelo, e Fable 5 é o membro disponível publicamente dessa classe.

Para o restante deste texto, assuma que seu código está chamando o Fable 5.

Por que o fallback é uma funcionalidade do produto, não apenas um caminho de erro

Essa é a parte que demorei um pouco para internalizar. O Opus 4.8 não é uma experiência degradada. É o tier Opus da geração anterior, ainda capaz, e não executa os mesmos classificadores. Então a lógica de roteamento é: tente o modelo mais forte primeiro, e se um classificador recusar, recaia no modelo que era o carro-chefe dois meses atrás. O usuário recebe uma resposta de qualquer forma. Esse é o design completo.

Um fallback não é um relatório de bug. É uma decisão de roteamento que seu código toma em nome do usuário.

O que desencadeia fallback ou recusa

Categorias de cibersegurança, biologia/química e destilação

O campo stop_details.category informa qual classificador disparou. As categorias publicadas no Fable 5 incluem cyber, bio e reasoning_extraction — a última é para requisições que parecem tentativas de fazer engenharia reversa ou destilar saídas do modelo sob os Termos de Serviço da Anthropic. A lista atual e o comportamento exato estão na documentação de recusas e fallback nos docs da API Claude.

Não vi bio disparar em nada que faço. Vi cyber disparar duas vezes. Ambas as vezes o prompt era relacionado à segurança, mas inofensivo — uma era uma pergunta sobre como um formato de log específico era estruturado, a outra era sobre um CVE com anos de existência e totalmente corrigido. Nenhuma foi uma tentativa de fazer nada. O classificador viu o padrão de superfície e recusou.

Falsos positivos e salvaguardas conservadoras

A Anthropic foi explícita de que os classificadores são ajustados de forma conservadora — mais rigorosos do que seria ideal, na própria formulação deles. Esse é o trade-off. Eles preferem recusar uma pergunta inofensiva sobre cyber e rotear para o Opus 4.8 do que deixar passar um caso real de uso indevido. O fallback existe exatamente porque a taxa de falsos positivos é diferente de zero por design.

Se você constrói com essa premissa, as surpresas desaparecem. Se você constrói assumindo que recusas são emergências raras, a primeira vai quebrar algo.

O que a API retorna quando requisições são recusadas

A resposta é um HTTP 200 normal. O formato é aproximadamente:

{
  "role": "assistant",
  "content": [],
  "stop_reason": "refusal",
  "stop_details": {
    "type": "refusal",
    "category": "cyber",
    "explanation": "..."
  },
  "usage": { "input_tokens": 106, "output_tokens": 1 }
}

Você não é cobrado por uma requisição recusada antes de qualquer saída ser gerada. Se você continuar a mesma conversa sem redefinir o turno recusado, continuará recebendo recusas — a documentação de recusas em streaming da Anthropic cobre isso especificamente. Remova ou reescreva o turno antes de retentar.

O campo category é informativo. Não ramifique o texto voltado ao usuário com base nele. Ele também pode ser null em algumas superfícies, incluindo resultados em batch, então detecte recusas verificando stop_reason diretamente.

Como os desenvolvedores devem implementar o fallback

Três maneiras. Escolha uma. Não as empilhe.

Parâmetro de fallback do lado do servidor

O caminho mais limpo na API Claude direta ou na Plataforma Claude na AWS é o parâmetro fallbacks com opt-in. Atualmente está em beta. Você adiciona uma lista de modelos de fallback à requisição, e se o Fable 5 recusar, a Anthropic executa a requisição novamente no próximo modelo da lista — Opus 4.8 no lançamento — e retorna essa resposta para você. Uma única ida e volta do seu lado.

Não é compatível com a API de Lotes de Mensagens, e atualmente não está disponível no Amazon Bedrock, Vertex AI ou Microsoft Foundry. Para esses, use o middleware do SDK.

Middleware do SDK do lado do cliente

Os SDKs da Anthropic incluem um middleware de fallback de recusa. Você configura um cliente uma vez com uma lista de modelos de fallback, e ele cuida do retry, do cabeçalho beta para o crédito de fallback e do gerenciamento do histórico da conversa. O modelo de aceitação fica fixado para os turnos subsequentes para que a conversa permaneça consistente.

Usei o middleware. A configuração é um bloco na construção do cliente, e depois disso client.beta.messages.create se comporta exatamente como o cliente regular — exceto que as recusas são roteadas automaticamente. Esse é o caminho que eu recomendaria se você estiver no Bedrock, Vertex ou Foundry, ou se simplesmente quiser o mesmo caminho de código em todos os lugares.

Registrando resultados do classificador sem expor conteúdo sensível

Quando uma recusa acontece, registre o suficiente para depurar — modelo, timestamp, categoria — mas não registre o prompt completo nos logs da sua aplicação se puder ser sensível. O classificador já o sinalizou. Trate o prompt como algo que você quer tratar, não como algo que quer indexado na sua stack de observabilidade.

Mantenho um contador em stop_details.category e uma taxa de amostragem de payloads completos apenas para ambientes de desenvolvimento. Isso te dá padrões de falsos positivos sem vazar o conteúdo.

Faturamento e experiência do usuário

Evitando custo duplicado de cache de prompt onde suportado

Se sua requisição original ao Fable 5 usou um prefixo de cache longo, você não quer pagar por essa leitura de cache duas vezes ao retentar no Opus 4.8. O crédito de fallback cuida disso. Quando uma recusa gera um crédito, você recebe um fallback_credit_token opaco na resposta, e passá-lo na requisição de retry evita a cobrança duplicada de cache. O mecanismo e o cabeçalho beta estão documentados no guia de crédito de fallback do AWS Bedrock, e o middleware do SDK envia o cabeçalho para você. O token dura cinco minutos.

Se você usou o parâmetro fallbacks do lado do servidor ou o middleware, isso é tratado automaticamente. Se você está fazendo um retry manual, precisa configurar isso você mesmo.

Explicando o fallback para os usuários finais

Um fallback não é uma falha. Mas o usuário precisa saber que a resposta veio de um modelo diferente, tanto por transparência quanto porque o Opus 4.8 pode responder de forma diferente. Mostro uma pequena nota inline — algo como “Respondido com um modelo de fallback” — e conecto a uma página de ajuda que explica o que isso significa. Não um pedido de desculpa. Um rótulo.

O que não faço é expor a categoria para o usuário. “cyber” ou “bio” fora de contexto soa como uma acusação, e geralmente não é.

Mantendo o comportamento de segurança observável

Acompanhe a taxa de recusa como um SLI normal. Se ela aumentar semana após semana, você quer saber — seja porque seu uso está se deslocando para categorias sinalizadas, ou um classificador foi reajustado. Ambos são operacionalmente interessantes. Ambos são invisíveis se você não mede.

Perguntas frequentes

Por que o Fable 5 faz fallback para o Opus 4.8?

Porque o Fable 5 vem com classificadores de segurança que podem recusar requisições em categorias específicas (cyber, biologia, química, destilação). Quando isso acontece, o Fable 5 não responde, e a requisição pode ser executada novamente no Opus 4.8 — que não executa os mesmos classificadores — para que o usuário ainda receba uma resposta.

Como as equipes de API devem lidar com uma resposta de recusa?

Trate como um resultado normal da API, não como uma exceção. Verifique stop_reason == "refusal". Ou use o parâmetro fallbacks do lado do servidor, o middleware do SDK, ou implemente um retry manual com o token de crédito de fallback. Redefina o turno recusado antes de continuar a conversa, ou você continuará recebendo recusas.

Fallback significa que a requisição é insegura?

Não. Os classificadores são ajustados de forma conservadora, então requisições inofensivas em categorias adjacentes às vezes vão dispará-los. A Anthropic afirma que menos de 5% das sessões chegam a um fallback. Trate uma recusa como um sinal de roteamento, não como um veredicto sobre o usuário.

Quando o Opus 4.8 deve ser o modelo padrão?

Quando você não precisa do teto de raciocínio do Fable 5 e quer evitar a lógica de roteamento completamente. O Opus 4.8 custa aproximadamente metade do custo por token e não executa os mesmos classificadores. Para trabalho rotineiro, o Opus 4.8 costuma ser o padrão mais sensato. Para execuções agênticas de longo horizonte, Fable 5 com um fallback configurado é a escolha certa.

Conclusão

Um fallback do Claude Fable 5 é um evento de roteamento, não um erro. Os classificadores disparam de forma conservadora, a API retorna um 200 limpo, e a Anthropic oferece um parâmetro do lado do servidor e um middleware de SDK que cuidam do retry, do faturamento de cache e do histórico da conversa sem você precisar escrever muito código.

O trabalho de implementação é pequeno. A mudança de perspectiva é a parte mais difícil. Uma vez que você para de tratar a recusa como uma exceção, o resto se encaixa.

Ainda estou observando com que frequência o classificador de cyber dispara em perguntas legítimas. Mais uma semana de dados deve me dizer se preciso ajustar algo do meu lado. Continuo na próxima semana.

Posts anteriores: