Orchestration frugale : cinq règles tirées de la facture d'une session multi-agents

Sur ma dernière session de développement multi-agents, plus d’un quart du coût est parti dans l’écriture du même contexte dans des caches, encore et encore. La session a coûté environ 3 450 $. Un orchestrateur répartissait le travail entre des centaines de sous-agents chargés d’implémenter, de tester et de relire du code, sur Claude Opus 5.5 et Claude Fable. Quand j’ai décomposé la facture, les postes évitables les plus lourds n’avaient rien à voir avec l’intelligence des modèles.

• 464 caches de sous-agents ont expiré puis ont été réécrits, à environ 200 000 jetons chacun : 653 $, 19 % du coût.
• 462 nouveaux agents ont chacun écrit un contexte de départ d’environ 90 000 jetons : 277 $, 8 %.
• Les jetons de sortie, les plus chers de la grille tarifaire, ont pesé 20 %.
• L’orchestrateur lui-même a coûté 450 $, 13 %, pour 5 149 réponses.

De cette facture, j’ai tiré cinq règles. Aucune ne demande un meilleur modèle : elles règlent combien de temps un agent attend, combien d’agents naissent, ce qu’ils lisent, ce qu’ils renvoient et jusqu’où grossit l’orchestrateur. L’article sur la guerre des prix se terminait sur le coût d’un dossier traité de bout en bout ; celui-ci ouvre l’un de ses facteurs, l’orchestration, sur une facture réelle.

1. Où est passé l’argent

Lue poste par poste, la facture montre qu’une session d’agents dépense plus à réécrire un contexte qu’elle avait déjà qu’à n’importe quel raisonnement pris isolément.

• Une écriture de cache coûte 1,25 fois le prix d’entrée pour un cache de cinq minutes, et une lecture de cache 0,05 fois sur Opus 5.5 [1]. Écrire un contexte coûte donc 25 fois plus cher que le relire.
• Les expirations et les premiers appels de nouveaux agents ont pris ensemble 27 % du coût. La session a payé sans cesse pour remettre en cache ce qu’elle avait déjà traité.
• La sortie, à 20 %, est l’autre gros poste. Sur Fable, elle est facturée 50 $ par million de jetons [1].
• L’orchestrateur, à 13 %, est la réussite de la session : 5 149 réponses à 0,087 $ en moyenne (voir Figure 1).

Le gaspillage tenait au minutage.

2. Règle 1 : aucun appel d’outil de sous-agent au-delà de quatre minutes

Le cache d’un sous-agent vit cinq minutes, et le compteur continue de tourner pendant que le sous-agent attend le retour d’un outil.

• Claude Code demande un cache d’une heure pour la conversation principale avec un abonnement Claude, dans les limites du forfait, et cinq minutes pour les sous-agents dans tous les cas [2].
• La durée de vie court depuis le début de la requête, génération comprise : « si une réponse met 4 minutes à se diffuser, une requête de suivi qui réutilise le même préfixe en cache doit démarrer dans la minute environ qui suit la fin de cette réponse » [3].
• L’outil Bash, lui, laisse une commande tourner jusqu’à dix minutes par défaut [4]. Le harnais autorise une attente deux fois plus longue que la vie du cache qui attend avec elle.
• Une suite de tests qui bloque six minutes au premier plan oblige donc la requête suivante à réécrire tout le contexte au prix de l’écriture de cache.

Sur la session, c’est arrivé 464 fois, et presque toujours pour la même raison.

• Chaque expiration a imposé une réécriture d’environ 200 000 jetons : 1,00 $ sur Opus 5.5 à 5 $ le million, 2,50 $ sur Fable à 12,50 $ [1]. La moyenne, 1,41 $, se situe entre les deux.
• 85 % des expirations sont survenues juste après une exécution de tests ou une attente sur son verrou, soit environ 394.
• D’où la règle : lancer les longues suites en arrière-plan, puis attendre par tranches de timeout 240. Chaque tranche relit le cache avant son expiration, pour environ 0,04 $ sur Opus 5.5 et 0,05 $ sur Fable 5.1 [1].

Le calcul est déséquilibré, et plus encore sur le modèle le plus cher (voir Figure 2).

