Fable 5.2 : migrer sans erreur 400, les 4 pièges de la doc

Le 9 novembre, Anthropic a sorti Claude Fable 5.2 et Mythos 5.2. Le prix baisse de 20 %, la vitesse de génération monte de 30 %. Et la doc annonce quatre changements susceptibles de casser votre code. Ce tuto s'adresse à ceux qui appellent l'API Claude depuis leurs propres scripts, agents ou automatisations : on déroule la migration dans l'ordre, avec les commandes à lancer et les erreurs à attendre.

Précision d'honnêteté : le modèle a un jour. Ce que vous lisez s'appuie sur la documentation officielle et sur les premiers tests publiés par des tiers, pas sur une mise en production de notre côté. Quand un chiffre vient d'Anthropic, on le dit. Quand il vient d'ailleurs, on cite la source.

Nous avions déjà publié une migration vers Fable 5.1. Voici ce qui a bougé depuis : une baisse de prix, un contrôle d'API étendu à tous les comptes, et un modèle qui se comporte différemment à prompt identique.

Fable 5.2 en une page : ID, prix, limites

Les specs viennent de la page « What's new in Claude Fable 5.2 ». L'ID est claude-fable-5-2 sur l'API Claude, Claude Platform on AWS, Google Cloud et Microsoft Foundry, et anthropic.claude-fable-5-2 sur Amazon Bedrock. Fenêtre de contexte : 1 million de tokens. Sortie maximale : 128 000 tokens. La réflexion adaptative est toujours active. Le tokenizer est celui introduit avec Opus 4.7, donc rien ne bouge sur le décompte par rapport à Fable 5.1.

Mythos 5.2 est le même modèle sans les garde-fous cyber et biologie. Il n'est accessible qu'aux organisations validées par les programmes de vérification d'Anthropic. Pour une PME, c'est Fable qui compte.

Sources : documentation Anthropic pour Fable, eesel pour Opus 5.5, Kingy pour Sol. Le batch divise les tarifs Fable par deux (4 $/20 $). Le mode rapide, jusqu'à 2,5 fois plus véloce, les double (16 $/80 $).

Premier réflexe à avoir : Fable coûte toujours deux fois le prix d'Opus 5.5 par token. La baisse de 20 % rapproche Fable de ses propres anciens tarifs, pas d'Opus. On y revient plus bas, avec les coûts par tâche.

Comment migrer de Fable 5.1 à Fable 5.2 : le changement d'ID

C'est la partie facile. Dans le code, remplacez claude-fable-5-1 par claude-fable-5-2. Dans Python, c'est une ligne :

model = "claude-fable-5-1"  # avant
model = "claude-fable-5-2"  # après

Si vous utilisez Claude Code, la doc de migration propose de déléguer le travail : /claude-api migrate this project to claude-fable-5-2. D'après Developers Digest, la version 2.1.321 de Claude Code fait de claude-fable-5-2 le modèle Fable par défaut, et les choix 5.1 enregistrés basculent aussitôt sur les comptes Pro et Max. Pour rester sur l'ancien : /model claude-fable-5-1. Fable 5.1 reste disponible en modèle hérité, selon TeamoRouter (la doc ne donne pas de date de retrait que nous ayons pu vérifier).

Règle n°1 : fixez l'effort vous-même

Le défaut de l'API est high. Celui d'Opus 5.5 était medium. Si vous migrez depuis Opus sans toucher à rien, vos requêtes tournent un cran plus haut, donc plus lentes et plus chères. La doc de migration demande de fixer effort explicitement puis de relancer un balayage medium / high / xhigh sur vos propres évals.

Anthropic donne ses repères. low : réponses rapides, tâches bien spécifiées, sous-agents à gros volume. medium : codage interactif et travail courant. high : codage difficile, recherche, longues exécutions autonomes. xhigh : seulement si vous avez mesuré un gain. max : pour mesurer le plafond du modèle. L'éditeur précise que l'essentiel du gain est déjà là à high.

