En bref

Un agent solo sur Claude Opus 4.5 coûte environ 9 dollars pour une session de 20 minutes. Le même travail confié à un harness planner + generator + evaluator revient à 200 dollars sur six heures — soit un facteur 22×, mesuré par Anthropic sur un cas concret de génération de logiciel. Les agents consomment en général 4× plus de tokens que les interactions chat ; les systèmes multi-agents, 15× plus. Ce surcoût n’est pas distribué uniformément : il provient de quelques mécanismes précis, identifiables et partiellement contrôlables. Et sur les tâches standards de développement logiciel, des études empiriques montrent que les agents solo peuvent surpasser les architectures multi-agents en qualité — tout en coûtant trois fois moins cher.

En clair : pensez à un chantier de construction. Un seul artisan polyvalent qui fait tout, c’est 9 unités de coût. Trois artisans spécialisés qui se passent les plans, se relisent et se corrigent, c’est 200 unités — et le résultat n’est pas forcément meilleur. La coordination coûte cher, le contexte qu’on transmet entre artisans coûte cher, et chaque vérification ajoute des heures. Le multi-agents n’est rentable que quand le solo ne sait vraiment pas faire seul.


Le cas $9 → $200 : que s’est-il passé ?

Anthropic a publié en mars 2026 une analyse détaillée de l’architecture “harness” qu’ils utilisent pour des tâches de développement logiciel longues. Le point de départ : un agent solo (Claude Opus 4.5) génère un retro game maker en une session de 20 minutes pour environ 9 dollars. La même catégorie de tâche, confiée à un harness complet avec un agent planificateur, un agent générateur, et un agent évaluateur QA, coûte 200 dollars sur six heures.

Un second run documenté sur une tâche différente (station de travail audio) permet de voir la décomposition interne (Anthropic Engineering, mars 2026) :

  • Planificateur : 0,46 dollar — moins de 0,4% du total
  • Phases de construction (3 rounds de génération) : 113,85 dollars — 91,3% du total
  • Phases QA : 10,39 dollars — 8,3% du total
  • Total : 124,70 dollars sur 3h50

La surprise : l’orchestration elle-même est presque gratuite. Le planificateur coûte moins d’un dollar. Ce qui coûte cher, c’est le travail réel — la génération répétée de code par le generator, appel après appel, avec un contexte qui grossit à chaque tour. Comprendre le surcoût oblige donc à regarder ailleurs que dans “l’overhead d’orchestration” au sens étroit.


Anatomie des coûts : quatre sources distinctes

1. La recréation du system prompt à chaque sous-agent

Chaque sous-agent est une session API indépendante. Il instancie son propre system prompt depuis zéro, ce qui signifie que les instructions système sont facturées en tokens input à chaque nouvel appel. Pour un system prompt de 8 000 tokens sur Claude Sonnet 4.6 (3 dollars par million de tokens input), chaque agent ajoute 0,024 dollar de coût fixe de démarrage. Sur cinquante appels par agent dans une session longue, cela représente 3,60 dollars de recréation pure — pour un seul agent (Anthropic — Prompt caching documentation).

Le prompt caching change radicalement ce calcul : la première écriture coûte 1,25× le tarif standard, mais chaque lecture suivante ne coûte que 0,1× — soit une réduction de 85% dès le deuxième appel. Le breakeven est atteint au deuxième appel. Au-delà de trois sous-agents partageant le même préfixe d’instructions, la réduction sur cette composante dépasse 70%.

La contrainte technique : en déploiement parallèle de sous-agents, il faut lancer le premier agent avec un léger décalage (0,5 seconde suffit) pour lui laisser le temps de créer l’entrée de cache avant que les suivants ne l’interrogent.

2. L’overhead de coordination : supra-linéaire avec le nombre d’agents

Une étude de décembre 2024 (arxiv:2512.08296) a mesuré l’overhead de coordination selon le type d’architecture multi-agents, en comparant le nombre de tokens consommés par rapport à un agent solo :

ArchitectureOverhead vs. agent soloEfficacité (succès / 1 000 tokens)
Agent solo0%67,7
Multi-agents indépendants+58%42,4
Multi-agents décentralisé+263%23,9
Multi-agents centralisé+285%21,5
Multi-agents hybride+515%13,6

