Como gerenciar recusas do Fable 5 na API

Você chama claude-fable-5, a resposta parece normal, e então você verifica o campo model: claude-opus-4-8. Sua solicitação acionou um classificador de segurança, Fable 5 recusou-se a responder, e outro modelo assumiu. Isso não é bug. É parte do design do Fable 5, e sua integração precisa tratar esse fluxo de forma explícita.

Experimente o Apidog hoje

Cobrimos o raciocínio por trás dessa arquitetura em nosso explicador sobre as salvaguardas de segurança do Fable 5. Este guia é o complemento prático: você verá o que aciona um redirecionamento, como detectá-lo no código, como usar o parâmetro beta fallbacks para automatizar a nova tentativa e como testar recusas antes que elas apareçam em produção.

Por que o Fable 5 redireciona algumas solicitações

Claude Fable 5 usa classificadores de segurança antes da execução do modelo. Eles analisam solicitações em três domínios:

• segurança cibernética;
• biologia e química;
• destilação de modelos.

Quando um classificador é acionado, o Fable 5 recusa a solicitação. Nas interfaces do Claude, a solicitação pode ser tratada pelo Claude Opus 4.8, com aviso ao usuário. Na API, a recuperação fica sob responsabilidade da sua aplicação — ou do parâmetro fallbacks, quando habilitado.

Os classificadores não são estáticos. Após a suspensão de junho, a Anthropic retreinou o classificador contra uma técnica de jailbreak relatada; a versão atualizada bloqueia mais de 99% das tentativas. O Fable 5 foi redesdobrado em 1º de julho de 2026 com o novo classificador ativo. Se você pausou sua integração durante a interrupção, veja a linha do tempo no hub Fable 5 está de volta.

Um detalhe importante: os classificadores ficam na frente do modelo, não dentro dele. Claude Mythos 5 é o mesmo modelo sem classificadores, com acesso restrito aos participantes do Projeto Glasswing. Mais de 95% das sessões do Fable não envolvem fallback; nesses casos, o desempenho do Fable 5 é efetivamente idêntico ao do Mythos 5. As diferenças estão detalhadas em Fable 5 vs Mythos 5.

O que um redirecionamento significa para seu aplicativo

Fable 5 e Opus 4.8 são modelos robustos, mas não são equivalentes do ponto de vista de engenharia.

Segundo a visão geral dos modelos, o Fable 5 opera com:

• janela de contexto de 1M tokens;
• saída máxima de 128K;
• preço de US$ 10 por milhão de tokens de entrada;
• preço de US$ 50 por milhão de tokens de saída.

O Opus 4.8 tem seu próprio preço, limites e perfil de comportamento. Um prompt ajustado para Fable 5 pode gerar respostas com comprimento, formatação ou padrões de chamada de ferramenta diferentes quando executado no Opus 4.8.

Na prática, isso afeta sua aplicação de formas diferentes:

• Assistentes e chats gerais: normalmente podem aceitar a resposta do Opus 4.8 sem impacto relevante.
• Benchmarks e avaliações: um fallback silencioso contamina os resultados se você mede um modelo específico.
• Extração estruturada: prompts ajustados para um modelo podem produzir formatos diferentes em outro.
• Custos e compliance: você precisa registrar qual modelo gerou cada saída e atribuir tokens ao modelo correto.
• Produtos próximos aos domínios do classificador: ferramentas de segurança e ciências da vida podem ver mais falsos positivos, então o caminho de fallback deve ser tratado como fluxo principal.

Detectando um fallback programaticamente

O sinal confiável é o campo model da resposta.

Se você enviou a solicitação para claude-fable-5 e recebeu claude-opus-4-8, houve redirecionamento. Esse campo está disponível nas respostas da Messages API; você não precisa habilitar beta apenas para lê-lo.

Registre também:

• stop_reason: indica se houve recusa direta;
• usage: fornece os tokens usados para atribuição de custo.

Uma recusa sem fallback configurado retorna HTTP 200 com stop_reason igual a "refusal" e sem conteúdo utilizável. Portanto, verifique esse campo antes de consumir response.content.

response = client.messages.create(
    model="claude-fable-5",
    max_tokens=16000,
    messages=[{"role": "user", "content": prompt}],
)

if response.stop_reason == "refusal":
    # Recusado sem fallback configurado:
    # não há conteúdo utilizável para o usuário.
    handle_refusal(response)

elif not response.model.startswith("claude-fable-5"):
    logger.info(
        "fallback served_by=%s in=%d out=%d",
        response.model,
        response.usage.input_tokens,
        response.usage.output_tokens,
    )

    handle_success(response)

else:
    handle_success(response)

Se você ainda está configurando a API, comece pelo guia de como usar a API Claude Fable 5 e adicione essa verificação assim que suas primeiras chamadas funcionarem.

Usando o parâmetro fallbacks

Sem fallback configurado, uma solicitação recusada para. Sua aplicação recebe a recusa e precisa decidir o que fazer.

O parâmetro fallbacks move a nova tentativa para o servidor. Quando o Fable 5 recusa, a API executa novamente a mesma solicitação em um modelo definido por você, dentro da mesma chamada, e retorna a resposta desse modelo.

O recurso está em beta na API Claude e na Claude Platform na AWS, documentado na página de recusas e fallback. Para usá-lo, envie o cabeçalho beta. No lançamento, o único alvo de fallback suportado é claude-opus-4-8.