Un détail qui change les habitudes : les lignes de prompt du genre « réponds directement, sans réfléchir » n'ont plus d'effet à medium et au-dessus. Anthropic recommande de les supprimer et de baisser l'effort. Si vous avez des prompts système hérités de Fable 5.1 qui contiennent cette consigne, c'est le premier endroit où chercher des tokens perdus.

Piège n°1 : le prefix check et l'erreur « bound to a different conversation »

C'est le changement le plus sournois. Le modèle conserve ses blocs de réflexion d'un tour à l'autre (« preserved thinking »). L'API vérifie que rien de ce qui précède un bloc n'a changé depuis sa production : ni le system, ni les tools, ni un message antérieur. Sur Fable 5.1, ce contrôle ne touchait que les comptes créés à partir du 31 août 2026. Sur Fable 5.2, tous les comptes sont concernés.

Symptôme : une erreur HTTP 400 dont le message contient « The block is bound to a different conversation ». Renvoyer la même requête ne règle rien. Un code qui tournait sans erreur sur un compte ancien avec Fable 5.1 peut donc tomber le jour du changement d'ID.

Vous n'avez rien à faire si Claude Code, claude.ai, Managed Agents ou l'Agent SDK construisent vos requêtes. Si c'est votre code qui assemble le tableau messages, vous êtes tranquille uniquement si ces trois conditions tiennent : system et tools restent identiques pendant toute la conversation, vous ne faites qu'ajouter des messages (jamais modifier, réordonner ou supprimer), et vous renvoyez chaque tour assistant exactement comme l'API l'a rendu, tous les blocs, dans le même ordre.

Le test à lancer avant de basculer

La doc propose une session de test en mode tolérant. Envoyez l'en-tête anthropic-beta: thinking-binding-controls-2026-08-01 et ce corps de requête :

{
  "model": "claude-fable-5-2",
  "max_tokens": 16000,
  "effort": "high",
  "thinking": {
    "type": "adaptive",
    "block_binding": { "prefix_mismatch_behavior": "drop_block" }
  },
  "messages": [ ... ]
}

Vérifiez la forme exacte du champ effort dans votre SDK ; la doc parle d'une valeur « top-level ». Avec drop_block, l'API supprime les blocs invalides au lieu de renvoyer une erreur, et liste chacun dans un tableau input_transformations de la réponse. Chaque entrée prefix_binding_mismatch désigne une modification de votre code à corriger. Après un changement de modèle voulu, attendez-vous à des entrées model_binding_mismatch, c'est normal.

Gardez le réglage par défaut ("error") en production. Anthropic prévient que supprimer des blocs force le modèle à réfléchir de nouveau et fait monter les tokens de sortie, et que le pire cas est une suppression à chaque tour. La vraie correction consiste à garder l'historique en ajout seul. Pour raccourcir une conversation, la doc recommande l'édition de contexte (context editing) ou une compaction qui ne garde aucun tour avant le résumé. Pour changer une consigne en cours de route, on la met dans le dernier message plutôt que dans le system.

Si vous avez déjà mis en place des mécanismes de réduction de contexte, notre tuto sur les message threads de Claude va dans le même sens : l'historique append-only est devenu la norme pour tenir le cache.

Piège n°2 : thinking, budget_tokens et tool_choice forcé

Deux règles de la Messages API, rappelées par la doc, s'appliquent à toute requête Fable 5.2. Elles ne changent rien si vous venez de Fable 5.1 ou d'Opus 5.5, mais elles piègent ceux qui viennent d'un modèle plus ancien, ou qui ont un vieux script oublié.

• Réflexion toujours active. thinking: {type: enabled, budget_tokens: ...} et thinking: {type: disabled} renvoient tous deux une 400. Omettez le champ ou envoyez {"type": "adaptive"}, puis réglez la profondeur avec l'effort.
• Pas d'outil forcé. tool_choice à {"type": "any"} ou à un outil nommé renvoie une 400 invalid_request_error. Pour obtenir du JSON conforme à un schéma, gardez auto et ajoutez strict: true, ou utilisez les sorties JSON.