La loi de scaling observée sur le nombre de tours d’interaction est T = 2,72 × (n + 0,5)^1,724, avec un R² de 0,974. Autrement dit : doublez le nombre d’agents, et les tours d’interaction n’augmentent pas de 2× mais de plus de 3×. Cette relation supra-linéaire est l’explication structurelle du facteur 15× documenté par Anthropic pour les systèmes multi-agents par rapport aux interactions chat standards.

3. Le scaffolding de framework : un coût invisible

Le choix du framework d’orchestration n’est pas neutre. Un benchmark sur un pipeline à trois agents, traité à 10 000 requêtes par jour avec GPT-4o, mesure un écart significatif entre LangGraph (~800 tokens par requête, ~32 dollars par jour) et CrewAI (~1 250 tokens par requête, ~50 dollars par jour). L’écart de 450 tokens correspond aux définitions de rôle automatiques que CrewAI injecte pour chaque agent — environ 150 tokens par agent de scaffolding non contrôlable par l’utilisateur. [Cette mesure provient d’une source unique et doit être considérée comme indicative.]

LangGraph offre un contrôle granulaire sur les prompts ; CrewAI abstrait cette couche au prix d’un overhead systématique. Le choix d’architecture encode donc un coût récurrent, invisible ligne à ligne mais significatif à l’échelle.

4. Les boucles de vérification : le coût exponentiel de l’erreur

Un benchmark empirique sur sept frameworks (arxiv:2511.00872) mesure que le système multi-agents AgentOrchestra consacre 41,54% de sa trajectoire à des tentatives de correction — contre une moyenne de 4,81% pour les agents solo. Le coût total varie de 2,13 dollars (agent solo GPTswarm) à 370,19 dollars (AgentOrchestra multi-agents) pour les mêmes 1 200 tâches de développement logiciel.

Le mécanisme sous-jacent est structurel. Une boucle Reflexion sur dix cycles peut consommer 50× plus de tokens qu’un passage linéaire unique, car chaque tour inclut l’historique complet de la conversation accumulée (Stevens Online). Tour 1 = 200 tokens. Tour 10 = 200 tokens plus neuf fois la taille de chaque output précédent. La complexité en contexte est en O(n²) pour un LLM seul qui s’auto-corrige.

En clair : les quatre sources de coût ont des profils très différents. Le system prompt à chaque sous-agent est gratuit avec prompt caching dès le 2ᵉ appel (-85%). L’overhead de coordination, lui, scale en supra-linéaire — doubler le nombre d’agents triple les tours d’interaction. Le scaffolding de framework est invisible mais permanent. Les boucles de vérification sont les plus dangereuses : elles peuvent multiplier la facture par 50× sans qu’on s’en aperçoive.


Les contre-données : l’agent solo surpasse parfois le multi-agents

Une conclusion qui revient dans plusieurs études indépendantes : les agents solo avec des prompts optimisés peuvent égaler ou dépasser les architectures multi-agents sur les tâches standard, à une fraction du coût.

L’étude arxiv:2511.00872 conclut explicitement que “les systèmes mono-agents démontrent systématiquement de meilleures performances que les systèmes multi-agents” sur les tâches de développement logiciel standard. OpenHands, un agent solo, surpasse AgentOrchestra en qualité de résultat tout en coûtant 115 dollars contre 370 pour 1 200 tâches identiques. La différence de performance provient en grande partie du fait qu’un agent solo peut maintenir un contexte cohérent sur l’ensemble de la tâche, là où un système multi-agents doit résumer et transmettre ce contexte entre agents — avec les pertes d’information que cela implique.

Un résultat de terrain va dans le même sens : réduire de 80% le nombre d’outils disponibles pour un agent améliore ses résultats (Vercel, cité par Aakash Gupta). Moins d’options, moins d’hésitation, moins de tokens de délibération sur quel outil appeler. La simplification de l’interface de chaque agent est souvent plus efficace que l’ajout d’une couche de coordination.

Un atelier ICLR 2025 sur les modèles de fondation en conditions réelles note la même tendance : “des agents solo avec des prompts optimisés peuvent correspondre aux performances multi-agents tout en économisant des tokens.”

Ces contre-données ne signifient pas que le multi-agents est inutile. Elles délimitent le périmètre où il l’est réellement — et rappellent que la complexité architecturale a un coût propre qui doit être justifié, pas présupposé.