• Sur Opus 5.5, une réécriture paie 25 tranches, 100 minutes d’attente avec un cache chaud.
• Sur Fable 5.1, elle en paie 50, soit 200 minutes, parce que la lecture de cache y est facturée 0,025 fois le prix d’entrée contre 0,05 sur Opus 5.5 [1].
• Une suite de 12 minutes coûte 0,12 $ en tranches sur Opus 5.5, contre 1,00 $ pour une attente bloquante.

La règle a deux limites qui méritent d’être écrites dans le harnais lui-même.

• Les tranches ont besoin d’un plafond. Un verrou qui ne se libère jamais achèterait des tranches sans fin ; au-delà d’un nombre fixé, cinq par exemple, le sous-agent doit signaler le verrou à l’orchestrateur au lieu de continuer d’attendre.
• Un cache d’une heure est désormais possible pour les sous-agents, par le réglage subagentPromptCacheTtl depuis Claude Code 2.1.242, ou par un cacheTtl expérimental propre à chaque agent depuis 2.1.248 [2]. Une écriture d’une heure coûte deux fois le prix d’entrée contre 1,25 fois [1], soit un surcoût d’environ 0,60 $ pour un sous-agent qui écrit 200 000 jetons au cours de sa vie sur Opus 5.5. Il se rentabilise sur les agents d’implémentation qui lancent de longues suites, et fait perdre de l’argent sur les relecteurs courts.

Les tranches ne coûtent rien de plus. Elles restent la règle.

3. Règle 2 : créer moins d’agents et réutiliser les agents chauds

Chaque nouvel agent paie sa première requête au prix fort, et une session qui crée des centaines d’agents paie ce prix des centaines de fois.

• La première requête d’un sous-agent ne relit pas le cache de l’agent parent, parce que son prompt système et ses outils diffèrent : il construit son propre cache [2]. Ce contexte de départ porte son prompt système, ses définitions d’outils, les fichiers CLAUDE.md du projet et la tâche [5].
• Sur la session, ce premier appel a écrit environ 90 000 jetons par agent : 277 $ pour 462 agents, 8 % du coût, environ 0,60 $ chacun. Au tarif public, 90 000 jetons écrits coûtent 0,45 $ sur Opus 5.5 et 1,13 $ sur Fable [1].
• Un agent chaud relit le même préfixe pour 0,018 $ sur Opus 5.5, 25 fois moins [1].
• Claude Code relance un sous-agent terminé quand il reçoit un message par SendMessage, sans nouvelle invocation [5]. Après moins de cinq minutes d’inactivité, son cache est encore chaud.
• Des petites relectures regroupées dans un seul agent paient un premier appel au lieu de cinq.
• La documentation de Claude Code estime elle-même qu’une équipe d’agents consomme environ 7 fois les jetons d’une session standard quand ses membres travaillent en mode plan, chacun gardant son propre contexte [6].

La réutilisation a son propre coût, et c’est pourquoi elle reste cantonnée à un même fil de travail.

• Un agent réutilisé emporte la tâche précédente avec lui : ses hypothèses, les pistes qu’il a abandonnées, les fichiers qu’il a lus. Sur l’étape suivante du même travail, cet historique aide. Sur une tâche sans rapport, il gêne.
• Son contexte continue aussi de grossir, et chaque tour suivant le relit.
• Les forks de Claude Code se situent à l’autre extrémité : ils partagent le prompt système, les outils et le cache de la session principale, donc leur première requête coûte peu, mais ils héritent de toute la conversation [5]. Ils conviennent aux tâches qui ont besoin de ce contexte, ce qui est rarement le cas d’un vérificateur.
• Le seul agent à ne jamais réutiliser est l’agent d’implémentation comme vérificateur de son propre travail, pour les raisons de la règle 3.

4. Règle 3 : limiter ce qui entre dans un contexte

Tout ce qui entre dans un contexte se paie de nouveau à chaque tour qui suit : le jeton le moins cher est celui qui n’entre jamais.

