🚀 Subagent-tax : coût des sous-agents IA (tokens)

Le préambule n'est pas « payé une fois » par tâche

La première version du calcul traitait le préambule fixe comme un coût payé lors de l'appel Task(). Avec un préambule de 51 000 tokens, l'estimation restait donc à 51 000 tokens, que le sous-agent ait ensuite un ou plusieurs tours.

Le problème, c'est que ce n'est pas toujours comme ça que l'interaction se comporte en pratique. Les schémas d'outils et une partie du préambule peuvent se retrouver dans le contexte à chaque appel d'API. Si un sous-agent fait trois tours et que le préambule pèse 51 000 tokens, on arrive à un ordre de grandeur de 51 000 × 3, soit 153 000 tokens de contexte cumulés rien que pour ces tours.

Et ce n'est pas seulement une question de total. Chaque tour doit aussi réussir à faire tenir son contexte dans la fenêtre disponible. Un calcul qui ne compte le préambule qu'une fois peut donc masquer à la fois le coût répété et la pression sur la fenêtre de contexte.

Chaque sous-agent repart de zéro

Le second facteur, c'est le lancement lui-même. Un appel Task() crée un nouveau contexte de sous-agent. Le préambule est donc réengagé au démarrage : il n'est pas automatiquement « hérité » du contexte du parent, ni de celui d'un sous-agent précédent.

C'est un multiplicateur. Si votre système lance beaucoup de sous-agents, le coût fixe du contexte initial se répète. Une tâche ponctuelle paraît raisonnable. La même opération répétée des dizaines (ou des centaines) de fois devient un poste qui compte.

Un lecteur de l'article d'origine, aidiveyt, rapporte par exemple 2 631 exécutions de sous-agents représentant 48,1 % de l'ensemble des tokens observés dans son cas. Ça décrit un scénario réel, mais ça ne doit pas être pris comme une « moyenne universelle ». Le volume dépend de la fréquence des appels, du préambule, du nombre de tours et de la façon dont les outils réinjectent leur contexte.

Pourquoi l'erreur est gênante en production

Si l'estimation est trop basse, on finit par prendre de mauvaises décisions : multiplier les sous-agents pour gagner du temps, puis découvrir que le coût d'inférence (ou les limites de contexte) monte beaucoup plus vite que prévu. L'inverse existe aussi : supprimer les sous-agents « par principe » peut dégrader la qualité ou ralentir un flux de travail qui, lui, en profite vraiment.

Autrement dit, le bon raisonnement n'est pas « les sous-agents coûtent trop cher » ni « ils sont toujours plus efficaces ». Le point, c'est de rendre le coût visible par appel, de le comparer à ce qui est réellement délégué, puis de décider où la parallélisation apporte une valeur mesurable.

Une estimation par tour et par type de sous-agent

La version 0.3 reprend le cadre de facturation corrigé présenté dans mcp-tax 0.3, mais l'applique aux sous-agents. Le rapport produit un registre par type de sous-agent : par exemple Explore ou Plan. Il liste le nombre d'appels, le multiplicateur de lancement et les volumes estimés par appel.

La logique est la suivante :

1. Estimer le préambule associé au contexte du sous-agent.
2. Estimer le nombre de tours effectués par chaque tâche.
3. Répéter le calcul pour chaque lancement de sous-agent.
4. Ajouter le surcoût de lancement et le traitement du résultat.
5. Prendre en compte les tokens facturables après effets du cache.

Dans l'exemple fourni par l'auteur, un sous-agent est estimé à trois tours en moyenne. Avec un préambule de 51 000 tokens, ça fait 153 000 tokens de contexte cumulés avant de tenir compte des autres éléments. Ensuite, une estimation autour de 155 000 tokens par appel peut intégrer d'autres coûts selon les paramètres et les données prises en compte.

Le « nombre de tours = 3 » n'est pas une mesure directement visible dans le transcript du parent : les échanges internes au sous-agent ne sont pas forcément exposés. C'est donc une heuristique, ajustable via --turns-per-task. Il faut lire le rapport comme une estimation paramétrable, pas comme une télémétrie exacte.

