Fable 5.1 vs Fable 5 : même prix, autre facture

Publié sur le blog TEN INVENT · Septembre 2026

Anthropic a lancé Claude Fable 5.1 et la première chose que tu vois sur la page des tarifs, c'est que rien n'a changé : 10 $ par million de tokens en entrée, 50 par million en sortie, exactement comme sur Fable 5. La deuxième chose, que tu ne vois que si tu lis le guide de migration jusqu'au bout, c'est que tout a changé dans la façon dont tu arrives à cette facture. Ce que tu achètes avec 5.1, ce n'est pas « un meilleur modèle au même prix », mais un modèle qui se comporte autrement à chaque niveau d'effort, qui lit le cache quatre fois moins cher et qui t'impose une certaine façon de construire le harness autour de lui.

Nous avons écrit cet article pour ceux qui doivent décider dans les prochaines semaines s'ils migrent. Nous avons aussi mis Opus 5 dans la comparaison, parce que sans lui la discussion est incomplète : Opus 5 coûte moitié moins, fonctionne sous zero data retention et, à effort élevé, résout une grande partie de ce que résout aussi Fable. Tous les chiffres ci-dessous viennent de la documentation officielle de l'API d'août 2026, pas de benchmarks marketing. Là où nous n'avons pas de chiffres, nous le disons.

Les trois modèles, dans un tableau

Une ligne qui mérite d'être lue deux fois : Opus 5 en fast mode coûte exactement autant que Fable 5.1. Pour le même argent, tu as soit le modèle le plus capable, soit un modèle un cran en dessous, mais avec un output jusqu'à 2,5 fois plus rapide. Ce sont deux produits différents au même prix, et le choix dépend de ce qui te fait mal : la latence ou la qualité sur les tâches lourdes.

Reasoning : ce qui a vraiment changé

Sur les deux modèles Fable, le thinking est toujours activé. Tu ne peux pas envoyer thinking: disabled sans recevoir un 400, et l'ancien budget_tokens a complètement disparu. Le seul bouton que tu as, c'est output_config.effort, avec cinq paliers : low, medium, high, xhigh, max. Opus 5 est plus permissif, il accepte qu'on désactive le thinking, mais seulement jusqu'à l'effort high, et la documentation te dit assez directement de ne pas le faire, parce que le modèle se met à écrire des appels de tools en texte au lieu de blocs structurés.

La partie importante pour les budgets, c'est que les niveaux d'effort ne signifient pas la même quantité de réflexion d'un modèle à l'autre. Le guide de migration dit explicitement qu'il faut refaire le sweep d'effort sur 5.1 même si tu l'as fait sur Fable 5. Et il donne deux repères que nous avons représentés ci-dessous : à medium, Fable 5.1 atteint à peu près les résultats de Fable 5 pour un coût moindre ; et à low, Fable 5.1 dépasse souvent le niveau xhigh, voire max, des modèles de la génération précédente.

Conséquence pratique : si tu fais tourner Fable 5 à high (le réglage par défaut), la première expérience sur 5.1 consiste à descendre à medium et à voir si tes évaluations passent encore. Si elles passent, tu as obtenu la même qualité avec moins de tokens en sortie, qui sont la partie chère. Le vrai gain de capacité par rapport à Fable 5 apparaît, dit la documentation, surtout à high et au-dessus, donc le niveau du haut reste pour les tâches où tu as mesuré que ça en vaut la peine.

Une chose qui n'a pas changé et qu'il est bon de savoir : le tokenizer est le même sur Fable 5, Fable 5.1 et sur la famille Opus depuis 4.7, donc le nombre de tokens pour le même prompt est comparable. La différence de coût entre les modèles vient du prix et de la quantité de réflexion, pas de la façon dont ils découpent le texte.

Où 5.1 est meilleur que 5

Anthropic liste six domaines, en précisant que l'écart est le plus grand aux niveaux d'effort élevés :

1. Coding agentique sur de longues sessions : fonctionnalités sur plusieurs fichiers, refactorisations et migrations de grande ampleur, debugging et code review sur des sessions de plusieurs heures.
2. Documents, feuilles de calcul et présentations construits de zéro, avec des formules vivantes, pas seulement du texte.
3. Research multi-étapes, c'est-à-dire de la recherche web où il suit ce qu'il a trouvé, pas une seule requête.
4. Vision sur des graphiques denses, des tableaux dans des PDF et des images dégradées. La meilleure forme est avec des tools de crop et de zoom à disposition, pas avec plus de thinking.
5. Retrieval en contexte long, profondément dans la fenêtre de 1M.
6. Computer use : piloter un navigateur ou des applications desktop, avec récupération après des étapes échouées.