• En programmation agentique, c’est l’entrée qui fait le coût. Une étude de huit modèles de pointe sur SWE-bench Verified a mesuré que les tâches agentiques consomment environ 1 000 fois plus de jetons que la conversation sur du code, « les jetons d’entrée, plutôt que les jetons de sortie, déterminant le coût global » [7].
• La règle : lire avec grep -n pour trouver les lignes, puis sed -n pour les afficher, jamais un fichier entier de plus de 300 lignes, et filtrer la sortie des tests à 60 lignes.
• L’essentiel de la sortie des outils est du bruit. Squeez, un petit modèle entraîné à élaguer la sortie des outils des agents de code, retire 92 % des jetons d’entrée en gardant un rappel de 0,86 sur les éléments pertinents [8].
• Le même chiffre marque la limite : 14 % des éléments pertinents manquent. Le journal complet reste sur disque, et l’agent lit plus loin avec sed -n quand 60 lignes n’expliquent pas l’échec.
• Les longs contextes dégradent aussi le travail lui-même. Sur quatre modèles phares engagés dans de longues tâches de recherche, la fréquence à laquelle ils abandonnent bien avant d’avoir épuisé leur contexte augmente avec sa longueur [9].

L’agent d’implémentation s’arrête dès que ses tests ciblés passent, et un agent neuf se charge de la vérification.

• Les modèles notent leur propre travail avec trop d’indulgence. Sur LiveCodeBench, « parmi les critères que les générateurs ne satisfont pas, les juges peuvent être plus de 50 % plus enclins à les marquer à tort comme satisfaits quand la production est la leur » [10].
• Quand ses tests passent enfin, le contexte de l’agent d’implémentation est rempli de tentatives ratées et de sorties de commandes. Y lancer la vérification complète coûte plus cher et voit moins bien.
• Un vérificateur neuf part du diff et du plan, dans un contexte bien plus petit.

L’auteur est le plus indulgent des relecteurs.

5. Règle 4 : limiter ce qui sort

La sortie est le jeton le plus cher de la grille, et elle a pesé un cinquième du coût de la session.

• Fable 5.1 facture la sortie 50 $ par million de jetons : 2,5 fois Opus 5.5 à 20 $, et 5 fois Sonnet 5 à 10 $ [1].
• Sur Fable 5.1, un jeton de sortie coûte autant que 200 jetons d’entrée lus en cache, 50 $ contre 0,25 $ le million [1]. Sur Opus 5.5, le rapport est de 100.
• Le compte rendu d’un sous-agent se paie deux fois : une fois en sortie, puis en entrée à chaque tour suivant de l’orchestrateur, dont il rejoint la conversation [2].
• La règle en découle : un compte rendu porte le verdict, les écarts et les preuves (la commande lancée et son résultat), rien d’autre. Les relecteurs reçoivent un seul diff avec le plan, et répondent brièvement.

La brièveté s’applique au compte rendu, et le raisonnement garde son budget.

• Les jetons de réflexion sont facturés comme de la sortie : l’API indique « combien des jetons de sortie facturés relevaient du raisonnement interne » [11].
• Un compte rendu plus court ne fait pas une relecture plus courte. C’est le réglage d’effort qui en décide, et un relecteur face à un diff risqué a besoin qu’il soit élevé.
• Ce qui disparaît, c’est la prose autour du verdict : le résumé de la tâche, le plan reformulé, les politesses.

Personne ne lit les politesses. Tout le monde les paie.

6. Règle 5 : un petit orchestrateur qui ne scrute jamais

L’orchestrateur relit tout son contexte à chaque réponse : sa taille multiplie le coût de chacun de ses milliers de tours.

• Sur la session, il a répondu 5 149 fois pour 450 $, 13 % du coût, environ 0,087 $ par réponse.
• Sur Opus 5.5, relire 300 000 jetons en cache coûte 0,06 $ par réponse ; à 900 000 jetons, 0,18 $ [1].
• Claude Code compacte par défaut les modèles à un million de jetons vers 967 000 jetons [12]. Je règle le seuil entre 300 000 et 400 000 jetons selon le flux de travail, avec /autocompact, qui accepte toute fenêtre de 100 000 jetons à 1 million, ou avec CLAUDE_CODE_AUTO_COMPACT_WINDOW [12].

Le journal s’écrit avant de compacter, parce que la compaction perd des consignes.

• Un banc d’essai publié en 2026 a mesuré que les outils de compaction actuels ne gardent que 17 % des contraintes qu’un utilisateur fixe en cours de session, et que la plupart font moins bien qu’une absence de compaction. Un extracteur qui tourne à côté de l’outil de compaction porte la rétention au-delà de 90 % [13].
• Le journal joue ce rôle : décisions prises, travail fait, travail restant, contraintes en vigueur, écrits sur disque et relus après la compaction.
• C’est la même discipline que celle des plans et des journaux qui ont pris le relais de Git dans notre pilotage par feuille de route.

L’orchestrateur attend aussi sans regarder.