Les trois paramètres à comprendre

Subagent-tax expose trois réglages qui bougent le résultat :

• --turns-per-task : nombre estimé de tours internes à chaque tâche. C'est lui qui fait varier la répétition du préambule.
• --spawn-overhead : volume associé au payload de Task() et au traitement du résultat. Dans l'exemple, la valeur donnée est de 2 000 tokens par appel.
• --cache-hit-rate : proportion estimée de tokens concernés par un cache hit, utilisée pour ajuster les tokens facturables.

Ces paramètres ne se remplacent pas l'un l'autre. Si vous sous-estimez le nombre de tours, vous minorez fortement la partie « coût récurrent ». Si vous surestimez le surcoût de lancement, vous attribuez trop de tokens à la délégation. Le mieux est de partir de valeurs explicites, puis de les rapprocher de ce que vous pouvez réellement mesurer dans votre environnement.

Cache : coût facturé et occupation du contexte, ce n'est pas la même chose

Le cache peut réduire la facture, mais il ne supprime pas le contenu de la fenêtre utilisée par le modèle. C'est pour ça que le rapport distingue billable_tokens et cumulative_window_tokens.

Au démarrage, un nouveau sous-agent commence avec un cache froid. Le tour de départ est donc compté comme un cache miss, même si des interactions précédentes ont déjà « chauffé » le cache. Et le cache TTL peut aussi provoquer des misses si le contexte n'est pas réutilisé assez vite.

Cette nuance est importante. Un cache qui marche bien peut faire baisser la facture, sans rendre le préambule « plus petit » dans le contexte effectivement traité. Si votre problème est la limite de fenêtre ou la répétition d'informations, regarder uniquement les tokens facturables ne suffit pas : il faut aussi regarder les tokens cumulés dans la fenêtre.

Lire le registre sans se tromper de colonnes

Dans l'extrait d'exemple, pour chaque type, on trouve : le nombre d'appels, le multiplicateur, les tokens par appel, les tokens cumulés dans la fenêtre et les tokens facturables. Pour Explore, il est question de 90 appels et 155 000 tokens par appel, soit 13 950 000 tokens cumulés. Pour Plan, 31 appels donnent 4 805 000 tokens.

L'extrait annonce ensuite un total corrigé de 20 460 000 tokens, contre 6 732 000 avec l'ancien modèle. Mais les deux lignes visibles additionnent 18 755 000 tokens, pas 20 460 000. Le rapport complet peut inclure d'autres lignes absentes de l'extrait ; sans elles, on ne reconstitue pas le total annoncé à partir de seulement ce qu'on voit. Dans un budget, mieux vaut donc vérifier le registre complet et les paramètres avant de s'appuyer sur un total agrégé.

Une installation simple pour prendre un premier repère

Le projet annonce une dépendance à la bibliothèque standard de Python, une licence MIT et 61 tests automatisés : 48 déjà présents et 13 ajoutés pour cette version. Ça réduit la friction d'installation et donne un aperçu du niveau de vérification du projet, sans remplacer vos tests dans votre propre environnement.

Pour l'installation et le lancement :

pip install subagent-tax
subagent-tax

Pour les options, les formats de sortie et les versions, voir la publication de subagent-tax 0.3. Le comportement dépend de ce que l'outil peut lire dans les données disponibles : vérifiez notamment que vos journaux correspondent bien à la période et au flux que vous cherchez à comprendre.

Une méthode de mesure en quatre étapes

Pour obtenir un résultat vraiment exploitable, évitez de lancer l'outil une seule fois puis de retenir un chiffre « au hasard ». Le plus utile, c'est de comparer :

