Rendre Fable moins coûteux qu'Opus

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

Fable 5 coûte deux fois plus par token qu'Opus 4.8. Mais lorsque nous avons exécuté les deux modèles sur FrontierCode 1.1 en utilisant notre nouvelle architecture Fusion, Fable a coûté moins cher. Sans surprise, il a également obtenu un score plus élevé. Cet article explique pourquoi et ce que cela signifie pour la tarification du travail agentique.

Introduction

Tous ceux qui utilisent des agents de codage savent que des modèles plus performants donnent de meilleurs résultats, mais vous en payez le prix.

Quand nous avons introduit Devin Fusion, nous avons montré une issue : garder un modèle de pointe aux commandes, lui permettre de déléguer à un sidekick moins cher et plus rapide, et vous obtenez des performances de niveau pointe à un coût inférieur de 35 %.

Mais une fois que le modèle principal délègue la majeure partie du travail, son prix par token domine-t-il encore la facture ? Fable 5 coûte 2x plus par token qu'Opus 4.8, donc un agent mené par Fable devrait coûter plus cher. Pour le savoir, nous avons mené 3 000 sessions d'évaluation sur FrontierCode 1.1 avec quatre configurations : Fable et Opus en position de leader, chacun avec et sans le même sidekick bon marché.

Les exécutions pures se comportent exactement comme l'intuition le suggère : Fable surpasse Opus (60,8 contre 55,4) et coûte plus cher. Meilleur modèle, facture plus élevée.

Les exécutions avec sidekick sont là où les choses deviennent intéressantes.

Avec le même sidekick, l'ordre des coûts s'inverse : Fable + Sidekick coûte moins cher qu'Opus + Sidekick (1,86 $ contre 2,04 $), tout en obtenant un score plus élevé (60,7 contre 54,6). Comparé à Fable pur, Fable + Sidekick réduit les coûts de 54 % tout en laissant le score quasiment inchangé.

Configuration

Score

Coût/exécution (moyenne)

Fable 5 (low) + Sidekick

60,7

1,86 $

Opus 4.8 (medium) + Sidekick

54,6

2,04 $

Fable 5 (low)

60,8

4,03 $

Opus 4.8 (medium)

55,4

3,06 $

La prime de 2x par token s'avère être le mauvais indicateur à considérer. Le coût d'un agent est dominé par le nombre de tours que le modèle principal effectue, la quantité de contexte qu'il traîne, et surtout ce qu'il décide de ne pas faire lui-même. La différence se résume au style de management : Opus se comporte comme un micromanager avec un stagiaire ; Fable est un manager avec un ingénieur compétent.

La configuration

Un rappel rapide du fonctionnement de l'architecture Sidekick de Fusion. L'agent principal possède la session : il dialogue avec l'utilisateur, planifie, révise le travail et effectue les commits. Il dispose également d'un sous-agent sidekick persistant pour déléguer des tâches. L'agent principal rédige un brief de passation en langage naturel, et le sous-agent, alimenté par un modèle beaucoup moins cher, l'exécute dans son propre contexte et fait rapport. L'agent principal examine le résultat et décide de la suite.

Pour savoir où va le coût, nous avons fait deux choses. D'abord, nous avons analysé chaque appel LLM sur les 3 000 sessions : quel modèle parlait, quel outil il a appelé, combien de tokens il a lus et écrits, et combien chaque appel a coûté. Ensuite, nous avons sélectionné 40 tâches pour un examen plus approfondi : celles où Fable était nettement moins cher, celles où Opus l'était, et un autre échantillon aléatoire du milieu. Pour chacune, nous avons analysé côte à côte l'exécution menée par Fable et celle menée par Opus, en examinant les trajectoires et en observant où allaient les dollars.

Coût d'un agent

Voici comment le coût se répartit entre le leader et le sidekick dans notre expérience :

Leader $

Sidekick $

Total $/exécution

Tours leader/exécution

Tokens d'entrée leader (cumulés)

1,28 $

0,58 $

1,86 $

11,5

545k tok

1,73 $

0,31 $

2,04 $

26,5

1 679k tok

Fable dépense plus pour son sidekick qu'Opus — 0,27 $ de plus par exécution. Mais il dépense 0,45 $ de moins sur lui-même. Le leader de Fable effectue 11,5 tours par exécution contre 26,5 pour Opus, écrit un tiers des tokens de sortie (6,1k contre 19,0k) et consomme un tiers des tokens d'entrée. Fable est nettement plus cher par token, mais gagne sur la gestion du contexte et le nombre de tours.

Les économies de tokens de Fable proviennent d'une éviction pure et simple de travail. Fait intéressant, dans 81 % des exécutions menées par Fable, le leader n'effectue jamais la moindre modification de code. Pour Opus, cela n'est vrai que pour 24 % des exécutions. Dans 13 % des exécutions menées par Fable, le leader ne lit même jamais un fichier du dépôt lui-même.

Un micromanager avec un stagiaire contre un manager avec un ingénieur