• Un processus d’attente en arrière-plan par processus long. Une commande lancée avec run_in_background continue de tourner pendant que l’agent poursuit son travail [4], et le harnais réveille l’agent quand elle se termine.
• Pas de Monitor. L’outil renvoie « chaque ligne de sortie à Claude » [4], et chaque ligne qui arrive est un tour de plus pour l’orchestrateur.
• Pas de coups d’œil intermédiaires non plus. À 300 000 jetons sur Opus 5.5, vérifier une suite de 12 minutes toutes les 30 secondes coûte 24 réponses, 1,44 $, là où l’avis de fin en coûte une, 0,06 $.

L’orchestrateur n’a pas besoin non plus du modèle le plus cher, parce que l’essentiel de son coût vient de la relecture de son propre contexte, et deux modèles sortis fin septembre divisent ce prix par deux.

• Claude Sonnet 5.5, sorti le 28 septembre 2026, coûte exactement la moitié d’Opus 5.5 sur chaque ligne de la grille : 2 $ le million de jetons en entrée, 10 $ en sortie, 0,10 $ pour une lecture en cache [1] [14]. À 300 000 jetons en cache, le contexte d’une réponse coûte 0,03 $ au lieu de 0,06 $.
• GPT-6.1 Sol, sorti par OpenAI le lendemain, affiche les mêmes prix jusqu’à 272 000 jetons en entrée : 2 $, 0,10 $ en cache, 10 $ en sortie [15]. Au-delà, « les requêtes de plus de 272 000 jetons en entrée sont facturées 2 fois le tarif d’entrée et de cache, et 1,5 fois le tarif de sortie, pour toute la requête » [16]. Un orchestrateur sur Sol doit donc être compacté sous 272 000 jetons, en dessous de mon seuil habituel.
• Les deux acceptent le niveau d’effort xhigh [12] [16].

Le réglage d’effort descend l’arbre : il se choisit une fois, en haut, et se baisse là où il ne sert pas.

• Dans Claude Code, le champ effort d’un sous-agent « remplace le niveau d’effort de la session » [5] : sans lui, le sous-agent tourne au niveau de la session. Dans une session réglée sur xhigh, un sous-agent Sonnet 5.5 lancé sans réglage d’effort a indiqué xhigh, alors que le niveau par défaut de Claude Code pour ce modèle est medium [12].
• Codex l’écrit en toutes lettres : « si vous ne configurez ni le modèle ni le model_reasoning_effort d’un sous-agent, il hérite du modèle et de l’effort de raisonnement de l’agent parent » [17]. Un piège : un lancement qui choisit un autre modèle sans préciser l’effort reçoit l’effort par défaut de ce modèle.
• D’où ma recommandation pour les longues sessions : Sonnet 5.5 en xhigh, ou GPT-6.1 Sol en xhigh, pour la session, et tout l’arbre travaille à ce niveau par défaut.
• Les jetons de réflexion sont facturés en sortie [11]. Les petits relecteurs reçoivent un niveau plus bas par leur champ effort, ou par le paramètre d’invocation, qui « exige Claude Code v2.1.292 ou ultérieur » [5].

Anthropic se montre plus prudent sur le sommet de l’arbre, et sa prudence fixe la condition sous laquelle un orchestrateur de milieu de gamme tient.

• Son propre billet de lancement écrit qu’« Opus 5.5 reste nettement plus fort sur le travail complexe et ouvert qui exige un jugement soutenu » [14].
• L’économie se réduit aussi avec l’effort : Sonnet 5.5 « complète au mieux Opus 5.5 à des niveaux d’effort plus bas », et aux niveaux plus élevés « il peut faire jeu égal pour un coût similaire » [14]. En xhigh, l’économie vient de la lecture du contexte.
• La configuration d’orchestrateur mesurée par Anthropic place le modèle frontière aux commandes : « le modèle frontière tient la boucle » et répartit les sous-tâches entre des modèles moins chers [18].
• La condition, c’est la méthode. Sur un projet mené selon un flux de développement strict de type UltraCoding, avec une revue critique traçable, des tests sur trois couches et des portes de livraison explicites, le jugement est porté par le processus, et Sonnet peut suffire. Sans cette discipline, le modèle frontière reste au sommet.

Le processus porte le jugement.

La Figure 3 place les cinq règles sur la forme de la session.

Le prix de l’attente

