Comment rendre Fable moins cher que Opus : en réécrivant la structure des coûts des agents grâce à la délégation

Fable ressemble à un manager de directeur ingénieur senior : il rend la tâche tôt, détaille clairement les spécifications, et met moins la main à la pâte. Opus, lui, ressemble à un micro-manager qui encadre des stagiaires. Cet article provient d’une publication de Joon Lee X et dissèque la structure des coûts en se basant sur 3 000 sessions d’évaluation.
(Contexte : Anthropic lance « Claude for Small Business » : ciblage de l’automatisation par l’IA pour les petites et moyennes entreprises, pour t’aider à relancer les factures, calculer les salaires..)
(Ajout de contexte : Anthropic exige une vérification KYC avec nom réel ! Une partie des fonctionnalités de Claude nécessitera d’importer des pièces d’identité, ce qui augmente la pression de conformité)

Table des matières

Toggle

• Introduction
• Paramétrage de l’expérience
• Le coût d’un agent
• Micro-manager avec des stagiaires vs manager avec des ingénieurs seniors
• Après la passation
• Quand la délégation ne suffit pas
• Conclusion

Nous avons remplacé Opus 4.8 par Fable 5, et la facture de Devin a pourtant baissé.

Le coût de Fable 5 par token est le double de celui d’Opus 4.8. Mais quand nous utilisons la toute nouvelle architecture Fusion, en faisant tourner simultanément ces deux modèles sur FrontierCode 1.1, Fable est au final plus économique. Rien d’étonnant : ses scores sont aussi plus élevés. Cet article explique pourquoi, et ce que cela implique pour « tarifer » le travail agentique.

Introduction

Quiconque exécute des agents qui écrivent du code sait : un modèle plus puissant te donne de meilleurs résultats, mais tu dois en absorber le coût.

Quand nous avons lancé Devin Fusion, nous avons montré une issue : faire s’asseoir un modèle de pointe aux commandes, le laisser déléguer le travail à un assistant moins cher et plus rapide, et ainsi obtenir une performance de niveau frontier à un coût inférieur de 35%.

Mais une fois que le modèle principal a délégué la majeure partie du travail, son prix par token va-t-il continuer à dominer toute la facture ? Le coût par token de Fable 5 est deux fois plus élevé que celui d’Opus 4.8. En théorie, un agent piloté par Fable devrait donc coûter plus cher. Pour trouver la réponse, nous avons fait tourner 3 000 sessions d’évaluation sur FrontierCode 1.1, couvrant quatre configurations : Fable et Opus, chacun aux commandes, et chacun exécuté avec et sans le même assistant bon marché.

Les résultats en exécution pure (pure runs) suivent exactement l’intuition : le score de Fable dépasse Opus (60,8 contre 55,4), et le coût est plus élevé. Un meilleur modèle, une facture plus grande.

C’est avec l’assistant que les choses deviennent intéressantes.

À assistant identique, l’ordre des coûts s’inverse : Fable + assistant revient moins cher qu’Opus + assistant (1,86 $ contre 2,04 $), tout en ayant un score plus élevé (60,7 contre 54,6). Et par rapport à Fable seul, Fable + assistant réduit le coût de 54 %, tout en gardant un score presque identique.

| Configuration | | --- | Score | Coût par exécution (moyenne) | | --- | --- | | Fable 5(low)+ assistant | 60,7 | 1,86 $ | | Opus 4.8(medium)+ assistant | 54,6 | 2,04 $ | | Fable 5(low) | 60,8 | 4,03 $ | | Opus 4.8(medium) | 55,4 | 3,06 $ |

Les résultats prouvent que « deux fois plus cher par token » était un chiffre mal interprété. Le coût d’un agent dépend surtout de combien de tours le modèle principal effectue, combien de contexte il embarque en même temps, et — plus important encore — ce qu’il décide de « ne pas faire » lui-même. La différence se résume à un style de management : Opus se comporte comme un micro-manager avec des stagiaires ; Fable comme un manager avec des ingénieurs efficaces.

Paramétrage de l’expérience

