Cloud Intelligence™
Plus de tokens, moins de dépenses : pourquoi le comptage de tokens classe les coûts d'agents IA à l'envers
Une comparaison de six workloads d'agents, menée sur une journée et un seul compte, a montré que c'est le coût de compute, et non le volume de tokens, qui déterminait les moins chers.
Cette page est également disponible en English, Deutsch, Español, Italiano, 日本語 et Português.
Les chiffres sont relevés directement sur des captures d'écran du dashboard d'un compte sandbox DoiT, et non modélisés à partir d'une grille tarifaire.
Plus de tokens, moins de dépenses : pourquoi le comptage de tokens classe les coûts d'agents IA à l'envers
TL;DR : le comptage de tokens et le coût des agents IA peuvent évoluer en sens opposé. Dans un sandbox AWS en conditions réelles, le 2026-08-15, les trois agents consommant le plus de tokens étaient les trois moins chers à faire tourner, et les trois agents en consommant le moins étaient les trois plus coûteux : une inversion complète. La raison tient au compute, pas aux tokens : chaque agent s'exécute comme son propre service Fargate de longue durée, et Fargate représentait 57 à 80 % du coût quotidien pour les trois workloads disposant d'une décomposition complète par ressources, et à peine 26 % pour un quatrième workload plus léger. AWS Cost Explorer ne peut pas du tout afficher le coût par agent : il regroupe tous les agents dans une seule ligne au niveau du service. C'est une décomposition des ressources par workload qui fait apparaître le classement caché derrière la facture.
Si vous classez le coût de vos agents IA selon la consommation de tokens, vous le classez peut-être précisément dans le mauvais ordre.
Le 2026-08-15 UTC, une journée consolidée dans notre compte doit-apj-attribute-sandbox en
us-east-1, les trois agents d'une application consommant le plus de tokens étaient aussi les trois
moins chers, et les trois agents en consommant le moins étaient les trois plus coûteux. L'écart de
tokens entre ces deux groupes atteint un facteur de deux et demi, et il va dans le sens opposé
des dollars. L'arrondi d'affichage est très loin de pouvoir expliquer un tel écart.
Chaque chiffre en dollars et en tokens ci-dessous est relevé directement sur cinq captures d'écran de ce compte sandbox : un rapport AWS Cost Explorer et quatre vues DoiT Attribute, tous consultés en direct. Aucun n'est modélisé à partir d'une grille tarifaire. Les pourcentages et les taux par million sont issus de nos propres calculs sur ces chiffres affichés, signalés comme tels là où ils apparaissent, et la mention estimated charges propre à Cost Explorer s'applique à sa colonne. Une sixième image, plus loin dans le billet, est un schéma d'architecture illustratif, et non une capture de dashboard.
Ce qu'AWS Cost Explorer ne peut pas vous dire sur le coût des agents IA
Commencez par AWS Cost Explorer pour cette journée : granularité quotidienne, regroupement par service, coûts amortis.
La colonne du 2026-08-15 :
Total costs $9.98Elastic Container Service $5.99Claude Haiku 4.5 (Bedrock Edition) $2.24VPC $1.01Claude Opus 5 (Bedrock Edition) $0.70Exact, et inutile pour répondre à cette question. Tous les agents de l'application se partagent
cette unique ligne Fargate à $5.99 et cette unique ligne Haiku à $2.24. La facture possède une
dimension service et une dimension compte. Elle n'a aucune dimension agent : elle ne peut donc pas
classer les agents, dans un sens comme dans l'autre.
Prêtez attention aux notes de bas de page du rapport lui-même : les dates sont en UTC, et les chiffres de la période de facturation en cours sont signalés comme des estimations.
L'inversion des coûts d'agents IA
Le même jour, dans Attribute à la maille workload, avec un filtre sur les workloads luminara-*
du compte sandbox :
Le total Cost (1 Day) $8.8 affiché par cette vue est la somme des sept workloads luminara-*
présentés ici, filtrés sur ce seul compte. Il n'est pas comparable au total de $9.98 de
Cost Explorer ci-dessus, qui couvre l'ensemble des coûts du compte, et pas seulement les dépenses
Fargate et modèle de ces sept workloads.
En relevant les six workloads d'orchestration et spécialisés luminara-* de cette liste :
| Workload | Tokens | Coût | Rang tokens | Rang coût |
|---|---|---|---|---|
luminara-orchestrator |
125.75K | $1.48 | 4 | 1 |
luminara-chain |
123.73K | $1.48 | 5 | 1 |
luminara-conditional |
115.27K | $1.46 | 6 | 3 |
luminara-route |
315.01K | $1.23 | 1 | 4 |
luminara-sites |
265.49K | $1.16 | 2 | 5 |
luminara-dining |
169.64K | $1.07 | 3 | 6 |
Le regroupement forme une inversion parfaite. Les trois workloads consommant le moins de tokens
sont les trois plus coûteux, et les trois workloads en consommant le plus sont les trois moins
chers. La paire la plus frappante oppose luminara-route à luminara-orchestrator : 2,5 fois
plus de tokens, et $0.25 de moins sur la journée.
Les trois premiers se tiennent à $0.02 près : leur ordre interne n'est donc pas significatif à cette précision d'affichage. L'inversion au niveau des groupes dépasse largement cette marge.
Si votre dashboard est un compteur de tokens, cette application semble dominée par
luminara-route, qui est en réalité le moins cher des six.
Pourquoi le compute, et non les tokens, décide du classement des coûts d'agents IA
Chaque agent luminara-* s'exécute comme son propre service ECS Fargate de longue durée qui
appelle Bedrock pour l'inférence. Ce fait structurel explique pourquoi une ligne Fargate existe,
distincte de la ligne modèle : Fargate facture le compute provisionné dans la durée, Bedrock
facture au token consommé, et il s'agit de deux axes de coût indépendants.
- Le client envoie une requête au service ECS Fargate de l'agent.
- Le service Fargate exécute la boucle de l'agent et appelle Amazon Bedrock pour l'inférence LLM.
- Bedrock renvoie la réponse du modèle au service Fargate.
- Pour
luminara-toolcalluniquement, le service Fargate appelle la Gateway Bedrock AgentCore pour invoquer des outils. - La Gateway distribue les appels vers trois fonctions Lambda derrière quatre outils.
- Pour
luminara-orchestratoruniquement, le service Fargate écrit des événements d'audit dans la file SQSluminara-trajectory-audit. - Le service Fargate renvoie la réponse finale au client.
Attribute décompose chaque workload en ses ressources. Les vues détaillées des deux extrêmes expliquent l'inversion.
luminara-orchestrator — Total resources cost: $1.48 (1 - 3 Out of 3)
luminara-poc EC2-ECS $1.18 20%us.anthropic.claude-haiku-4-5-20251001-v1 AmazonBedrock $0.30 125.75K Tokens 13%luminara-trajectory-audit AWSQueueService $0.00 --
luminara-route — Total resources cost: $1.23 (1 - 2 Out of 2)
luminara-poc EC2-ECS $0.70 12%us.anthropic.claude-haiku-4-5-20251001-v1 AmazonBedrock $0.53 315.01K Tokens 24%luminara-route dépense effectivement plus pour le modèle, $0.53 contre $0.30. Il est malgré
tout devancé, car la ligne Fargate de l'orchestrateur s'élève à $1.18 contre $0.70 pour route.
Les pourcentages figurant sur ces deux captures (20%, 13%, 12%, 24%) correspondent à la
métrique Resource Accountability d'Attribute pour chaque ligne de ressource, et non à une part
du coût du workload ; ils sont reproduits tels qu'affichés. Les parts Fargate ci-dessous relèvent
de nos propres calculs sur les totaux en dollars, soit un chiffre différent.
En calculant les parts à partir de ces chiffres :
| Workload | Fargate | Modèle | Part Fargate |
|---|---|---|---|
luminara-orchestrator |
$1.18 | $0.30 | 80 % |
luminara-route |
$0.70 | $0.53 | 57 % |
Le compute représente la majorité du coût quotidien dans les deux cas, et c'est la variable qui décide du classement. Les tokens ne sont que le terme minoritaire, qu'un dashboard fondé sur les tokens traite pourtant comme la totalité du coût.
luminara-dining écarte l'hypothèse d'une coïncidence limitée à deux points de mesure :
luminara-dining — Total resources cost: $1.07 (1 - 2 Out of 2)
luminara-poc EC2-ECS $0.70 12%us.anthropic.claude-haiku-4-5-20251001-v1 AmazonBedrock $0.38 169.64K Tokens 17%Il affiche la même ligne Fargate à $0.70 que luminara-route, deux services spécialisés
dimensionnés à l'identique, tandis que l'orchestrateur se situe à $1.18. Un quatrième workload,
luminara-toolcall, affiche $0.24 de Fargate sur une journée à $0.93, soit 26 %, à l'extrémité
basse du même spectre. La décomposition par ressources derrière ce chiffre est conservée parmi les
éléments de preuve, mais n'est pas reproduite dans ce billet.
Nous ne présentons pas la prédominance du compute comme une découverte nouvelle. Une capture de
dashboard sur 30 jours, conservée et arrêtée au 2026-08-21, avait déjà mesuré la part EC2-ECS de
luminara-orchestrator à 71 %, et nous ne la citons que pour montrer que la même tendance se
vérifie sur une fenêtre différente. C'est la conséquence qui est nouvelle ici. Parce que le terme
compute domine et varie selon le rôle du workload, il décide du classement, et le classement
qu'il produit est l'inverse du classement par tokens. Nous n'avançons aucune affirmation sur des
architectures au-delà de ces workloads.
La troisième ressource de l'orchestrateur, luminara-trajectory-audit, est une ligne
AWSQueueService à $0.00. Attribute inventorie la ressource même lorsqu'elle ne coûte rien ce
jour-là : c'est ainsi que vous découvrez que cet agent dépend d'une file d'attente.
Cloud bill shouldn't be a mystery
One platform for AI and Cloud optimization.
Ce que cela implique pour le suivi des coûts d'agents IA
Le comptage de tokens n'est pas un indicateur du coût total d'un agent IA
Il ne reflète que le coût de la ligne modèle, et sur les trois workloads que nous avons analysés
en détail, la ligne modèle représentait entre 20 % et 43 % du coût quotidien du workload. Toute
vue de coût par agent construite uniquement sur des objets usage classera mal le parc d'agents dès que
les empreintes de compute diffèrent, c'est-à-dire dès que les agents diffèrent par leur rôle
d'orchestration, comme un orchestrateur central face à des workloads spécialisés plus ciblés.
Classer les agents IA par coût a nécessité une vue du compute par workload
La comptabilité des tokens côté client ne voit pas du tout Fargate. La facture voit Fargate et le regroupe en une seule ligne. La décomposition par workload ci-dessus est la contribution spécifique d'Attribute ici, et c'est elle qui a inversé la conclusion.
Rien de tout cela n'en fait un classement d'efficience. Ces workloads accomplissent des tâches différentes à des volumes de requêtes différents ; ce qui est mesuré ici est le coût quotidien par workload, et non le coût par requête, par objectif atteint ou par unité de qualité. Moins cher par jour ne signifie pas moins cher par unité de travail.
FAQ
Une consommation de tokens plus élevée signifie-t-elle un coût d'agent IA plus élevé ? Pas nécessairement. Dans cette analyse, les trois agents consommant le plus de tokens étaient les trois moins chers à faire tourner, et les trois agents en consommant le moins étaient les trois plus coûteux. Le volume de tokens ne reflète que la ligne modèle, pas le coût total d'exécution de l'agent.
Pourquoi AWS Cost Explorer ne peut-il pas afficher le coût par agent IA ? Cost Explorer regroupe par service et par compte, pas par agent. Tous les agents d'une application partagent les mêmes lignes Fargate et Bedrock : il n'existe donc aucune dimension dans la facture permettant de ventiler le coût par agent individuel.
Qu'est-ce qui détermine le coût d'un agent IA, si ce ne sont pas les tokens ? Le compute. Sur les trois workloads disposant d'une décomposition complète par ressources, la ligne de compute Fargate représentait 57 à 80 % du coût quotidien contre 20 à 43 % pour la ligne modèle ; la part Fargate d'un quatrième workload plus léger descendait jusqu'à 26 %. Le coût varie selon le rôle d'orchestration, pas selon le nombre de tokens qu'un workload consomme.
Comment mesurer le coût par agent IA sur une infrastructure partagée ? En décomposant chaque workload en ses ressources sous-jacentes, telles que le compute, les appels au modèle et toute autre ressource facturée comme une file d'attente, plutôt qu'en s'appuyant sur le comptage de tokens ou une ligne de facturation agrégée. Attribute le fait au niveau du workload à partir de données d'exécution plutôt que de tags.
L'estimation des coûts basée sur les tokens est-elle fiable pour les systèmes d'IA agentique ? Pas à elle seule. Les tokens ne reflètent que la ligne modèle. Une vue fondée uniquement sur les tokens peut mal classer les workloads lorsque leurs coûts de compute diffèrent, comme ce fut le cas pour les six workloads mesurés ici.
Évaluer correctement le coût des agents IA exige une vue du compute par workload, pas un comptage de tokens.