Autre détail de la doc de migration relayé par Developers Digest : les tokens de réflexion comptent dans max_tokens. Une limite trop basse peut s'arrêter avant le premier mot de texte. Et comme le bloc de réflexion arrive en premier, un code qui lit content[0] au lieu de filtrer par type lira du vide.

Avec des clés de chiffrement gérées par le client (CMEK), les sorties structurées ne sont pas disponibles pour Fable 5.2. Dans ce cas, retirez strict et validez l'entrée de l'outil dans votre code.

Piège n°3 : computer use, advisor et routeurs de modèles

Trois situations à vérifier, par ordre de probabilité chez une PME.

Routeur ou repli entre modèles

Chaque bloc de réflexion mémorise le modèle qui l'a produit. Fable 5.2 lit ceux de Fable 5.1, Opus 5.5, Sonnet 5.5, Haiku 5.5 et de plusieurs modèles plus anciens. L'inverse est faux : aucun autre modèle (hors Mythos 5.2) ne lit les blocs de Fable 5.2, y compris Fable 5.1 et Opus 5.5. Si votre routeur bascule en cours de conversation de Fable vers un modèle moins cher, la requête réussit, les blocs illisibles sont supprimés et non facturés, mais le raisonnement est perdu et le tour suivant coûte plus cher en tokens et en latence. Les replis autorisés pour Fable 5.2 sont Opus 4.8 et Opus 5 : auditez toute chaîne qui pointe ailleurs. Les blocs sont aussi liés au compte qui les a produits.

Si vous aviez construit un routage entre modèles, l'article sur les passerelles LLM montre quelles options gèrent le mieux ce genre de bascule.

Computer use

Le vieux type d'outil computer_20251124 renvoie une 400 partout sauf sur Amazon Bedrock. Il faut passer au jeu d'outils computer_toolset_20260801, sans nom, sans dimensions d'écran, sans en-tête bêta. Un grep suffit pour savoir si vous êtes concerné.

Advisor

L'outil advisor (bêta) exige un conseiller au moins aussi capable que l'exécuteur. Un exécuteur Fable 5.2 n'accepte que Fable 5.2 ou Mythos 5.2 comme conseiller. Un advisor sur Fable 5.1 produit une 400. Et changer le modèle du conseiller modifie tools : faites-le dans de nouvelles conversations, sinon vous retombez sur le piège n°1. Par ailleurs, le conseil rendu par un advisor Fable 5.2 est chiffré ; si votre code lit le texte du conseil, la doc renvoie à la page des variantes de résultat.

Un seul grep couvre l'essentiel : grep -rnE "computer_20251124|budget_tokens|tool_choice|disabled" --include=*.py --include=*.ts --include=*.js .. L'auteur d'un billet publié sur DEV Community a fait exactement cela sur ses projets et n'a rien trouvé, parce qu'aucun de ses codes n'appelle l'API directement. Il précise toutefois ne pas avoir de clé API : son code n'a été que vérifié au typage, jamais exécuté. Les risques réels se concentrent chez ceux qui assemblent eux-mêmes leurs messages.

Rétention de 30 jours et refus : les deux pièges administratifs

Fable 5.2 et Mythos 5.2 exigent une rétention des données de 30 jours et ne sont pas disponibles en rétention zéro, sauf autorisation expresse d'Anthropic. Ce sont des « Covered Models ». Le modèle surveille les schémas d'usage sur plusieurs requêtes ; un programme privé en bêta (Enterprise Frontier Safeguards) vise à rendre cette surveillance compatible avec la rétention zéro. D'après eesel, le modèle n'est pas pris en charge au niveau Priority Tier. Pour un cabinet ou une clinique qui a négocié une rétention zéro, c'est un sujet à régler avant la migration, pas après. Notre article sur l'entraînement des modèles et l'opt-out rappelle la différence entre rétention et entraînement.

