Anthropic baisse de 20 % les prix de Fable 5.2 : ce que cela change pour les agents d'IA

Un agent d'IA corrige un bug complexe : il lit le dépôt, lance les tests, modifie le code, puis revient au contexte. Ces boucles peuvent se répéter des dizaines de fois. Pour une équipe, ce qui compte n'est donc pas seulement le tarif de la réponse, mais aussi le coût de la relecture répétée des mêmes fichiers. Claude Fable 5.2, sortie le 9 novembre, rend cette partie du travail moins chère. La prochaine étape pratique consiste à la tester sur une tâche longue dont vous connaissez déjà les coûts et la qualité du résultat.

Anthropic a fixé le prix à 8 $ par million de tokens en entrée et 40 $ par million en sortie, soit 20 % de moins que Fable 5.1. La relecture depuis le cache coûte 0,20 $ par million de tokens. Cependant, on ne peut pas appliquer automatiquement cette remise à tout le budget de l'agent : la facture comprend toujours la génération, l'écriture du cache et les nouvelles parties du contexte. Les tarifs sont publiés dans la documentation du modèle.

Où le cache bon marché aide vraiment

Imaginons un agent qui migre un service vers une autre bibliothèque. Il a constamment besoin de la structure du projet, des conventions de l'équipe et de la description de l'API. Si ces éléments forment une partie inchangée de la requête et sont bien mis en cache, les relire coûte moins cher. Si l'application reconstruit le contexte à chaque fois, l'économie attendue peut disparaître.

Il est facile ici de se tromper de métrique. Comparer uniquement le prix du million de tokens ne suffit pas. Un modèle corrigera le problème en quelques tentatives, un autre passera la soirée sur des modifications inutiles. Ce qu'il faut calculer, c'est le coût d'un changement accepté : combien l'équipe a payé avant que les tests et la revue soient passés. Le temps de l'ingénieur consacré à la vérification fait aussi partie de l'économie d'un tel déploiement.

Pour une première comparaison, quelques tâches déjà résolues dans votre propre dépôt suffiront. Conservez des conditions identiques, les mêmes limites d'outils et les mêmes critères d'acceptation. Notez séparément les coûts d'entrée, de sortie et de cache, le nombre de nouvelles tentatives et le temps nécessaire pour obtenir un résultat exploitable. Un tel essai est plus utile que la promesse d'une économie par cinq déduite d'un seul tarif.

Deux versions du modèle, des restrictions différentes

Fable 5.2 et Mythos 5.2 reposent sur le même modèle de base. La version Fable, accessible au grand public, applique des restrictions supplémentaires en cybersécurité et en biologie ; les organisations accèdent à Mythos via des programmes de vérification. Cette différence est importante pour les équipes qui conçoivent des outils d'audit ou des processus de recherche. Les produits sont décrits dans l'annonce d'Anthropic.

Le risque pratique apparaît lorsque l'application, après un refus, envoie la tâche à un autre modèle. L'utilisateur voit une interface unique, mais le résultat peut déjà dépendre d'un autre exécutant. Il est donc utile de consigner dans le journal d'exécution le modèle choisi, les refus et les requêtes répétées. Sinon, il est difficile de comprendre pourquoi un audit détectait un problème hier et le laisse passer aujourd'hui.

Les benchmarks demandent eux aussi une lecture prudente. Dans le tableau fourni par le constructeur, Fable devance plusieurs concurrents en programmation agentique, mais ne domine pas tous les processus métier. Le résultat d'un test isolé ne doit pas devenir la promesse de remplacer un employé ou de mener à bien votre migration. Le niveau de raisonnement, les outils et les conditions d'exécution influencent le résultat.

Savoir qu'on est évalué ne signifie pas tromper

La thèse la plus retentissante du matériel d'origine est que le modèle remarque qu'on le teste. Mais il y a une différence entre reconnaître une vérification et fausser délibérément les résultats. La part de dialogues présentant de tels signes ne montre pas, à elle seule, combien d'évaluations le modèle a réussi à contourner. Pour cela, il faut connaître les conditions de l'expérience et disposer d'observations précises du comportement.

Pour le développeur, la conclusion est très pratique : il faut vérifier à la fois les réponses et les actions de l'agent. Quels fichiers a-t-il ouverts, quelles commandes a-t-il exécutées, où a-t-il envoyé des données, les modifications correspondent-elles à la tâche. De bons résultats d'audit en laboratoire ne remplacent pas l'isolation de l'environnement ni la restriction de l'accès aux secrets.

Avant un pilote, vérifiez aussi les conditions de conservation des requêtes : pour ce modèle, la documentation prévoit une conservation de 30 jours, et les exceptions nécessitent une autorisation distincte d'Anthropic. Commencez par un ensemble limité de tâches, mesurez les coûts et la part de résultats acceptés. Si le gain persiste après la revue et les exécutions répétées, il y aura une raison d'étendre l'usage.