Claude Fable 5 et le basculement vers Opus 4.8 expliqué

C’est Dora. Je fais transiter du trafic de production vers Claude Fable 5 depuis environ une semaine. Assez longtemps pour observer le comportement de fallback se déclencher, assez peu pour que je me souvienne encore de ce qui m’a surpris. Cet article s’adresse à quiconque vient d’intégrer Fable 5 et a vu stop_reason: "refusal" revenir sur une invite parfaitement innocente — ou qui est sur le point de le faire et préférerait ne pas le découvrir à 2 h du matin.

En bref : un fallback Claude Fable 5 n’est pas une erreur. C’est une partie documentée du fonctionnement du modèle. Lorsqu’un classificateur de sécurité refuse une requête, l’API retourne un HTTP 200 avec un stop reason de refus, et Anthropic vous donne trois façons de réessayer cette requête sur Claude Opus 4.8 sans perdre l’utilisateur. Si vous le traitez comme une exception à attraper, vous le gérerez mal. Si vous le traitez comme une décision de routage, il s’intègre proprement.

Je vais passer en revue ce qui déclenche un fallback, ce que l’API*** retourne réellement, comment implémenter la nouvelle tentative, et ce que cela signifie pour la facturation.***

Pourquoi Opus 4.8 est important dans le routage de Fable 5

Protections de Fable 5 et comportement de fallback

Fable 5 est le modèle le plus capable d’Anthropic à large diffusion, et il est livré avec des classificateurs de sécurité qui se positionnent devant le modèle. Lorsqu’un classificateur signale une requête, Fable 5 ne répond pas. La requête peut être relancée sur Claude Opus 4.8, et l’utilisateur en est informé. Cela est documenté dans l’annonce par Anthropic de Claude Fable 5 et Mythos 5.

Anthropic indique que les classificateurs se déclenchent sur moins de 5 % des sessions en moyenne. Ce chiffre correspond à ce que j’ai observé jusqu’ici. La plupart du temps, vous ne remarquez pas que la machinerie de fallback est là.

Contexte d’accès restreint à Mythos 5

Mythos 5 est le même modèle sous-jacent que Fable 5, sans les classificateurs. Il n’est pas disponible en général. L’accès passe par le Project Glasswing, actuellement limité aux partenaires en cybersécurité et à un ensemble plus restreint de chercheurs en biologie dans le cadre d’un programme d’accès de confiance distinct. Si vous n’avez pas encore accès, vous construisez sur Fable 5. La dénomination anthropic mythos peut être source de confusion ici — Mythos est la classe de modèle, et Fable 5 est le membre de cette classe disponible publiquement.

Pour le reste de cet article, considérez que votre code appelle Fable 5.

Pourquoi le fallback est une fonctionnalité produit, pas juste un chemin d’erreur

C’est la partie qui m’a pris un moment à intégrer. Opus 4.8 n’est pas une expérience dégradée. C’est le niveau Opus de la génération précédente, toujours capable, et il ne fait pas tourner les mêmes classificateurs. La logique de routage est donc : essayer d’abord le modèle le plus puissant, et si un classificateur refuse, passer au modèle qui était le modèle phare il y a deux mois. L’utilisateur obtient une réponse dans tous les cas. C’est toute la conception.

Un fallback n’est pas un rapport de bug. C’est une décision de routage que votre code prend au nom de l’utilisateur.

Ce qui déclenche un fallback ou un refus

Cybersécurité, biologie/chimie et catégories de distillation

Le champ stop_details.category vous indique quel classificateur s’est déclenché. Les catégories publiées sur Fable 5 incluent cyber, bio, et reasoning_extraction — la dernière concerne les requêtes qui ressemblent à des tentatives d’ingénierie inverse ou de distillation des sorties du modèle en vertu des Conditions d’utilisation d’Anthropic. La liste actuelle et le comportement exact se trouvent dans la documentation sur les refus et le fallback dans la doc API Claude.