Récapitulons rapidement comment fonctionne l’architecture d’assistant dans Fusion. L’agent principal possède toute la session : il discute avec l’utilisateur, planifie, examine le travail et fait la soumission (commit). Il dispose aussi d’un sous-agent d’assistant, permanent, chargé de déléguer les tâches. Le modèle principal rédige en langage clair une note de passation, puis un sous-agent alimenté par un modèle beaucoup moins cher exécute la tâche dans son propre contexte et renvoie les résultats. Le modèle principal examine les résultats et décide de la suite.

Pour comprendre où partent les coûts, nous avons fait deux choses. Premièrement, nous avons analysé chaque appel LLM dans l’ensemble des 3 000 sessions de travail : quel modèle parle, quels outils il appelle, combien de tokens il lit/écrit, et combien cela coûte à chaque appel. Deuxièmement, nous avons choisi 40 tâches pour une observation plus rapprochée : celles où Fable est manifestement moins cher, celles où Opus est manifestement moins cher, et un autre lot d’échantillons aléatoires provenant de zones intermédiaires. Pour chacune, nous analysons côte à côte une exécution pilotée par Fable et une exécution pilotée par Opus, en examinant leurs trajectoires et en observant à quoi l’argent est dépensé.

Le coût d’un agent

Voici comment, dans notre expérience, les coûts se répartissent entre le modèle principal et l’assistant :

| | | --- | Modèle principal $ | Assistant $ | Coût total par exécution $ | Nombre de tours du modèle principal | Tokens d’entrée du modèle principal (cumulés) | | --- | --- | --- | --- | --- | | Fable + assistant | 1,28 $ | 0,58 $ | 1,86 $ | 11,5 | 545k tok | | Opus + assistant | 1,73 $ | 0,31 $ | 2,04 $ | 26,5 | 1,679k tok |

Fable dépense plus d’argent pour l’assistant que Opus — +0,27 $ par exécution. Mais il dépense moins pour lui-même : −0,45 $. Le modèle principal de Fable effectue 11,5 tours par exécution, contre 26,5 pour Opus ; les output tokens écrits ne représentent qu’un tiers (6,1k contre 19,0k), et les input tokens consommés ne représentent aussi qu’un tiers. Fable est clairement plus cher par token, mais il gagne sur la gestion du contexte et le nombre de tours.

Les économies de tokens de Fable viennent du fait qu’il évite carrément le travail. Fait intéressant : dans 81 % des exécutions pilotées par Fable, le modèle principal n’a fait aucun editing de code du début à la fin. Pour Opus, ce cas ne concerne que 24 % des exécutions. Dans 13 % des exécutions pilotées par Fable, le modèle principal n’a même jamais lu en personne un fichier de repo.

Micro-manager avec des stagiaires vs manager avec des ingénieurs seniors

L’écart qui rend tout cela intéressant, c’est que les deux modèles principaux délèguent le même nombre de fois : environ 3 passations par exécution. Les logs d’appels successifs réfutent l’explication simpliste « Fable délègue juste davantage ». La vraie différence, c’est « quand » il délègue, et « quoi » il délègue. La première passation de Fable arrive très tôt.

Opus, lui, délègue souvent très tard, après une longue phase d’exploration et d’implémentation en solo ; à ce moment-là, les décisions de design sont déjà prises, les fichiers importants sont déjà entrés dans son contexte, et le travail coûteux est déjà fait.

Une exécution typique pilotée par Fable fait d’abord quelques actions de reconnaissance sur le repo, puis rédige une note de spécifications au niveau « grade », en déléguant d’un seul coup toute la boucle « implémenter + tester + lint ». Ensuite : un git show pour examiner le diff, puis on commit.

Une exécution typique pilotée par Opus traverse 20 à 45 tours d’exploration, de conception et d’implémentation en solo, puis une passation qui n’arrive qu’à la fin, et qui ne fait que déléguer une fermeture mécanique.

Parfois, la première action de Fable dans une session consiste à déléguer. Sur la même tâche, l’entrée en matière des deux modèles principaux ressemble à ceci :

La correction évidente serait de forcer Opus à déléguer davantage d’exploration, mais imposer ce comportement fait souvent baisser la performance. Savoir quand une investigation peut être déléguée sans risque et quand, au contraire, tu dois la faire toi-même, c’est en soi un jugement. Un modèle forcé à déléguer ne développera pas pour autant ce type de jugement : il va simplement déléguer ce qu’il ne faudrait pas déléguer.