La performance multilingue est à parité avec Fable 5. Nous n'avons pas de chiffres de benchmark d'Anthropic pour la comparaison 5.1 contre 5, donc nous n'en inventons pas. Ce que nous avons, ce sont les trois changements de comportement observés dans les harness, sans aucune modification de code : 5.1 groupe moins les appels de tools implicites, narre moins entre les appels et, à effort low, répond plus souvent de mémoire au lieu de vérifier. Les trois se corrigent avec un prompt, et la documentation fournit le texte exact.

Le coût réel : le cache au quart du prix

C'est ici que se joue l'histoire d'argent, et elle est cachée dans une seule ligne du tableau des tarifs. La lecture du cache sur Fable 5.1 coûte 0,25 $ par million, contre 1,00 sur Fable 5 et 0,50 sur Opus 5. Ça a l'air d'un détail, jusqu'à ce que tu regardes ce que fait vraiment une session agentique : elle relit le même préfixe à chaque tour. Un system prompt avec des tools, puis tout l'historique de la conversation, quarante fois dans une seule session. Dans un tel scénario, les lectures du cache sont de loin le plus gros volume de tokens, même si ce n'est pas le plus gros coût.

Nous avons calculé un scénario typique pour que tu voies les proportions. Un agent avec un préfixe de 20 000 tokens (system prompt plus les définitions des tools), 40 tours, à chaque tour environ 3 500 nouveaux tokens en entrée issus des résultats des tools et 3 000 tokens en sortie, thinking inclus. Le tout avec le cache actif, avec le breakpoint déplacé à chaque tour.

Deux choses ressortent du diagramme. La première : à nombre de tokens égal, Fable 5.1 est environ un quart moins cher que Fable 5 sur une session agentique, uniquement du fait du prix de la lecture du cache. Si tu ajoutes qu'à medium tu fais le même travail avec moins de thinking, l'économie réelle est plus grande. La seconde : Opus 5 reste le moins cher avec une marge nette, environ 35 % sous 5.1 dans ce scénario, et l'écart vient presque entièrement des tokens en sortie, qui coûtent moitié moins.

Il y a aussi un côté moins agréable du cache bon marché. Quand une lecture coûte 0,25 et une écriture 12,50, un cache miss est 50 fois plus cher qu'un hit. Sur Fable 5, le rapport était de 12,5. Autrement dit, sur 5.1 garder le cache chaud compte beaucoup plus : un changement de system prompt entre deux requêtes, un timestamp dans le prompt ou une pause au-delà des cinq minutes de TTL te coûtent relativement plus qu'avant. Pour les pauses entre 5 et 60 minutes, la documentation recommande un renvoi avec max_tokens: 0, qui est en général moins cher que le TTL d'une heure.

Trois changements qui cassent le code à la migration

Le prix est le même, mais l'API n'est pas un drop-in. Trois choses qui marchaient sur Fable 5 renvoient un 400 sur 5.1.

Forcer un tool n'existe plus. tool_choice avec any ou avec un nom de tool est rejeté. Si tu utilisais le forçage pour obtenir du JSON garanti, remplace-le par les structured outputs. Si tu l'utilisais pour t'assurer que le modèle appelle le tool, tu utilises auto plus une instruction explicite et strict: true sur le schéma du tool.

Les blocs de thinking sont liés au modèle qui les a produits. Si tu envoies l'historique d'une conversation de Fable 5.1 vers Opus 5 (par exemple comme fallback sur un refus), Opus 5 ignore les blocs de thinking, sans les facturer. Dans l'autre sens, Fable 5.1 lit ceux des modèles plus anciens. En pratique, tu ne peux plus déplacer librement une session entre modèles sans perdre le contexte de raisonnement.

L'historique est append-only. C'est celui qui fait le plus mal et la documentation l'appelle « preserved thinking ». Si tu modifies un tour précédent de la conversation (tu supprimes un message, tu réécris le system prompt, tu coupes l'historique), tous les blocs de thinking situés après le point modifié deviennent invalides. Les comptes créés à partir du 31 août 2026 reçoivent directement un 400 sur un historique modifié, et les modèles suivants appliqueront la règle à tout le monde. Beaucoup de harness écrits pour Opus 4.8 ou plus ancien tronquent les vieux tours ou injectent puis suppriment des messages de rappel. Tous doivent être réécrits.

Cinq nouveautés d'API, toutes au service du cache