Ces cinq règles ont en commun de donner un prix au temps qu’un agent passe à attendre, à lire et à parler, ce qu’aucun classement de modèles ne montre jamais. Sur la prochaine session, je suis quatre chiffres plutôt qu’une facture.

• Les expirations par agent, et ce qui a précédé chacune.
• Les premiers appels par tâche livrée.
• La part de sortie par rôle : orchestrateur, agents d’implémentation, relecteurs.
• La taille du contexte de l’orchestrateur à chaque réponse.

Les seuils des règles (quatre minutes, 300 lignes, 60 lignes, 300 000 jetons) sont les miens, et ils bougeront avec les prix et les outils. Le mécanisme, lui, restera : un cache qui expire à heure fixe, un contexte payé de nouveau à chaque tour, un jeton de sortie qui vaut cent jetons lus en cache.

Le premier métier d’un orchestrateur est de bien attendre.

Les chiffres viennent de mes propres journaux d’une seule session, pas d’un banc d’essai ; le total est déduit des parts, et les parts se recoupent pour les jetons de sortie. Les coûts unitaires sont calculés sur les tarifs publics d’Anthropic relevés le 27 septembre 2026, pour Opus 5.5 et Fable 5.1 et un contexte de 200 000 jetons, sans les quelques centaines de jetons qu’ajoute chaque tranche. Les comportements de Claude Code sont ceux documentés à la même date. La partie sur le modèle de l’orchestrateur, ajoutée le 11 octobre 2026, s’appuie sur des prix relevés ce jour-là : le billet de lancement de Sonnet 5.5 donne 0,20 $ pour la lecture en cache, là où la page de tarifs retenue ici donne 0,10 $.

Sources

1. Anthropic, Pricing, documentation de la plateforme Claude, lue le 27 septembre et le 11 octobre 2026.
2. Anthropic, How Claude Code uses prompt caching, documentation de Claude Code, lue le 27 septembre 2026.
3. Anthropic, Prompt caching, documentation de la plateforme Claude, lue le 27 septembre 2026.
4. Anthropic, Tools reference, documentation de Claude Code, lue le 27 septembre 2026.
5. Anthropic, Create custom subagents, documentation de Claude Code, lue le 27 septembre et le 11 octobre 2026.
6. Anthropic, Manage costs effectively, documentation de Claude Code, lue le 27 septembre 2026.
7. Longju Bai, Zhemin Huang, Xingyao Wang, Jiao Sun, Rada Mihalcea, Erik Brynjolfsson, Alex Pentland et Jiaxin Pei, « How Do AI Agents Spend Your Money? Analyzing and Predicting Token Consumption in Agentic Coding Tasks », arXiv:2604.22750, 24 avril 2026, révisé le 29 avril 2026.
8. Ádám Kovács, « Squeez: Task-Conditioned Tool-Output Pruning for Coding Agents », arXiv:2604.04979, 4 avril 2026.
9. Shijie Xia, Yikun Wang, Zhen Huang et Pengfei Liu, « Diagnosing and Mitigating Context Rot in Long-horizon Search », arXiv:2606.29718, 29 juin 2026, révisé le 4 août 2026.
10. José Pombal, Ricardo Rei et André F. T. Martins, « Self-Preference Bias in Rubric-Based Evaluation of Large Language Models », arXiv:2604.06996, 8 avril 2026, révisé le 3 août 2026.
11. Anthropic, Extended thinking, documentation de la plateforme Claude, lue le 27 septembre 2026.
12. Anthropic, Model configuration, documentation de Claude Code, lue le 27 septembre et le 11 octobre 2026.
13. Zhiqi Wang, Yichi Zhang, Dongwon Lee et Yuchen Yang, « Lost in Compaction: Evaluating Side-Constraint Loss under Context Compaction », arXiv:2608.11242, 31 juillet 2026.
14. Anthropic, Introducing Claude Sonnet 5.5, 28 septembre 2026.
15. OpenAI, Changelog, documentation de l’API OpenAI, entrée du 29 septembre 2026 annonçant GPT-6.1 Sol.
16. OpenAI, GPT-6.1 Sol, documentation de l’API OpenAI, lue le 11 octobre 2026.
17. OpenAI, Subagents, documentation de Codex, lue le 11 octobre 2026.
18. Anthropic, Optimizing for cost and intelligence, documentation de la plateforme Claude, lue le 11 octobre 2026.