Vous appelez claude-fable-5, la réponse semble normale, puis vous vérifiez le champ model : claude-opus-4-8. Votre requête a déclenché un classificateur de sécurité, Fable 5 a refusé de répondre, et un autre modèle est intervenu. Ce n'est pas un bug. C'est ainsi que Fable 5 est conçu pour fonctionner, et votre intégration devrait le gérer intentionnellement plutôt que par accident.
Nous avons abordé le raisonnement derrière cette architecture dans notre article explicatif sur les garde-fous de sécurité de Fable 5. Cet article est le complément pratique. Vous apprendrez ce qui déclenche un réacheminement, comment le détecter dans le code, comment le paramètre bêta fallbacks automatise la nouvelle tentative, et comment tester votre gestion des refus avant qu'un véritable utilisateur ne la rencontre.
Pourquoi Fable 5 réachemine certaines requêtes
Claude Fable 5 est livré avec des classificateurs de sécurité qui filtrent les requêtes entrantes. Ils surveillent trois domaines : la cybersécurité, la biologie et la chimie, et la distillation de modèles. Lorsqu'un classificateur est déclenché, Fable 5 refuse la requête. Sur les interfaces grand public de Claude, la requête est ensuite traitée par Claude Opus 4.8 et l'utilisateur est informé de ce qui s'est passé. Sur l'API, la récupération est de votre ressort, et c'est là qu'intervient le paramètre fallbacks.
Les classificateurs ne sont pas figés. Après la suspension de juin, Anthropic a réentraîné le classificateur contre une technique de "jailbreak" signalée ; la version mise à jour bloque plus de 99 % des tentatives. Fable 5 a été redéployé le 1er juillet 2026 avec le nouveau classificateur en place. Si vous avez interrompu votre intégration pendant la panne, notre centre Fable 5 est de retour contient la chronologie complète et les changements apportés.
Un autre élément de contexte est utile ici. Les classificateurs se situent en amont du modèle, pas à l'intérieur. Claude Mythos 5 est le même modèle sans classificateurs, et l'accès est restreint aux participants du Projet Glasswing. Plus de 95 % des sessions Fable n'impliquent aucun repli, et pour ces sessions, les performances de Fable 5 sont effectivement identiques à celles de Mythos 5. Nous détaillons les différences dans Fable 5 vs Mythos 5.
Ce que signifie un réacheminement pour votre application
Fable 5 et Opus 4.8 sont tous deux des modèles puissants, mais ils ne sont pas interchangeables d'un point de vue technique. Fable 5 utilise une fenêtre de contexte de 1M de jetons avec un maximum de 128K de sortie à 10 $ par million de jetons d'entrée et 50 $ par million de jetons de sortie ; Opus 4.8 a sa propre tarification et son propre profil de comportement. L'aperçu des modèles liste les spécifications actuelles pour les deux. Un prompt que vous avez optimisé pour Fable 5 peut produire des longueurs différentes, des formatages différents ou des modèles d'appel d'outils différents sur Opus 4.8.
Que cela importe dépend de votre cas d'utilisation :
- Généralement, non. Pour les assistants de chat, les agents et la génération générale, une réponse d'Opus 4.8 est une bonne réponse. Plus de 95 % des sessions ne subissent jamais de repli, l'effet combiné sur la qualité est donc faible.
- Cela importe pour les évaluations et les pipelines figés. Si vous effectuez des benchmarks sur un modèle spécifique, un réacheminement silencieux contamine vos données. Il en va de même pour l'extraction structurée avec des prompts optimisés pour le comportement exact d'un modèle.
- Cela importe pour l'attribution des coûts et la conformité. Les tentatives de repli sont facturées aux tarifs du modèle de service, et certaines équipes doivent enregistrer quel modèle a produit chaque sortie.
- Cela importe le plus près des domaines déclencheurs. Les outils de sécurité et le travail en sciences de la vie sont proches des cibles du classificateur, les faux positifs y sont donc plus fréquents qu'ailleurs. Si c'est votre cas, traitez la gestion des replis comme un chemin de code de première classe, et non comme un cas limite.
Détection programmatique d'un repli
Le signal fiable est le champ model de la réponse. Chaque réponse de l'API Messages nomme le modèle qui l'a produite, donc une requête envoyée à claude-fable-5 qui renvoie claude-opus-4-8 a été réacheminée. C'est le comportement standard de l'API Messages ; vous n'avez besoin d'aucune fonctionnalité bêta pour le lire.
Deux autres champs appartiennent à la même ligne de log. stop_reason vous indique si la requête a été purement et simplement refusée : une requête refusée sans gestion de repli renvoie HTTP 200 avec stop_reason défini sur "refusal" et aucun contenu utilisable, alors vérifiez-le avant de lire response.content. Et usage vous donne les décomptes de jetons dont vous avez besoin pour attribuer le coût au modèle qui les a facturés.
response = client.messages.create(
model="claude-fable-5",
max_tokens=16000,
messages=[{"role": "user", "content": prompt}],
)
if response.stop_reason == "refusal":
# Refusé sans fallback configuré : aucun contenu utilisable n'est revenu
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,
)
Si vous configurez l'API à partir de zéro, commencez par notre guide sur comment utiliser l'API Claude Fable 5 et ajoutez cette vérification une fois que vos premiers appels fonctionnent.
Le paramètre `fallbacks`
Sans aucune configuration de repli, une requête API refusée s'arrête simplement. Vous recevez le refus, votre utilisateur ne reçoit rien, et la logique de réessai est à écrire par vous. Le paramètre fallbacks déplace cette nouvelle tentative vers le serveur : lorsque Fable 5 refuse, l'API réexécute la même requête sur un modèle que vous nommez, au sein du même appel, et renvoie la réponse de ce modèle.
Le paramètre est en version bêta sur l'API Claude et la plateforme Claude sur AWS, documenté sur la page des refus et replis d'Anthropic. Vous l'activez avec un en-tête bêta, et au lancement, la seule cible de repli prise en charge est 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 si la requête a été réacheminée
La facturation fonctionne en votre faveur. Une requête refusée avant la génération de toute sortie n'est pas facturée du tout ; la tentative de récupération est facturée aux tarifs propres du modèle de repli. La détection reste la même qu'avant : response.model nomme le modèle qui a répondu.
Quelques limites à connaître. Le paramètre est rejeté sur l'API Batches et n'est pas disponible sur Amazon Bedrock, Google Vertex AI ou Microsoft Foundry ; sur ces plateformes, vous gérez les nouvelles tentatives côté client. Et si le modèle de repli refuse également, la réponse finale porte stop_reason: "refusal", alors gardez la branche de refus de la section précédente même avec les replis activés.
Concevoir votre politique de gestion
La détection et la réexécution sont des mécanismes. La vraie décision est ce que votre produit fait lorsqu'un repli se produit, et il existe trois politiques saines :
Accepter la réponse d'Opus. Convient aux produits de chat, aux assistants et à la plupart des agents. Activez les fallbacks, enregistrez l'événement et passez à autre chose. Votre utilisateur obtient une réponse en un seul aller-retour au lieu d'une erreur.
Réessayer avec une requête modifiée. Convient aux pipelines où la cohérence du modèle est plus importante que la latence. Ne renvoyez pas le même prompt à Fable 5 ; le classificateur qui l'a refusé une fois le refusera à nouveau. Reformulez-le pour vous éloigner du déclencheur, acheminez l'ensemble du travail vers Opus 4.8, ou mettez-le en file d'attente pour une révision humaine.
Le soumettre à l'utilisateur. Convient lorsque les clients paient spécifiquement pour Fable 5, ou lorsque la conformité exige une divulgation. Montrez quel modèle a répondu et laissez l'utilisateur décider de relancer ou non.
Quelle que soit la politique que vous choisissez, suivez votre taux de repli. Un taux proche de zéro correspond à la ligne de base de la plateforme. Un taux qui dépasse quelques pour cent signifie que vos invites frôlent un domaine déclencheur, et il vaut la peine de les réviser avant que le volume n'augmente.
Tester les chemins de refus avant la production
La gestion des replis est le genre de code qui fonctionne en démo et échoue six semaines plus tard, car les refus sont rares par conception. Vous ne pouvez pas attendre qu'un utilisateur réel déclenche le classificateur pour savoir si votre journalisation, vos réessais et votre interface utilisateur se comportent tous correctement. Vous devez provoquer le chemin vous-même.
Apidog rend cela pratique. Définissez le point de terminaison Claude Messages une seule fois, conservez votre clé API dans une variable d'environnement, et construisez un scénario de test à partir d'une petite suite de prompts de cas limites : quelques prompts liés à la sécurité et à la biologie qui se situent près des cibles du classificateur, plus des contrôles bénins qui ne devraient jamais être réacheminés. Puis vérifiez le corps de la réponse. Chaque test vérifie le champ model (le contrôle est-il resté sur claude-fable-5 ? le cas limite est-il revenu de claude-opus-4-8 ?) et le stop_reason (quelque chose a-t-il été refusé purement et simplement ?).
Exécutez le scénario selon un calendrier ou en CI. Lorsque Anthropic réentraîne le classificateur, comme ce fut le cas avant le redéploiement du 1er juillet, votre suite vous indique dans la journée si vos cas limites se comportent toujours comme votre code de gestion s'y attend. C'est une configuration de cinq minutes dans Apidog contre une surprise silencieuse en production.
FAQ
Le paramètre fallbacks entraîne-t-il des coûts supplémentaires ? Non. Une requête refusée avant de produire une sortie n'est pas facturée. Si le modèle de repli répond, vous payez les tarifs normaux par jeton de ce modèle pour la tentative de récupération. Vous n'êtes jamais facturé deux fois pour la même réponse.
Les requêtes liées à la sécurité déclencheront-elles toujours un repli ? Non. Les classificateurs ciblent les requêtes nuisibles en cybersécurité, en biologie et chimie, et en distillation de modèles, pas les sujets eux-mêmes. La plupart des travaux d'ingénierie de sécurité passent sans être affectés ; plus de 95 % de toutes les sessions ne voient aucun repli. Des faux positifs se produisent près de ces domaines, c'est précisément pourquoi vous testez le chemin et enregistrez le taux.
Je suis passé de Fable 5 lors de la suspension de juin. Est-il sûr de revenir ? Oui. Avec le redéploiement du 1er juillet, le classificateur réentraîné est en ligne et l'interface API est inchangée. Notre guide sur le retour à l'API Fable 5 explique comment le réactiver, et le paramètre fallbacks est l'élément que la plupart des équipes ajoutent lors du retour.
En résumé
Les réacheminements de Fable 5 sont une décision de conception, pas un incident, alors traitez-les comme tels dans votre code. Vérifiez response.model à chaque appel, conservez une branche de refus même avec les replis activés, optez pour le paramètre fallbacks à moins d'avoir une raison de ne pas le faire, et choisissez une politique pour ce que votre produit fait lorsque Opus 4.8 répond. Ensuite, prouvez que tout le chemin fonctionne : construisez la suite de cas limites dans Apidog, vérifiez model et stop_reason, et exécutez-la selon un calendrier. Téléchargez Apidog et vous pourrez exécuter la suite de refus avant votre prochain déploiement.