Ce n'est pas une coïncidence si quatre des cinq ajouts de 5.1 résolvent exactement le problème ci-dessus : comment changer quelque chose au milieu d'une conversation sans modifier l'historique.

• Effort par message. Un message système vide avec output_config.effort change le niveau d'effort à partir de ce point, sans reset de cache. Tu montes à xhigh pour l'étape difficile, tu descends à low pour les étapes de routine, dans la même conversation. Ça marche aussi sur Opus 5, mais pas sur Fable 5.
• Messages système avec date d'expiration. clear_at: "next_user_message" fait qu'un rappel n'est visible qu'un seul tour, puis reste dans l'historique, mais n'est plus rendu et ne coûte plus rien. C'est comme ça que tu injectes « vérifie l'inbox avant de lancer du code » sans rien supprimer ensuite.
• Progress updates entre les tool calls. Avec display: "updates", le modèle renvoie les courtes notes de progression qu'il écrit entre les appels, tandis que le raisonnement proprement dit reste caché. Sans ça, un tour agentique de 10 minutes ressemble à une pause de 10 minutes dans l'UI.
• La lecture du cache à 0,25. Vue plus haut.
• Provenance du contenu. Tout le texte généré par 5.1 porte un watermark statistique, sans caractères cachés et sans tokens supplémentaires. Les images et les fichiers média produits dans le sandbox de code execution reçoivent des Content Credentials C2PA signés. C'est la première fois qu'un modèle Anthropic vient avec ça par défaut, et ça ne se désactive pas.

Encore un détail de contexte : Claude Mythos 5.1 est le même modèle que Fable 5.1, avec les mêmes tarifs et la même API, proposé uniquement aux participants du Project Glasswing. Nous avons écrit en avril sur ce qu'est Mythos et ce qui relève du marketing ; la différence par rapport à cette époque, c'est que Mythos 5.1 fait maintenant tourner ses propres classificateurs de sécurité, selon le programme d'accès de l'organisation.

Rétention des données : le point de décision pour l'enterprise

Une ligne du tableau change la discussion pour toute une catégorie de clients. Fable 5 et 5.1 sont des « Covered Models » : Anthropic exige que l'organisation ou le workspace qui les appelle ait la rétention des données de 30 jours activée. Si tu as zero data retention dans ton contrat, la requête reçoit un 400 avec un message explicite, et le seul contournement est une autorisation expresse négociée avec l'équipe de compte.

Pour la majorité des entreprises, rien ne change, parce que la rétention de 30 jours est le réglage par défaut. Pour les banques, la santé, les cabinets d'avocats ou le secteur public, où le ZDR est souvent une condition de l'analyse d'impact RGPD, le choix entre Opus 5 et Fable 5.1 n'est plus une question de coût et de capacité. Ça devient une discussion avec le DPO : Opus 5 fonctionne sous ZDR sans aucun changement, Fable 5.1 signifie soit un workspace séparé avec rétention, soit une autorisation, soit renoncer au modèle.

Quand choisir quoi

Le positionnement officiel est clair et mérite d'être pris au sérieux parce que ce n'est pas celui qu'on attendrait d'un vendor : commence avec Opus 5, passe à Fable 5.1 uniquement pour le reasoning intensif et les tâches agentiques de longue durée, ou quand les évaluations sur Opus 5 à effort élevé n'atteignent pas le seuil.

Avec Fable 5, il ne reste qu'une seule raison de rester : le Priority Tier, qui n'existe pas sur 5.1. Pour le reste, 5.1 fait le même travail pour le même argent par token, avec le cache quatre fois moins cher. Pour qui vient d'Opus 5, le saut, c'est le doublement du prix par token, auquel s'ajoutent la perte du ZDR et un ensemble plus large de classificateurs. Ça ne vaut le coup que si tu as mesuré qu'Opus 5 à xhigh n'arrive pas là où tu en as besoin, ou si tu as un cas d'usage parmi les six domaines ci-dessus où la différence est visible.

Ce que nous avons observé en pratique, sur le travail quotidien avec Claude Code, c'est que le plus gros gain ne vient pas du choix du modèle, mais du choix de l'effort. Un Fable 5.1 à medium sur les tâches de routine et à xhigh sur les tâches lourdes, dans la même session, bat aussi bien un Fable 5 lancé uniformément à high qu'un Opus 5 qui a besoin de deux tentatives sur les tâches lourdes. Et l'effort par message est exactement ce qui rend ce setup possible sans payer le reset de cache.

Si tu fais déjà tourner des agents sur Fable 5 ou Opus et que tu veux savoir combien te coûterait la migration, y compris la réécriture du harness en append-only, parlons-en.