response = client.beta.messages.create(
    model="claude-fable-5",
    max_tokens=16000,
    betas=["server-side-fallback-2026-06-01"],
    fallbacks=[{"model": "claude-opus-4-8"}],
    messages=[{"role": "user", "content": prompt}],
)

print(response.model)
# claude-opus-4-8 se a solicitação tiver sido redirecionada

A detecção continua igual:

if response.stop_reason == "refusal":
    handle_refusal(response)

elif response.model == "claude-opus-4-8":
    handle_fallback_response(response)

else:
    handle_fable_response(response)

A cobrança também segue o modelo que respondeu. Uma solicitação recusada antes de gerar saída não é cobrada; a tentativa de fallback é cobrada pelas taxas normais do modelo de fallback.

Limitações importantes:

• fallbacks é rejeitado na Batches API;
• não está disponível no Amazon Bedrock, Google Vertex AI ou Microsoft Foundry;
• nessas plataformas, você precisa implementar a nova tentativa no cliente;
• se o modelo de fallback também recusar, a resposta final terá stop_reason: "refusal".

Por isso, mantenha o branch de recusa mesmo com fallbacks habilitado.

Projetando sua política de tratamento

A parte mecânica é simples: detectar, registrar e tentar novamente. A decisão de produto é o que fazer quando o fallback acontece.

Use uma destas políticas.

1. Aceitar a resposta do Opus 4.8

Boa opção para:

• chats;
• assistentes;
• agentes gerais;
• geração de texto não sensível ao modelo específico.

Fluxo recomendado:

Fable 5 -> recusou -> fallback para Opus 4.8 -> registrar evento -> responder ao usuário

Você mantém a experiência em uma única ida e volta e evita expor um erro desnecessário.

2. Reprocessar com uma solicitação alterada

Boa opção para pipelines em que consistência do modelo importa mais do que latência.

Não envie o mesmo prompt novamente ao Fable 5. Se o classificador recusou uma vez, provavelmente recusará de novo.

Em vez disso:

• reformule o prompt para afastá-lo do gatilho;
• envie todo o trabalho ao Opus 4.8;
• ou coloque o item em revisão humana.

3. Mostrar o modelo ao usuário

Boa opção quando:

• clientes pagam especificamente pelo Fable 5;
• há exigência de auditoria;
• compliance exige rastreabilidade do modelo.

Nesse caso, inclua o modelo usado na interface ou nos metadados da resposta:

{
  "requested_model": "claude-fable-5",
  "served_by": "claude-opus-4-8",
  "fallback": true
}

Independentemente da política, monitore a taxa de fallback. Uma taxa próxima de zero está alinhada à linha de base da plataforma. Se a taxa passar de alguns por cento, seus prompts provavelmente estão próximos de um domínio de acionamento e devem ser revisados antes de escalar volume.

Testando caminhos de recusa antes da produção

Fallback é o tipo de código que funciona no demo e falha semanas depois, porque recusas são raras por design. Não espere um usuário real acionar o classificador para descobrir se logs, retries e interface se comportam corretamente.

Você precisa testar esse caminho de forma controlada.

Apidog torna esse fluxo prático:

1. Defina o endpoint de Mensagens do Claude.
2. Armazene sua chave de API em uma variável de ambiente.
3. Crie um cenário com prompts de borda.
4. Inclua controles benignos que não deveriam ser redirecionados.
5. Faça asserts sobre model e stop_reason.

Exemplo de validações:

Controle benigno:
- response.model deve ser claude-fable-5
- response.stop_reason não deve ser refusal

Caso de borda:
- response.model pode ser claude-opus-4-8
- se response.stop_reason == refusal, o fluxo de recusa deve ser acionado

Execute esse cenário em CI ou em um cronograma. Quando a Anthropic retreinar o classificador, como fez antes do redesdobramento de 1º de julho, seus testes indicam rapidamente se os casos de borda ainda se comportam como esperado.

FAQ

O parâmetro fallbacks custa extra?

Não. Uma solicitação recusada antes de produzir saída não é cobrada. Se o modelo de fallback responder, você paga as taxas normais por token desse modelo. Você não é cobrado duas vezes pela mesma resposta.

Prompts relacionados à segurança sempre acionam fallback?

Não. Os classificadores miram solicitações prejudiciais em segurança cibernética, biologia e química, e destilação de modelos — não os tópicos em si. A maior parte do trabalho legítimo de engenharia de segurança passa normalmente. Mais de 95% das sessões não veem fallback.

Saí do Fable 5 durante a suspensão de junho. É seguro voltar?

Sim. Com o redesdobramento de 1º de julho, o classificador retreinado está ativo e a superfície da API permanece inalterada. O guia sobre como voltar para a API Fable 5 mostra como reativá-la. Para a maioria das equipes, o principal ajuste ao voltar é adicionar fallbacks e monitoramento.

Conclusão

Redirecionamentos do Fable 5 são uma decisão de design, não um incidente. Trate-os como parte normal da integração:

• verifique response.model em toda chamada;
• mantenha um branch para stop_reason == "refusal";
• habilite fallbacks quando fizer sentido;
• registre tokens e modelo usado;
• defina uma política clara para respostas do Opus 4.8;
• teste casos de borda antes da produção.

Monte esse conjunto no Apidog, faça asserts sobre model e stop_reason, e execute em CI ou em um cronograma. Baixe o Apidog para validar o fluxo de recusas antes do próximo deploy.