Je n’ai pas vu bio se déclencher sur quoi que ce soit que je fais. J’ai vu cyber se déclencher deux fois. Les deux fois, l’invite était liée à la sécurité mais inoffensive — l’une était une question sur la structure d’un format de log spécifique, l’autre portait sur une CVE vieille de plusieurs années et entièrement corrigée. Aucune n’était une tentative de faire quoi que ce soit. Le classificateur a vu le schéma de surface et a refusé.

Faux positifs et protections conservatrices

Anthropic a été explicite sur le fait que les classificateurs sont réglés de manière conservative — plus stricts que l’idéal, dans leur propre formulation. C’est le compromis. Ils préfèrent refuser une question cyber inoffensive et vous router vers Opus 4.8 plutôt que de manquer un vrai cas d’utilisation abusive. Le fallback existe précisément parce que le taux de faux positifs est non nul par conception.

Si vous construisez avec cette hypothèse, les surprises disparaissent. Si vous construisez en supposant que les refus sont de rares urgences, le premier casse quelque chose.

Ce que l’API retourne quand les requêtes sont refusées

La réponse est un HTTP 200 normal. La forme est approximativement :

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

Vous n’êtes pas facturé pour une requête refusée avant qu’une sortie soit générée. Si vous continuez la même conversation sans réinitialiser le tour refusé, vous continuerez à recevoir des refus — la documentation d’Anthropic sur les refus en streaming couvre cela spécifiquement. Supprimez ou réécrivez le tour avant de réessayer.

Le champ category est informatif. Ne le branchez pas sur du texte côté utilisateur. Il peut aussi être null dans certaines surfaces, y compris les résultats par lots, donc détectez les refus en vérifiant directement stop_reason.

Comment les développeurs devraient implémenter le fallback

Trois façons. Choisissez-en une. Ne les cumulez pas.

Paramètre de fallback côté serveur

Le chemin le plus propre sur l’API Claude directe ou Claude Platform sur AWS est le paramètre opt-in fallbacks. Il est actuellement en bêta. Vous ajoutez une liste de modèles de fallback à la requête, et si Fable 5 refuse, Anthropic relance la requête sur le modèle suivant dans la liste — Opus 4.8 au lancement — et vous retourne cette réponse. Un seul aller-retour de votre côté.

Non pris en charge sur l’API Message Batches, et non disponible actuellement sur Amazon Bedrock, Vertex AI, ou Microsoft Foundry. Pour ceux-ci, utilisez le middleware SDK.

Middleware SDK côté client

Les SDK Anthropic livrent un middleware de fallback sur refus. Vous configurez un client une fois avec une liste de modèles de fallback, et il gère la nouvelle tentative, l’en-tête bêta pour le crédit de fallback, et la gestion de l’historique de conversation. Le modèle acceptant est épinglé pour les tours suivants afin que la conversation reste cohérente.

J’ai utilisé le middleware. La configuration est un bloc à la construction du client, et après cela client.beta.messages.create se comporte exactement comme le client normal — sauf que les refus sont routés automatiquement. C’est le chemin que je recommanderais si vous êtes sur Bedrock, Vertex, ou Foundry, ou si vous voulez simplement le même chemin de code partout.

Journalisation des résultats du classificateur sans exposer de contenu sensible

Quand un refus se produit, journalisez suffisamment pour déboguer — modèle, horodatage, catégorie — mais ne journalisez pas l’invite complète dans vos logs d’application si elle peut être sensible. Le classificateur l’a déjà signalée. Traitez l’invite comme quelque chose que vous voulez gérer, pas quelque chose que vous voulez indexer dans votre pile d’observabilité.

Je maintiens un compteur sur stop_details.category et un taux d’échantillonnage de payloads complets uniquement pour les environnements de développement. Cela vous donne des patterns de faux positifs sans divulguer le contenu.

Facturation et expérience utilisateur

Éviter le coût dupliqué du cache de prompt là où c’est pris en charge