Quand le surcoût est justifié

Anthropic formule le critère de décision de façon directe dans son guide harness (Anthropic Engineering, mars 2026) : “L’évaluateur vaut le coût quand la tâche dépasse ce que le modèle fait de façon fiable en solo.” Et, plus fondamentalement, dans “Building Effective Agents” (2024) : “Les systèmes agentiques troquent souvent latence et coût contre de meilleures performances — il faut se demander quand ce compromis a du sens.”

Trois cas où le facteur multiplicateur se justifie empiriquement :

La parallélisation réelle. Anthropic rapporte un gain de performance de 90,2% pour son système de recherche multi-agents (un lead Opus 4 coordonnant des sous-agents Sonnet 4) par rapport à un agent solo Opus 4, sur des tâches où les recherches peuvent être conduites en parallèle. Le temps de traitement est divisé, et la couverture de l’espace de recherche augmente. C’est le cas d’usage où le multi-agents a l’avantage le plus clair.

Le dépassement de la fenêtre de contexte. Lorsque la tâche ne tient pas dans une seule fenêtre de contexte, le multi-agents n’est pas une option parmi d’autres — c’est la seule option. L’architecture Chain of Agents de Google Research réduit la complexité de O(n²) à O(nk) en découpant le contexte entre agents spécialisés, ce qui la justifie économiquement pour les tâches à très long contexte.

La spécialisation avec cascade de modèles. Le projet BudgetMLAgent (IIT Bombay, AIMLSystems 2024) atteint une réduction de 94,2% des coûts — de 0,931 dollar à 0,054 dollar par run — en routant les sous-tâches mécaniques vers des modèles moins coûteux ou gratuits, tout en obtenant un taux de succès supérieur à GPT-4 solo (32,95% contre 22,72%). Le multi-agents peut coûter moins cher qu’un agent solo haut de gamme quand le dispatch est intelligent.

Le problème de dépréciation

Un avertissement pratique : chaque composant d’un harness encode une hypothèse sur ce que le modèle ne sait pas faire seul. Anthropic l’explicite directement dans son article de mars 2026 — “Every component in a harness encodes an assumption about what the model can’t do.” Sur Opus 4.5, un évaluateur QA externe était nécessaire pour certaines tâches. Sur Opus 4.6, ces mêmes tâches entrent dans la fenêtre de compétence native du modèle — l’évaluateur devient du surcoût inutile.

Un investissement de “milliers d’heures d’ingénierie” (Aakash Gupta) dans un harness complexe se déprécie donc à chaque nouvelle génération de modèle. Le rythme de progression des capacités de base des LLM est actuellement suffisamment rapide pour que certaines architectures multi-agents deviennent obsolètes avant d’avoir amorti leur coût de développement.

La baisse des prix des API LLM — environ 80% en douze mois selon pricepertoken.com — modifie également le calcul : des systèmes auparavant non viables à 200 dollars par run peuvent devenir acceptables à 40 dollars avec les nouveaux tarifs. Mais si cette baisse incite les équipes à augmenter la complexité de leurs architectures proportionnellement, l’économie réalisée disparaît. Le ROI réel des harnesses complexes n’est pas quantifié dans la littérature disponible, ce qui est lui-même un signal d’alerte pour les équipes qui investissent massivement dans ces structures.


Ce qu’il faut retenir

  • Un système multi-agents consomme jusqu’à 15× plus de tokens qu’une interaction chat standard ; un harness complet peut coûter 22× plus qu’un agent solo sur la même tâche (Anthropic Engineering, mars 2026).
  • Le coût principal est porté par l’agent de travail (91% dans le cas documenté), pas par l’orchestration. Le planificateur coûte moins d’un dollar.
  • Le prompt caching réduit de 85% le coût de recréation du contexte dès le deuxième appel — c’est le levier d’optimisation le plus immédiat pour un harness en production.
  • Sur les tâches de développement logiciel standard, les agents solo avec des prompts optimisés surpassent en général les architectures multi-agents en qualité et en coût (arxiv:2511.00872).
  • Le multi-agents est justifié dans trois cas précis : parallélisation réelle des sous-tâches, dépassement de la fenêtre de contexte, et cascade de modèles avec dispatch intelligent.