1. Choisissez un périmètre représentatif. Prenez une tâche courante, un lot de travail, ou une période clairement identifiable. Évitez de mélanger essais ponctuels et flux de production stable.
2. Fixez les hypothèses. Notez les valeurs de --turns-per-task, --spawn-overhead et --cache-hit-rate. Si le nombre de tours n'est pas observé, précisez qu'il s'agit d'une estimation.
3. Regardez les résultats par type. Un total global peut masquer un sous-agent particulièrement coûteux ou lancé trop souvent. Comparez les appels et les tokens par catégorie.
4. Changez une seule variable à la fois. Réduisez le nombre de lancements, ajustez le préambule, ou modifiez le découpage de la tâche, puis comparez sur un périmètre identique.

Ce cadre évite deux pièges fréquents : attribuer à un « cache qui aide » une baisse qui vient en réalité d'un plus petit nombre d'appels, ou déclarer un type de sous-agent inefficace alors qu'il a juste traité une tâche atypique.

Mettre le coût en face du travail obtenu

Un sous-agent n'est pas utile parce qu'il consomme « peu ». Il est utile quand ce qu'il produit justifie la ressource engagée : temps gagné, meilleure couverture d'un dépôt, moins d'erreurs, ou un meilleur résultat final.

Pour chaque type de tâche, vous pouvez suivre des indicateurs simples :

• nombre d'appels de sous-agent par tâche terminée ;
• tokens de contexte cumulés par résultat accepté ;
• proportion de résultats rejetés ou repris par le parent ;
• délai total, en incluant les appels supplémentaires ;
• évolution des coûts facturables quand le cache est pris en compte.

Une analyse de code qui évite une régression coûteuse peut valoir davantage qu'une génération répétée à faible valeur. À l'inverse, si le parent doit presque toujours refaire le travail, le coût du sous-agent ne s'arrête pas au démarrage : il faut ajouter la reprise et les échanges supplémentaires.

Un outil d'estimation, pas une facture fournisseur

Subagent-tax rend explicite un modèle de coût. Il ne remplace pas les données de facturation de votre fournisseur, ni les métriques natives de votre plateforme. Les tours internes peuvent être estimés plutôt qu'observés, et le comportement du cache ou du contexte peut varier selon les modèles et l'orchestration.

Donc, pour piloter un budget, comparez le rapport à ce que vous avez déjà : compteurs d'usage, factures, journaux d'appels ou tableaux de bord du fournisseur. Si ça ne colle pas, commencez par comparer périmètres, définitions et périodes. « Tokens cumulés dans la fenêtre » et « tokens facturés » ne veulent pas dire la même chose.

Des comparaisons utiles, tant que les hypothèses restent figées

Le gros intérêt d'un modèle explicite, c'est de tester des scénarios. Estimer l'effet d'une hypothèse « deux tours au lieu de trois », comparer un préambule réduit à un préambule complet, ou voir ce qui se passe si vous divisez par deux le nombre d'appels.

Mais une comparaison ne vaut que si le reste reste constant. Si vous changez à la fois le modèle, le nombre de tours, la taille du préambule et le cache, vous ne saurez pas quel changement a fait quoi. Dans un système qui bouge, gardez les hypothèses et la période de chaque mesure.

Quand réduire le nombre de sous-agents

Le registre peut montrer qu'un type de sous-agent est appelé très souvent pour un travail relativement limité. Avant de le supprimer, regardez pourquoi il est lancé. Il est possible de regrouper des tâches, de produire un résultat intermédiaire réutilisable, ou de réduire les informations répétées dans son préambule.

Mais consolider a aussi un coût : une tâche plus grosse se parallélise parfois moins bien, et les erreurs peuvent être plus difficiles à isoler. Et réduire les instructions pour diminuer le préambule peut dégrader la qualité ou la sécurité du résultat. Économiser des tokens n'est pas une amélioration si ça augmente le taux d'échec et multiplie la correction.

La décision se prend donc à l'échelle du système : coût total, qualité, latence, capacité à diagnostiquer les erreurs, contraintes de fenêtre. Le but n'est pas de minimiser chaque appel, mais d'éviter les répétitions sans valeur.