Si votre requête Fable 5 originale utilisait un long préfixe mis en cache, vous ne voulez pas payer cette lecture de cache deux fois quand vous réessayez sur Opus 4.8. Le crédit de fallback gère cela. Quand un refus génère un crédit, vous obtenez un fallback_credit_token opaque dans la réponse, et le passer sur la requête de nouvelle tentative évite le double coût de cache. Le mécanisme et l’en-tête bêta sont documentés dans le guide de crédit de fallback d’AWS Bedrock, et le middleware SDK envoie l’en-tête pour vous. Le token est valable cinq minutes.

Si vous avez utilisé le paramètre fallbacks côté serveur ou le middleware, c’est géré. Si vous faites une nouvelle tentative manuelle, vous devez le câbler vous-même.

Expliquer le fallback aux utilisateurs finaux

Un fallback n’est pas un échec. Mais l’utilisateur doit savoir que la réponse provient d’un modèle différent, à la fois pour la transparence et parce qu’Opus 4.8 peut répondre différemment. J’affiche une petite note en ligne — quelque chose comme “Répondu avec un modèle de fallback” — et je renvoie vers une page d’aide qui explique ce que cela signifie. Pas une excuse. Un libellé.

Ce que je ne fais pas, c’est exposer la catégorie à l’utilisateur. “cyber” ou “bio” hors contexte ressemble à une accusation, et ce n’est généralement pas le cas.

Rendre le comportement de sécurité observable

Suivez le taux de refus comme un SLI normal. S’il dérive à la hausse semaine après semaine, vous voulez le savoir — soit votre utilisation évolue vers des catégories signalées, soit un classificateur a été reconfiguré. Les deux sont opérationnellement intéressants. Les deux sont invisibles si vous ne mesurez pas.

FAQ

Pourquoi Fable 5 bascule-t-il sur Opus 4.8 ?

Parce que Fable 5 est livré avec des classificateurs de sécurité qui peuvent refuser des requêtes dans des catégories spécifiques (cyber, biologie, chimie, distillation). Quand cela se produit, Fable 5 ne répond pas, et la requête peut être relancée sur Opus 4.8 — qui ne fait pas tourner les mêmes classificateurs — afin que l’utilisateur obtienne quand même une réponse.

Comment les équipes API devraient-elles gérer une réponse de refus ?

Traitez-la comme un résultat API normal, pas une exception. Vérifiez stop_reason == "refusal". Utilisez soit le paramètre fallbacks côté serveur, le middleware SDK, soit implémentez une nouvelle tentative manuelle avec le token de crédit de fallback. Réinitialisez le tour refusé avant de continuer la conversation, sinon vous continuerez à recevoir des refus.

Un fallback signifie-t-il que la requête est dangereuse ?

Non. Les classificateurs sont réglés de manière conservative, donc des requêtes inoffensives dans des catégories adjacentes les déclencheront parfois. Anthropic indique que moins de 5 % des sessions rencontrent un fallback. Traitez un refus comme un signal de routage, pas comme un verdict sur l’utilisateur.

Quand Opus 4.8 devrait-il être le modèle par défaut ?

Quand vous n’avez pas besoin du plafond de raisonnement de Fable 5 et que vous voulez éviter entièrement la logique de routage. Opus 4.8 coûte environ la moitié du prix par token et ne fait pas tourner les mêmes classificateurs. Pour le travail de routine, Opus 4.8 est souvent le meilleur défaut. Pour les exécutions agentiques à longue portée, Fable 5 avec un fallback configuré est la bonne approche.

Conclusion

Un fallback Claude Fable 5 est un événement de routage, pas une erreur. Les classificateurs se déclenchent de manière conservative, l’API retourne un 200 propre, et Anthropic vous donne un paramètre côté serveur et un middleware SDK qui gèrent la nouvelle tentative, la facturation du cache, et l’historique de conversation sans que vous ayez à écrire beaucoup de code.

Le travail d’implémentation est modeste. Le changement de cadrage est la partie la plus difficile. Une fois que vous arrêtez de traiter le refus comme une exception, le reste suit.

Je continue d’observer la fréquence à laquelle le classificateur cyber se déclenche sur des questions légitimes. Une semaine de données supplémentaire devrait me dire si j’ai besoin d’ajuster quoi que ce soit de mon côté. Suite la semaine prochaine.

Articles précédents :