Anthropic baisse les tarifs de Fable 5.2 de 20 %, mais le coût par tâche augmente de 31 % dans un test

Si votre agent d’IA passe des heures à corriger du code, une baisse du tarif des tokens ne garantit pas des économies. Anthropic a lancé Fable 5.2 avec des prix inférieurs de 20 % à ceux de la version précédente, mais, dans un test indépendant de tâches professionnelles, la facture moyenne par tentative a augmenté de 31 %. La raison est simple : le modèle vérifie plus soigneusement son propre travail. Pour une équipe, c’est l’occasion de revoir les paramètres de raisonnement et de calculer le coût d’un résultat ayant passé les vérifications.

Fable 5.2 est sorti en même temps que Mythos 5.2. Anthropic destine ces nouveaux modèles aux projets techniques complexes dont les exigences évoluent encore en cours de route. Le lancement a coïncidé avec le début des présentations de l’entreprise aux investisseurs en vue de son introduction en Bourse. Pour les développeurs, une autre question est toutefois plus intéressante : combien de vérifications supplémentaires vaut-il la peine de payer au modèle ?

Pourquoi des tokens moins chers ont rendu la tâche plus coûteuse

Le million de tokens d’entrée de Fable 5.2 coûte 8 $, contre 40 $ pour les tokens de sortie. Pour Fable 5.1, les tarifs étaient respectivement de 10 $ et de 50 $. Mais la facture finale dépend aussi du volume de travail : du temps que le modèle consacre au raisonnement, de ses appels aux outils et de ses vérifications des solutions intermédiaires.

Selon l’analyse de SemiAnalysis, dans le test GDPx, la nouvelle version générait parfois des centaines, voire des milliers de vérifications là où les modèles précédents se limitaient à une vingtaine. Elle faisait aussi plus volontiers appel à des agents supplémentaires pour vérifier la solution de manière indépendante. Le coût moyen par tâche est passé de 67,16 $ à 88,15 $. Fable a obtenu un score de 16,4 %, le meilleur de ce test, mais ce pourcentage ne peut pas être extrapolé au développement courant.

Imaginez la migration d’un service vers une nouvelle bibliothèque. L’agent modifie les appels API, lance les tests, puis commence à vérifier des combinaisons rares de paramètres et demande à un autre agent de réexaminer le correctif. Ce travail peut permettre de détecter une erreur gênante avant la mise en production. Si la modification concerne un prototype interne destiné à une seule soirée, le coût de cette même minutie devient plus discutable. Il s’agit d’un exemple hypothétique du mécanisme des dépenses, et non d’une expérience publiée.

Un raisonnement maximal ne garantit pas une utilité maximale

Fable propose cinq niveaux d’effort : Low, Medium, High, Xhigh et Max. Dans les applications Claude et Claude Code, le niveau par défaut est Medium. Ce paramètre détermine la quantité de ressources que le modèle peut consacrer à la résolution d’une tâche.

Un détail important de ce lancement : plusieurs évaluations ont montré qu’un effort accru n’améliore pas toujours le résultat. Sur Vals, le niveau High a fait mieux que Xhigh et Max. Selon Anthropic, sur FrontierCode 2.0, Fable en mode High a égalé Opus 5.5 en mode Max pour un coût par tâche environ deux fois moindre. Cette dernière affirmation vient du fabricant et mérite d’être vérifiée séparément sur son propre code.

La supériorité n’est pas non plus universelle. Dans les mesures indépendantes citées, Fable était devancé par certains concurrents sur les tâches en terminal et l’automatisation. Une première place au classement général ne dit donc pas grand-chose sur la baisse éventuelle du coût d’un processus précis : correction de régressions, préparation de documents financiers ou utilisation d’un navigateur.

L’annonce officielle présente le positionnement de Fable et Mythos, tandis que la documentation de Cursor permet de vérifier les particularités de l’utilisation du modèle dans l’éditeur. Lors d’une migration, il est important de réévaluer les paramètres : un même nom de niveau dans différentes versions ne garantit pas une consommation identique.

Que vérifier avant de migrer

Prenez quelques dizaines de tâches terminées de votre propre projet et exécutez-les avec le modèle actuel, Fable Medium et Fable High. Définissez à l’avance les critères d’acceptation : les tests passent-ils, les exigences sont-elles respectées, combien de corrections une personne a-t-elle demandées ? Comparez les dépenses en tenant aussi compte du temps d’attente et des retouches manuelles.

Un indicateur utile consiste à diviser le coût total de toutes les tentatives par le nombre de résultats acceptés. Il prend en compte aussi bien les échecs peu coûteux que les exécutions réussies mais onéreuses. Pour les exécutions longues, fixez un budget, une durée limite et des conditions d’arrêt, faute de quoi une vérification supplémentaire peut facilement se transformer en dépense imprévue.

Fable 5.2 mérite d’être testé sur les migrations complexes et les tâches aux exigences incomplètes. Une migration massive des requêtes courantes doit se justifier par vos propres mesures. Si High fournit déjà une solution exploitable, le niveau d’effort suivant doit prouver son utilité.