Deuxième sujet : les classificateurs de sécurité. Une requête refusée renvoie HTTP 200 avec stop_reason: "refusal" et un objet stop_details qui nomme la catégorie : cyber, bio, frontier_llm, reasoning_extraction ou general_harms. Anthropic affirme que les blocages ont baissé d'environ 55 % par rapport à Fable 5.1 (environ 60 % en cyber, 40 % en biologie), un chiffre que reprend MacRumors. Mais ils existent : des utilisateurs signalent encore des refus sur des questions de chimie banales, selon les commentaires recueillis par eesel.

Le point pratique : un refus arrive avec un code 200. Un script qui ne teste que le statut HTTP prendra une réponse vide pour un succès. Testez stop_reason. La doc propose un repli côté serveur (fallbacks: "default", en bêta) qui relance la requête sur le modèle recommandé pour la catégorie ; pour reasoning_extraction, le refus reste. Et si vos prompts demandent au modèle d'écrire son raisonnement dans la réponse, supprimez cette consigne : elle déclenche ce classificateur. Pour voir comment le modèle a raisonné, réglez display: "summarized" et lisez les blocs de réflexion.

Combien coûte Claude Fable 5.2 en France : le prix par token ne dit pas tout

Il n'existe pas de grille tarifaire française. Anthropic facture en dollars, et eesel signale une majoration de 10 % pour l'inférence réservée aux États-Unis. Ce qui compte pour un budget, c'est le coût par tâche, qui dépend du nombre de tokens de réflexion consommés.

Les mesures indépendantes sont celles d'Artificial Analysis, reprises par Latent Space et Kingy. Fable 5.2 en effort max prend la première place de l'indice d'intelligence v5 avec 65, devant Gemini 4 Carbon (60), Opus 5.5 (59) et GPT-6 Astra (57). Fable 5.1 plafonnait à 49.

Trois lectures.

1. Le prix baisse, la consommation monte. Latent Space rapporte que le coût par tâche à effort max est environ 2,6 fois celui d'Opus 5.5 et 2 fois celui de Fable 5.1. Une autre source tierce, citée par eesel, indique que les tokens par tâche passent de 118 000 à 274 000 à effort max.
2. L'effort high est le bon réglage. À 9,08 $ pour un score de 62, Fable 5.2 dépasse Opus 5.5 max (59 pour 10,04 $). Anthropic dit la même chose : sur FrontierCode 2.0, l'effort high égale à peu près le meilleur score d'Opus 5.5 pour environ moitié moins par tâche. Plusieurs évaluations (Vals, vue code d'AA) montrent même high devant xhigh et max ; un commentateur cité par Latent Space résume : ne pas utiliser Fable 5.2 en max.
3. Sol reste dix à vingt fois moins cher. Selon Kingy, Fable coûte environ 21 fois plus par tâche que GPT-6.1 Sol alors que ses tarifs de tokens ne sont que 4 fois supérieurs, parce qu'il produit environ quatre fois plus de tokens de sortie. Kingy n'a pas fait ses propres tests ; la comparaison repose sur un indice composite à effort maximal, et le résultat Fable est étiqueté « Default Fallback ».

Côté coûts cachés, SemiAnalysis, cité par Latent Space, a vu le coût par tâche de son évaluation GDPx passer de 67,16 $ à 88,15 $ (+31 %) : le modèle écrit des centaines, voire des milliers de cas de test, et lance des sous-agents de vérification là où les anciens s'arrêtaient vers vingt. Anthropic le confirme dans sa doc : à xhigh et max, Fable 5.2 peut lancer des sous-agents de relecture, ce que Fable 5.1 ne faisait pas.

Pour mesurer ça chez vous plutôt que de croire des benchmarks, le tuto sur le coût par clé avec l'API Usage and Cost fait gagner une heure. Et si vos agents consomment trop de tokens d'outils, la méthode du programmatic tool calling reste valable : un modèle qui réfléchit plus rend chaque aller-retour inutile plus douloureux.