Voici ce qui rend l'écart intéressant : les deux leaders délèguent le même nombre de fois, environ 3 passations par exécution. Les journaux par appel démontent l'explication facile selon laquelle Fable délègue simplement plus. Ce qui diffère, c'est quand et quoi ils délèguent. La première passation de Fable arrive tôt. Opus délègue souvent tard, après une longue période d'exploration et d'implémentation en solo ; à ce moment-là, les décisions de conception sont prises, les fichiers importants sont dans son contexte, et le travail coûteux est déjà fait.

Une exécution typique menée par Fable effectue quelques actions de reconnaissance sur le dépôt, puis rédige un brief de qualité spécifications déléguant l'ensemble de la boucle implémentation + test + lint. Ensuite, un git show pour examiner le diff, et un commit.

Une exécution typique menée par Opus passe par 20 à 45 tours d'exploration, de conception et d'implémentation en solo, et une passation tardive pour la queue mécanique.

Parfois, la première action de Fable dans une session est une passation. Sur la même tâche, les deux leaders ont commencé comme ceci :

La correction évidente serait de faire déléguer plus d'exploration à Opus, mais forcer ce comportement tend à diminuer les performances. Savoir quand une investigation peut être déléguée en toute sécurité et quand c'est quelque chose que vous devez faire vous-même est en soi un jugement. Un modèle contraint à déléguer n'acquiert pas ce jugement ; il délègue simplement les mauvaises choses.

Le style de management de chaque modèle se révèle également dans les briefs de passation eux-mêmes. Quand Opus délègue l'implémentation, il dicte, tandis que Fable rédige un document de conception :

La délégation ne déplace pas seulement les coûts ; elle change aussi la qualité du travail. La tâche de hachage ci-dessus en est un exemple frappant. Le cahier des charges exigeait qu'une fonction de hachage soit O(1) par rapport à la longueur du pointeur. Opus l'a implémentée à la main et n'a jamais écrit cette exigence nulle part. En cours de route, il a oublié la contrainte et a livré une implémentation en temps linéaire, qui a obtenu un score de 25. En revanche, Fable a délégué en utilisant des contraintes de haut niveau. Son brief disait : « operator() doit être O(1) en longueur du pointeur : PAS de scan complet de token. » Le sidekick a implémenté cela avec succès pour un score de 94.

Nous avons constaté que ce modèle se généralise à travers les tâches. Les passations de Fable énuméraient les contraintes, les cas limites et une définition du « fait », s'épargnant ainsi des efforts tout en permettant au sidekick de terminer l'implémentation à moindre coût et correctement.

Après la passation

L'autre moitié est ce que l'agent leader fait avec le travail qui revient du sidekick. Les deux leaders effectuent souvent le même contrôle bon marché : deux ou trois appels git diff/git show. Mais Opus ne s'arrête pas là. Il ramène les fichiers du sidekick dans son propre contexte 2x plus souvent et effectue 4x plus de modifications correctives aux prix du leader. Dans le cas extrême, il a annulé le travail du sidekick et l'a réécrit à la main :

La méfiance d'Opus n'augmente pas non plus la justesse. Dans certaines tâches d'évaluation, la révision unique du diff par Fable a détecté de véritables bogues du sidekick, et a opté pour une autre passation bon marché, au lieu de la réécriture au niveau leader qu'Opus utilise si souvent.

Quand la délégation n'aide pas

La stratégie de délégation de Fable n'est pas universellement utile ; elle échoue lorsque la tâche ne comporte pas de composants délégables. Les types de tâches suivants semblaient difficiles à décomposer :

• Les tâches courtes qui ne comprennent qu'une poignée de tours du modèle leader sans rien à déléguer entre la décision et la livraison.
• Les tâches de débogage séquentiel où la recherche de la cause racine est une longue chaîne de jugements. Ici, le contexte accumulé est le travail.

Notablement, sur ces tâches, Fable délègue à peine. Le même jugement qui rédige un bon brief sait aussi quand ne pas en rédiger. Mais quand une tâche n'offre rien qui vaille la peine d'être transmis, la délégation n'a aucun effet de levier sur le coût.

En production, Fusion gère cela à un autre niveau : la délégation contrôle quel travail reste avec le modèle coûteux, tandis que le routage décide si le modèle coûteux est impliqué du tout.

Conclusion

Nous avons commencé cette expérience en nous attendant à mesurer à quel point la prime de 2x de Fable augmenterait le coût. Nous avons été surpris de constater que la délégation efficace de Fable diminuait en fait le coût global. Elle spécifiait des contraintes et des résultats au lieu de détailler l'implémentation, donnait des retours au lieu d'effectuer elle-même les corrections, et dans la plupart des cas, ne touchait jamais au code. Ce sont les habitudes d'un bon manager.

À mesure que les modèles sidekick deviennent moins chers et meilleurs, davantage de travail peut leur être confié. Ce qui restera digne des prix de pointe, c'est le jugement : quoi construire, quoi contraindre, et qui devrait l'écrire.