Mon orchestrateur d'agents a consommé 1 à 2 millions de tokens Opus par tâche.

Comment les coûts ont explosé

L'orchestrateur a été conçu pour Claude Code et utilisait une hiérarchie de sous-agents. Chaque sous-agent héritait des paramètres du parent, exécutait son propre prompt et renvoyait le résultat dans la boucle jusqu'à ce qu'un réviseur déclare la sortie « propre ». L'outil accomplissait les tâches, mais le coût était astronomique.

Trois « taxes » cachées ont multiplié le nombre de tokens :

  • Taxe de modèle – Les sous-agents ne spécifiaient jamais de modèle, ils utilisaient donc par défaut Opus, le niveau le plus coûteux. Une opération mineure qui aurait pu tenir sur un modèle moins cher (Haiku ou Sonnet) était facturée au tarif Opus.
  • Taxe de cache – La mise en cache des prompts ne réutilise que les correspondances exactes, octet par octet. Comme chaque sous-agent ajoutait des instructions personnalisées, chaque appel forçait une écriture en cache à froid. Le cache du parent ne pouvait pas être réutilisé, gaspillant ainsi les économies qu'un cache partagé procure normalement.
  • Taxe de boucle – La règle « boucler jusqu'à ce que ce soit propre » maintenait le processus actif tant qu'un réviseur trouvait une faille. Sans plafond strict, la boucle tournait jusqu'à ce que le modèle s'arrête.

Ensemble, ces multiplicateurs ont transformé quelques lignes de code en une avalanche de tokens.

Pourquoi la règle budgétaire dans le prompt a échoué

La conception initiale tentait de limiter les dépenses en intégrant une règle budgétaire directement dans le prompt système. En théorie, dire au modèle « reste sous X tokens » aurait dû limiter l'utilisation. En pratique, une règle basée sur un prompt n'est qu'une préférence. À mesure que la session s'allonge, le modèle compresse le contexte et peut carrément supprimer ou ignorer ces instructions. Résultat : le modèle se comportait comme si la règle n'avait jamais existé.

Passer de l'application par le prompt à l'application par le code

La refonte a extrait la logique budgétaire du prompt pour la placer dans un système de hooks déterministes que le modèle ne peut pas contourner.

  1. Sélection explicite du modèle – Chaque envoi de sous-agent nécessite désormais un choix de modèle concret (Haiku, Sonnet ou Opus). L'héritage silencieux a disparu, de sorte que les tâches peu coûteuses restent peu coûteuses.
  2. Garde-fous stricts via un hook PreToolUse – Avant l'exécution de tout outil, le hook vérifie :
    • Le nombre d'envois déjà effectués dans la session.
    • Si le modèle choisi respecte un niveau minimum (pour éviter l'utilisation accidentelle d'Opus).
    • Un nombre maximum d'itérations de boucle, après quoi le processus s'interrompt.

Si un garde-fou est déclenché, le code interrompt le sous-agent ; le modèle de langage n'a aucun moyen de contester la décision.

Ce que cela signifie pour les développeurs

Tout système imposant des plafonds de dépenses, des politiques de sécurité ou des limites sur des commandes destructrices devrait traiter ces contraintes comme du code, et non comme des directives conversationnelles. Un prompt peut être écrasé, ignoré ou perdu dans la compression interne du modèle. Le code, en revanche, s'exécute de manière déterministe et peut être audité.