Et dans l'abonnement ?

Sur les offres Claude, Fable ne compte que pour 50 % des limites hebdomadaires au maximum, d'après MacRumors ; eesel précise que Pro et les places Team standard fonctionnent en crédits d'usage hors promotion. Le créateur Theo estime, d'après Latent Space, qu'un abonnement à 200 $ donne environ 3 000 $ de Fable 5.2 contre environ 15 000 $ d'Opus 5.5. Une promotion court jusqu'au 16 novembre : Pro et places Team standard obtiennent jusqu'à 50 % des limites hebdomadaires sans surcoût plus une remise à zéro ; Max, Ultra et places premium obtiennent une à trois remises à zéro, expirant le 8 mars 2027 (source : eesel). Les fiches de coût des abonnements ont l'habitude de bouger : vérifiez sur la page officielle avant de décider.

Les réglages de prompt à revoir avant d'ouvrir le trafic

Le guide de prompting Fable 5.2 est plus utile que la plupart des tests tiers, parce qu'il chiffre chaque correction. Voici les six points qui comptent pour une automatisation de PME, avec les chiffres d'Anthropic.

• Le modèle s'arrête trop tôt à effort bas. À low et medium, un tour peut se terminer sur une liste de ce qui reste ou une offre de continuer. Anthropic fournit un bloc « Finishing work » à coller dans le prompt système. Rejoué sur des sessions enregistrées à effort medium, il a divisé par deux les fins de session avec du travail restant, au prix d'environ 30 % de tokens de sortie en plus. Gardez une étape de confirmation humaine pour tout ce qui est irréversible.
• Le propriétaire du code. Sans précision, le modèle ajoute à la structure existante et signale les problèmes voisins au lieu de les corriger. Avec la phrase « This codebase is yours », il a fusionné du code répété dans environ la moitié des essais, contre moins d'un dixième sans, mais avec environ 1,5 fois plus de tokens de sortie et des changements non demandés (tests, documentation). À omettre si le code appartient à un client qui veut un diff minimal.
• Les sous-agents. Relisez vos fichiers d'agents et de skills : les lignes qui poussent à déléguer font démarrer plus de sous-agents que nécessaire. Anthropic précise que les sous-agents peuvent représenter une grosse part du coût d'une session et invite à vérifier sur quel modèle votre harnais les fait tourner par défaut.
• Les approbations. Une règle « demander avant d'envoyer des messages à des personnes extérieures » a fait retenir au modèle environ la moitié de ses demandes courantes à des collègues. Nommez les actions exactes.
• Les notes accumulées. Mémoires, fichiers d'instructions, notes d'agents : une note « ne jamais réessayer » a fait baisser les relances de presque toutes à environ quatre essais sur dix. Nettoyez ce que vos agents s'écrivent.
• Le budget de tokens écrit dans le prompt. Retirer un gros budget indiqué dans le prompt a baissé le coût à performance équivalente à effort high et xhigh. Testez sans.

Si votre client n'affiche que les blocs text, il paraîtra muet pendant les longues boucles d'outils : les mises à jour de progression arrivent dans des blocs thinking vides par défaut. Réglez display: "updates" (bêta, en-tête thinking-display-updates-2026-08-18) pour les recevoir.

Avant de modifier un prompt, rappelons une règle de la doc qui les relie à la section précédente : faites ces changements dans de nouvelles conversations seulement. Modifier le prompt système d'une conversation stockée puis la reprendre peut déclencher le prefix check. Pour mesurer ces effets sans deviner, la méthode du tuto évals avec promptfoo s'applique telle quelle : un jeu de 20 tâches réelles, trois efforts, trois prompts.

Ce que les premiers testeurs rapportent, y compris ce qui coince

Les retours du premier jour sont contrastés, et c'est utile. Voici ce qui est documenté et attribuable.

