Anthropic lance Fable 5.2 : des résultats de niveau Opus pour près de moitié moins cher par tâche

Un agent IA peut passer des heures à corriger un bug, lancer des tests et réécrire son propre correctif. Pour une équipe, la question devient vite financière : combien coûte une modification que le développeur acceptera réellement ? Anthropic a lancé Fable 5.2 et affirme que, sur un test de programmation, le modèle s'est approché du résultat d'Opus 5.5 pour un coût par tâche presque deux fois inférieur. C'est une bonne raison de vérifier les réglages de votre agent, surtout si les dépenses liées aux longs raisonnements pèsent déjà sur le budget.

D'où vient l'économie

Sur FrontierCode 2.0, Fable 5.2 avec le réglage High a obtenu 45,3 %, et Opus 5.5 avec Max 45,5 %. Le test évalue si les mainteneurs de dépôts open source accepteraient les modifications proposées par le modèle. Selon l'entreprise, le coût par tâche de Fable était dans cette comparaison environ deux fois plus bas. L'API du nouveau modèle coûte 8 $ par million de tokens en entrée et 40 $ par million en sortie. Source des chiffres : l'annonce d'Anthropic.

Il est utile de distinguer le prix du token et le prix du résultat. Le premier figure dans la grille tarifaire. Le second dépend du nombre de tentatives de l'agent pour corriger l'erreur, de la quantité de contexte lue et du travail laissé à l'humain. Un lancement moins cher peut très bien coûter plus cher au final si l'ingénieur passe ensuite une demi-journée à rétablir un comportement cassé.

Le réglage de la profondeur de raisonnement fait lui aussi partie du choix. Comparer les modèles uniquement dans leurs modes maximaux est pratique pour un tableau de records. Pour un produit, il est plus utile de trouver le mode qui offre une qualité acceptable avec un budget abordable. Le résultat d'Anthropic montre pourquoi une telle expérience a du sens, même si l'on ne peut pas promettre d'avance la même économie à une équipe donnée.

Comment tester sur un bug familier

Imaginons un service d'abonnements : après une requête répétée, le client reçoit parfois deux prélèvements identiques. L'agent doit comprendre le traitement des requêtes répétées, corriger le code et ajouter une vérification. Une explication bien rédigée ne règle rien si les doublons continuent d'apparaître.

Pour comparer les modèles, préparez le même instantané du dépôt, la description de l'erreur et les outils disponibles. Fixez les mêmes limites de temps et de dépenses. Vérifiez ensuite si le correctif élimine le problème initial, si les tests existants passent et si le comportement des scénarios voisins reste inchangé. Il est utile que le relecteur évalue d'abord les modifications sans connaître le nom du modèle : on est ainsi moins tenté de pardonner une erreur à son favori.

Un seul bug ne suffit pas. Constituez un petit ensemble de tâches déjà résolues : correction d'une régression, évolution d'une API, modification d'un schéma de données, recherche de la cause d'une requête lente. Pour chacune, conservez le coût des exécutions, le nombre de nouvelles tentatives et le temps de vérification humaine. La métrique principale est le coût par correctif accepté. Le taux de réussite et la durée d'exécution doivent être examinés en parallèle, sinon l'économie peut masquer une dégradation de la qualité ou de la vitesse.

Pour un product manager, c'est un moyen de tester une hypothèse précise : peut-on traiter plus de requêtes complexes avec le même budget ? Pour un fondateur, c'est la possibilité d'estimer le coût de revient d'une fonctionnalité avant de promettre un assistant illimité aux utilisateurs.

Où s'arrêtent les conclusions de l'annonce

La comparaison publiée comporte une limite importante : les résultats ont été présentés par le fournisseur lui-même. Vos dépôts, outils, instructions et critères d'acceptation peuvent différer sensiblement de ceux du test. De plus, l'écart entre 45,3 % et 45,5 % ne prouve pas à lui seul que les modèles sont équivalents sur toutes les tâches d'ingénierie.

Il serait donc prématuré de changer de modèle d'un seul coup dans tout le produit. Une première étape raisonnable consiste à rejouer les tâches sauvegardées, puis à confier à la nouvelle configuration une petite part du travail réel avec une relecture habituelle. Si le gain se confirme, on peut étendre l'usage progressivement, en gardant la possibilité de revenir à la solution précédente.

La valeur pratique de cette version tient à une promesse vérifiable : réduire le coût du travail complexe. Chaque équipe doit trouver sa propre réponse à une question simple : combien d'argent et de temps faut-il pour une correction qui a passé les vérifications et qui a rejoint le code principal ?