Le style de management de chaque modèle transparaît aussi dans la note de passation elle-même. Quand Opus délègue l’implémentation, il « donne des ordres » ; Fable, lui, rédige un document de design :

La délégation ne fait pas que déplacer des coûts ; elle change aussi la qualité du travail. La tâche de hashing ci-dessus en est un bon exemple. La spécification demande qu’une fonction de hachage ait une complexité O(1) en fonction de la longueur du pointeur. Opus l’a implémentée lui-même, mais n’a jamais écrit cette contrainte quelque part. À une étape du processus, il a oublié cette contrainte et a livré une implémentation à temps linéaire, d’où un score de 25. En revanche, Fable délègue avec des contraintes de haut niveau. Sa note dit : « operator() doit être O(1) par rapport à la longueur du pointeur : ne doit pas faire un scan complet de tokens. » L’assistant a réussi à l’implémenter, obtenant 94 points.

Nous avons constaté que ce schéma se généralise à travers les tâches. La passation de Fable énumère diverses contraintes, les cas limites, et une définition de « ce qui compte comme fait », ce qui lui évite du travail, tout en permettant à l’assistant de faire l’implémentation de façon bon marché et correcte.

Après la passation

L’autre moitié, c’est ce que le modèle principal fait des livrables renvoyés par l’assistant. Les deux modèles principaux lancent souvent les mêmes vérifications bon marché : deux ou trois appels git diff / git show. Mais Opus ne s’arrête pas là. Il rapatrie les fichiers issus de l’assistant dans son propre contexte à une fréquence deux fois supérieure, et fait jusqu’à quatre fois plus d’éditions correctives au tarif du modèle principal. Dans le cas le plus extrême, il annule complètement le résultat de l’assistant et le réécrit de ses propres mains :

Et la méfiance d’Opus n’a pas non plus amélioré la correction. Sur certaines tâches d’évaluation, une seule revue de diff par Fable a détecté le vrai bug de l’assistant, puis Fable a choisi de faire une nouvelle passation bon marché plutôt que de recourir aussi souvent à des réécritures de niveau modèle principal — que fait Opus.

Quand la délégation ne suffit pas

La stratégie de délégation de Fable n’est pas universelle ; quand une tâche ne comporte pas de sous-éléments délégables, elle échoue. Ces types de tâches semblent difficiles à découper :

• Les tâches courtes ne contenant que quelques tours du modèle principal, où il n’y a rien entre le « décider » et le « livrer » qui puisse être délégué.
• Les tâches de débogage séquentielles, dont la cause racine est une longue chaîne de jugements consécutifs. Ici, le contexte accumulé lui-même constitue le travail.

À noter : sur ces tâches, Fable délègue presque complètement. Le jugement capable d’écrire une bonne note de passation sait aussi quand il ne faut pas écrire. Mais lorsqu’une tâche ne contient rien qui vaille la peine d’être délégué, la délégation n’a aucun levier sur les coûts.

En environnement de production, Fusion traite ce sujet à un autre niveau : la « décision de délégation » détermine quels travaux restent entre les mains du modèle cher, tandis que le « routage » détermine si ce modèle cher doit être impliqué ou non.

Conclusion

Quand nous avons lancé cette expérience, nous nous attendions à mesurer combien le surcoût de 2 fois de Fable ferait augmenter les coûts. Résultat : nous avons été surpris de constater que la délégation efficace de Fable faisait en réalité baisser le coût global. Elle formule des contraintes et des résultats, au lieu d’écrire l’implémentation pas à pas ; elle donne un feedback au lieu de corriger par elle-même ; et, dans la plupart des cas, elle ne touche même jamais au code. Ce sont là des habitudes de bon manager.

À mesure que les modèles assistants deviennent moins chers et meilleurs, on peut leur confier davantage de travail. Et à l’avenir, ce qui mérite encore de payer le prix du modèle de pointe, ce sera le jugement : quoi faire, quelles contraintes imposer, et qui doit écrire.