• Un coût de 42 $ pour un résultat banal. Le développeur Theo a facturé environ 42 $ sur un projet de jeu (« Fishslop »), jugé « pas significativement meilleur qu'Opus 5.5 », avec « beaucoup d'erreurs stupides » qu'il n'attendrait pas d'Opus (Latent Space).
• Un quota englouti en 20 minutes. Un utilisateur cité par eesel rapporte des sous-agents imbriqués qui ont vidé une enveloppe d'usage de cinq heures en moins de vingt minutes. Source unique, un commentaire de forum : à traiter comme un signal, pas comme une statistique.
• Des gains réels sur les tâches longues. Lydia Hallie, citée par Latent Space, note que le modèle vérifie bien plus que Fable 5.1. Chez Anthropic, Felix Rieseberg dit que Fable gagne sur les grosses tâches longues mais « réfléchit un peu plus lentement » et qu'il préfère souvent Opus.
• Des témoignages clients choisis par Anthropic. Oracle affirme que son SQL donne des résultats corrects là où deux autres modèles ont surévalué des montants de 5 à 8 fois ; Cognition dit qu'il avoue son incertitude plutôt que d'halluciner. À lire comme du matériel de lancement.
• Un doute de fond. SemiAnalysis qualifie l'amélioration de « marginale » et suppose le modèle loin derrière les modèles internes d'Anthropic ; le lancement tombe le jour où démarre le roadshow de l'introduction en Bourse. Notre décryptage du S-1 d'Anthropic donne le contexte financier.

Fable 5.2 ou Opus 5.5 pour une PME : notre verdict

Tranchons. Migrez vers Fable 5.2 tout ce qui tourne déjà sur Fable 5.1 : l'ID change, le prix baisse de 20 %, la vitesse monte de 30 %, et le surcoût de migration se limite à une revue de code d'une heure si vous assemblez vous-même vos messages. Fixez l'effort à high, lancez le test drop_block, relisez vos routeurs.

Ne basculez pas le reste. Anthropic recommande elle-même de commencer par Opus 5.5 et de monter sur Fable quand ses évals à effort élevé échouent encore. Les chiffres tiers vont dans le même sens : Fable à 8 $/40 $, c'est deux fois le prix d'Opus par token, et la réflexion plus longue peut annuler l'avantage. Un devis, un résumé, une extraction de facture : Opus 5.5, Sonnet 5.5 ou même un modèle moins cher. Nos comparatifs Opus 5.5 contre GPT-6 Sol et Sonnet 5.5 contre GPT-6.1 Sol donnent les ordres de grandeur.

La règle de la dizaine, empruntée à eesel et à Kingy : routez vers Fable les 10 % de tâches les plus difficiles, celles où un résultat faux coûte cher et où Opus échoue sur vos évals. Pour les autres, c'est de l'argent dépensé en réflexion.

Le cas particulier des offres à abonnement : si vous êtes sur Max ou Ultra, Fable ne pèse que jusqu'à 50 % de la limite hebdomadaire. Utilisez-le pour les tâches lourdes et laissez Opus faire le reste, sinon vous épuiserez votre quota plus vite qu'avec un seul modèle. Voir aussi comment exploiter les crédits API inclus dans Claude Max avec des modèles plus légers. Pour tester Fable 5.2 sans écrire de code,

Les questions qu'on continue de se poser

• La baisse de prix tiendra-t-elle ? Aucune garantie. Le tarif est fixé, mais nos sources ne disent rien de sa durée.
• Les scores sont-ils comparables ? Les chiffres d'Anthropic sont produits par Anthropic, garde-fous activés. Les tiers (Artificial Analysis, Vals) convergent sur le classement mais divergent légèrement sur certains scores (Sol à 55 ou 56).
• Que vaut l'effort high à long terme ? Les anomalies high contre xhigh sont documentées sur quelques évaluations, pas encore sur des usages métier.
• Qu'en est-il de la perte de raisonnement entre modèles ? Le coût réel d'un routeur qui bascule en cours de conversation n'est pas chiffré publiquement. À mesurer chez vous.