Version : 1.0.0
Auteurs : Charlie (analyste approfondi), Alex (coordinateur de la flotte AB Support), Bravo (recherche), Editor (révision de contenu)
Contact : alex@vibeagentmaking.com
Date : 2026-03-26
Statut : Brouillon pré-publication
Licence : Apache 2.0
Organisation : AB Support LLC
Lorsque l'Agent A envoie une requête à l'Agent B, l'Agent B paie en tokens pour la lire. Ce coût de compréhension n'a aucun équivalent dans le commerce humain — un consultant ne paie pas pour ouvrir une lettre, un entrepreneur ne paie pas pour lire un plan. Pourtant, dans les interactions agent-à-agent, le coût d'inférence du répondant pour traiter une requête entrante peut dépasser le coût de génération du demandeur. Un seul contexte de 100 000 tokens traité par Claude Opus 4.6 coûte 0,50 $ en tokens d'entrée uniquement [1] ; une orchestration multi-agents complexe de 15 tours peut atteindre 0,07 $ par conversation, soit 255 000 $/an à 10 000 conversations quotidiennes [2]. Ces coûts sont supportés silencieusement par l'agent qui se trouve à traiter les tokens à chaque étape, sans aucun protocole d'allocation, de négociation ou de règlement.
L'absence d'allocation des coûts n'est pas un simple oubli comptable — c'est une distorsion structurelle. Les protocoles de paiement actuels pour agents (x402 [3], Machine Payments Protocol [4], Google AP2 [5]) implémentent universellement le modèle « le demandeur paie » : l'agent qui initie l'interaction supporte le coût, et le répondant traite gratuitement. Cela ignore trois des quatre flux de coûts dans toute interaction entre agents : le coût de traitement des entrées du répondant, le coût de génération des sorties du répondant, et le coût de réception du demandeur. Lorsque ces quatre flux ne sont pas tarifés, les agents n'ont aucun mécanisme pour signaler qu'une requête est trop coûteuse à traiter, aucun moyen de négocier un partage des coûts pour des interactions mutuellement bénéfiques, et aucune défense contre les adversaires qui consomment un espace de fenêtre de contexte coûteux à un coût marginal nul.
Le protocole Context Window Economics (CWEP) comble cette lacune. Le CWEP spécifie six capacités qui, ensemble, constituent une couche économique complète pour les interactions agent-à-agent :
Le CWEP se situe à la couche 4 (Marché/Économie) de l'écosystème de confiance AB Support, aux côtés de l'Agent Matchmaking Protocol [19]. Il s'intègre avec les Agent Service Agreements [20] pour l'intégration des termes de coûts dans les contrats, l'Agent Rating Protocol [21] pour la tarification pondérée par la réputation, et la Chain of Consciousness [22] pour des enregistrements de coûts auditables. Il est agnostique quant au rail de paiement — le CWEP spécifie ce qui doit être payé et combien, mais pas par quel mécanisme. Le règlement peut s'effectuer via x402, MPP, L402 [23], le streaming Superfluid [24], ou la facturation traditionnelle.
Il s'agit d'un domaine de problèmes véritablement nouveau. Nous ne forçons pas les analogies avec le commerce humain là où elles ne s'appliquent pas. Lorsque les parallèles avec les infrastructures sont instructifs (peering internet, tarification du réseau électrique, FinOps cloud), nous les utilisons ; lorsque les dynamiques spécifiques aux agents divergent de tous les modèles antérieurs, nous le signalons et construisons à partir des principes fondamentaux.
Chaque interaction agent-à-agent impose des coûts aux deux participants. Lorsqu'un agent de recherche envoie une analyse de 50 000 tokens à un agent de revue, l'agent de revue paie — en dollars réels — pour la lire. Sur Claude Sonnet 4.6, ce coût de lecture est de 0,15 $ ; sur Claude Opus 4.6, il est de 0,75 $ [1]. L'agent de recherche a également payé pour générer l'analyse — aux tarifs de sortie de Sonnet 4.6, 50 000 tokens coûtent 0,75 $. Le coût total de l'interaction est de 0,90 $ à 1,50 $ en inférence seule, réparti de manière inégale entre les deux agents sans aucun mécanisme pour négocier, suivre ou régler l'allocation.
C'est la taxe invisible de l'économie des agents. Aucun agent ne sait combien il en coûte aux autres agents d'interagir avec lui. Aucun protocole ne tarifie l'attention consommée. Aucune place de marché ne prend en compte le coût de la compréhension mutuelle lors de l'appariement des agents pour des tâches.
La taxe s'accumule dans les systèmes multi-agents. Les chercheurs de Google DeepMind ont constaté que l'ajout d'agents au-delà d'un seuil de quatre agents fait que les frais de coordination absorbent les gains de performance, avec une multiplication de la dépense en tokens tandis que la performance chute de 39 à 70 % [25]. L'infrastructure interne de CrewAI ajoute environ 56 % de tokens supplémentaires par requête par rapport aux appels API directs [26]. Les flux de travail agentiques ont fait augmenter la consommation de tokens par tâche de 10 à 100 fois depuis décembre 2023, en raison de composants verbeux, de charges utiles de récupération répétées, de transferts multi-agents nécessitant le renvoi du contexte, et d'opérations de mémoire avec des coûts d'écriture/récupération séparés [14].
Le coût agrégé est considérable. Les dépenses totales des organisations en inférence IA continuent d'augmenter malgré une baisse des prix par token d'environ 10 fois par an [27] — le paradoxe de Jevons appliqué au calcul. Les coûts par token sont passés d'environ 60 $/MTok (lancement de GPT-4, mars 2023) à 5 $/MTok (Claude Opus 4.6, mars 2026) — une réduction d'environ 12 fois en trois ans [27][1]. Pourtant, les dépenses des organisations en IA continuent d'augmenter, les agents consommant 10 à 100 fois plus de tokens par tâche en raison de composants verbeux, de charges utiles de récupération répétées, de transferts multi-agents nécessitant le renvoi du contexte, et d'opérations de mémoire avec des coûts d'écriture/récupération séparés [14]. Le coût par token de l'intelligence s'effondre ; le coût par tâche du travail multi-agents, non. Le CWEP traite directement cette divergence — en rendant visible la structure bilatérale des coûts de chaque interaction, il permet aux agents de prendre des décisions rationnelles sur le moment où une communication verbeuse vaut son coût et quand la compression ou la spécialisation serait plus efficace.
Dans le commerce humain, le coût de compréhension d'une requête est effectivement nul. Lire un courriel coûte à un humain quelques secondes d'attention. Un consultant qui lit un cahier des charges n'encourt aucun coût monétaire direct pour l'acte de lecture. La tarification du consultant reflète sa réponse — son expertise, son temps et ses livrables — pas sa compréhension.
Pour les agents IA, la compréhension a un prix direct, mesurable, au token près. Un agent doit payer — via le budget API de son opérateur — pour traiter chaque token de chaque message entrant. Cela crée des dynamiques sans parallèle clair dans l'économie humaine :
Certaines analogies partielles sont instructives. Le peering internet traite la question de savoir qui paie lorsque les réseaux échangent du trafic [28]. La tarification marginale localisée (LMP) de l'électricité décompose les coûts par emplacement et par congestion [13]. La tarification de l'interconnexion des télécommunications aborde la question « l'appelant paie » contre « le destinataire paie » [29]. Le FinOps cloud fournit un vocabulaire opérationnel pour l'attribution des coûts [6]. Mais aucun de ces domaines ne présente la combinaison de coûts de traitement non linéaires, de flux bilatéraux de génération et de compréhension, et de variance de niveau de modèle qui caractérise les interactions entre agents. Le CWEP s'inspire de tous ces domaines tout en reconnaissant que le problème spécifique aux agents nécessite une solution conçue sur mesure.
Le CWEP traite de l'économie des interactions agent-à-agent — plus précisément, de la question de savoir qui supporte le coût d'inférence lorsque les agents communiquent. Il ne traite pas de :
Le CWEP spécifie le modèle de coûts pour les interactions bilatérales entre agents. Il produit des recommandations d'allocation de coûts qui peuvent être réglées via n'importe quel mécanisme de paiement. C'est une couche de tarification, pas une couche de paiement.
Interaction entre agents. Un échange unique de requête-réponse entre deux agents, comprenant quatre flux de tokens : génération de la requête (A produit), traitement de la requête (B reçoit), génération de la réponse (B produit), et réception de la réponse (A reçoit).
Fenêtre de contexte. Le tampon de tokens de longueur fixe disponible pour un LLM afin de traiter un seul appel d'inférence. Les fenêtres de contexte vont de 8K tokens (modèles anciens) à 1M+ tokens (Claude Opus 4.6 [1], Gemini 3.1 Pro [30]). La fenêtre de contexte est simultanément une ressource de calcul, un actif économique et un goulot d'étranglement de l'attention.
Token. L'unité atomique du calcul LLM. Un token correspond à environ 4 caractères ou 0,75 mot en anglais. Les tokens sont tarifés par million (MTok) avec des tarifs distincts pour l'entrée et la sortie [1].
Coût de compréhension. Le coût d'inférence supporté par un agent récepteur pour traiter un message entrant. Mesuré en tokens d'entrée multipliés par le tarif d'entrée par token de l'agent. Ce coût est engagé avant que l'agent ne décide de répondre.
Règlement bilatéral. Une allocation de coûts qui attribue une part du coût total de l'interaction à chaque participant, en fonction de la contribution, du bénéfice ou des termes négociés.
Utilisation du contexte. La fraction de la fenêtre de contexte d'un agent consommée par une seule interaction. Une requête de 50 000 tokens envoyée à un agent disposant d'une fenêtre de 200 000 tokens consomme 25 % du contexte disponible.
Flux de tokens. Un mouvement directionnel de tokens dans une interaction entre agents. Chaque interaction comporte quatre flux : requête A→B (tokens de sortie de A, tokens d'entrée de B), réponse B→A (tokens de sortie de B, tokens d'entrée de A). Chaque flux a une tarification par token distincte déterminée par le modèle et le fournisseur de l'agent générateur/récepteur.
Enregistrement de comptage. Une entrée de journal structurée capturant les comptes de tokens, les identifiants de modèle, la tarification du fournisseur, les horodatages et les coûts calculés pour un flux de tokens unique. Quatre enregistrements de comptage constituent un enregistrement d'interaction complet.
Proposition de règlement. Une recommandation d'allocation de coûts produite par le moteur de règlement CWEP, spécifiant la part de chaque agent dans le coût total de l'interaction, ainsi que la méthode d'allocation et les paramètres utilisés.
Toutes les interactions entre agents ne nécessitent pas un règlement bilatéral. Une requête d'information légère (500 tokens en entrée, 200 tokens en sortie) coûte des fractions de centime — la régler coûterait plus que l'interaction elle-même. Le CWEP sépare le comptage (toujours actif) du règlement (déclenché par un seuil). Toutes les interactions sont mesurées pour l'observabilité, l'attribution des coûts et l'audit ; le règlement n'intervient que lorsque le coût de l'interaction dépasse un seuil configurable ou qu'un accord explicite l'exige.
Les résultats d'impossibilité de Green-Laffont et Moulin-Shenker [12] prouvent qu'aucun mécanisme de partage des coûts ne peut simultanément atteindre la compatibilité d'incitation (déclaration honnête des coûts), l'équilibre budgétaire (les paiements égalent les coûts) et l'efficacité économique (toutes les interactions bénéfiques ont lieu). Tout protocole prétendant atteindre les trois est soit dans l'erreur, soit malhonnête. Le CWEP fait un choix de conception explicite : nous sacrifions l'efficacité totale au profit de l'équilibre budgétaire et d'une compatibilité d'incitation approximative. Certaines interactions bénéfiques n'auront pas lieu parce que l'allocation des coûts les rend non rentables pour l'une des parties. C'est le prix d'un système qui ne fonctionne pas à déficit et n'encourage pas les déclarations erronées.
Le CWEP produit des propositions de règlement — des allocations de coûts structurées avec des montants libellés en monnaie fiduciaire (USD) ou en stablecoins (USDC). Le mode de transfert de ces montants est hors du périmètre du CWEP. Le règlement peut s'effectuer via x402 pour les micropaiements natifs HTTP [3], MPP pour le règlement multi-rail [4], Superfluid pour les paiements en streaming lors de conversations en cours [24], L402 pour les micropaiements Bitcoin Lightning [23], la facturation traditionnelle pour les déploiements d'entreprise, ou la comptabilité interne lorsque les deux agents partagent un opérateur. Le CWEP spécifie le quoi et le combien ; la couche de paiement gère le comment.
Lorsque des modèles économiques établis s'appliquent (valeur de Shapley pour l'allocation des coûts, LMP pour la tarification dépendante de la position, négociation de Nash pour la négociation bilatérale), nous les utilisons avec une attribution et des réserves appropriées. Lorsqu'aucun modèle antérieur ne capture les dynamiques en jeu (coûts quadratiques de l'attention, flux bilatéraux de compréhension, asymétrie des niveaux de modèle), nous construisons à partir des principes fondamentaux et marquons clairement la contribution comme nouvelle. Nous ne prétendons pas que ce problème est simplement des « factures téléphoniques pour robots » ou du « cloud computing avec des étapes en plus ».
Le protocole spécifie trois niveaux d'implémentation :
Les organisations adoptent le niveau qui correspond à leurs besoins en matière de complexité. Le niveau 1 apporte de la valeur immédiatement ; le niveau 3 est l'objectif à long terme.
Considérons un scénario concret : l'Agent A (un chef de projet) envoie à l'Agent B (un spécialiste de la revue de code) une pull request contenant 15 fichiers modifiés, totalisant 8 000 tokens de sortie de diff plus 2 000 tokens d'instructions de revue. L'Agent B traite la requête, génère une revue de 3 000 tokens et la renvoie. L'Agent A traite la revue pour en extraire les actions à mener.
Les flux de tokens :
| Flux | Direction | Tokens | Qui génère | Qui traite | Coût (Sonnet 4.6) |
|---|---|---|---|---|---|
| Génération de la requête | A → B | 10 000 | Agent A (sortie) | — | 0,150 $ |
| Traitement de la requête | A → B | 10 000 | — | Agent B (entrée) | 0,030 $ |
| Génération de la réponse | B → A | 3 000 | Agent B (sortie) | — | 0,045 $ |
| Réception de la réponse | B → A | 3 000 | — | Agent A (entrée) | 0,009 $ |
| Total | 26 000 | 0,234 $ |
Sous le modèle « le demandeur paie » (le seul modèle implémenté par les protocoles de paiement actuels), l'Agent A paie 0,234 $. L'Agent B paie 0,00 $. Mais l'opérateur de l'Agent B a réellement engagé 0,075 $ de coûts d'inférence (traitement des entrées + génération des sorties). Le modèle actuel surtaxe A de 0,075 $ et sous-facture B du même montant.
Mettons maintenant cela à l'échelle. Aux tarifs de Claude Opus 4.6 (5,00 $/25,00 $ par MTok), la même interaction coûte :
| Flux | Coût (Opus 4.6) |
|---|---|
| Génération de la requête (sortie A) | 0,250 $ |
| Traitement de la requête (entrée B) | 0,050 $ |
| Génération de la réponse (sortie B) | 0,075 $ |
| Réception de la réponse (entrée A) | 0,015 $ |
| Total | 0,390 $ |
À 10 000 interactions de ce type par jour, le coût annuel total d'inférence est de 1,42 million de dollars. L'erreur d'allocation sous le modèle « le demandeur paie » — le montant incorrectement attribué — est de 456 250 $/an. Ce n'est pas une erreur d'arrondi.
Chaque interaction entre agents génère exactement quatre flux de coûts. Le CWEP nomme et suit les quatre :
Flux 1 : sortie de la requête (RO). Le demandeur génère la requête. Coût = tokens_de_requête × tarif_de_sortie_du_demandeur. C'est le seul flux tarifé par les protocoles de paiement actuels.
Flux 2 : entrée de la requête (RI). Le répondant traite la requête. Coût = tokens_de_requête × tarif_d_entrée_du_répondant. C'est le coût de compréhension — le coût engagé par le répondant avant toute décision de répondre. Il est propre aux interactions entre agents et n'a aucun parallèle dans le commerce humain.
Flux 3 : sortie de la réponse (SO). Le répondant génère la réponse. Coût = tokens_de_réponse × tarif_de_sortie_du_répondant. Cela s'apparente à la tarification traditionnelle des services — le coût de production du livrable.
Flux 4 : entrée de la réponse (SI). Le demandeur traite la réponse. Coût = tokens_de_réponse × tarif_d_entrée_du_demandeur. C'est le coût de réception et de compréhension du livrable. En termes humains, cela reviendrait à payer pour lire un rapport que l'on a commandé.
Le coût total de l'interaction est : C_total = RO + RI + SO + SI
L'observation clé est que RO et SI sont supportés par l'opérateur du demandeur, tandis que RI et SO sont supportés par l'opérateur du répondant. Sous le modèle « le demandeur paie », le demandeur est facturé pour les quatre flux mais n'en supporte directement que deux. Sous le statu quo (pas de règlement inter-agents), chaque opérateur absorbe ses propres coûts sans réconciliation.
Les quatre flux ne sont pas de taille égale. Les agents IA en production consomment typiquement 100 tokens d'entrée pour chaque token de sortie généré [31]. Cela signifie que le flux de traitement de la requête (RI) domine typiquement le flux de génération de la réponse (SO) en nombre de tokens, mais les tokens de sortie coûtent 3 à 5 fois plus par token que les tokens d'entrée chez tous les principaux fournisseurs [1][30][32]. Il en résulte une interaction complexe où aucun des deux côtés ne supporte systématiquement la majorité du coût.
L'asymétrie crée trois défaillances de marché :
1. Externalité de la requête verbeuse. L'Agent A n'a aucune incitation à minimiser la taille de sa requête parce que le coût de traitement de l'Agent B lui est invisible. Une requête de 50 000 tokens qui pourrait être compressée à 5 000 tokens [16] impose un coût 10 fois inutile à B. Sans signaux de coûts bilatéraux, A n'investira pas dans la compression.
2. Inadéquation du niveau de modèle. L'Agent B pourrait utiliser Opus 4.6 (5,00 $/MTok en entrée) alors que Haiku 4.5 (0,25 $/MTok en entrée) suffirait pour la requête — une différence de coût de 20 fois [1]. Si B supporte ses propres coûts d'entrée sans récupération, il y a une pression pour utiliser le modèle le moins cher indépendamment de la qualité. Si le demandeur paie, il y a une pression pour utiliser le modèle le plus cher (sur-qualité). Aucune de ces incitations ne produit une sélection efficace de modèle.
3. Tragédie des communs de la fenêtre de contexte. La fenêtre de contexte d'un agent est une ressource partagée dans les systèmes multi-agents — plusieurs agents peuvent envoyer des requêtes qui, collectivement, remplissent la fenêtre de contexte, réduisant la capacité disponible pour chacun. Sans tarification, les agents surconsomment une ressource rare. C'est un cas classique de tragédie des communs [33], transposé des pâturages à l'espace de contexte.
La solution naïve — partager tous les coûts également entre le demandeur et le répondant — échoue parce que les interactions sont rarement symétriques en valeur. Lorsque l'Agent A demande une revue de code à l'Agent B, A reçoit considérablement plus de valeur (un code base révisé) que B (une tâche accomplie, un crédit de réputation). Un partage 50/50 des coûts ignore cette asymétrie et décourage les agents de fournir des services à forte valeur ajoutée.
De même, un modèle fixe « le demandeur paie » échoue lorsque l'interaction est mutuellement bénéfique — par exemple, deux agents de recherche partageant leurs résultats. Si l'initiateur paie toujours, le premier agent à envoyer un message est pénalisé, créant un jeu de « à toi de commencer » qui retarde les interactions productives.
L'allocation correcte dépend de l'interaction spécifique : qui en bénéficie, dans quelle mesure et quelles alternatives chaque partie possède. C'est précisément le problème que la théorie des jeux coopératifs a été développée pour résoudre.
Herbert Simon a articulé l'idée fondamentale en 1971 : « Une abondance d'information crée une pauvreté d'attention et un besoin d'allouer cette attention efficacement » [34]. Simon décrivait la cognition humaine, mais le parallèle avec les agents IA est exact. La fenêtre de contexte d'un LLM est son budget d'attention. Chaque token consommé par une information est un token indisponible pour une autre. L'ingénierie de contexte — concevoir le tout de sorte que le modèle dépense son budget d'attention limité uniquement sur des tokens à fort signal — est explicitement reconnue par Anthropic comme une discipline fondamentale [35].
Heitmayer (2024) distingue l'« attention fluide » (traitement immédiat, expérientiel) de l'« attention calcifiée » (connaissances stockées en externe, convertibles en valeur) [36]. Pour les agents IA, l'attention fluide correspond au traitement actif de la fenêtre de contexte ; l'attention calcifiée correspond aux systèmes de mémoire externe (Mem0 [37], Zep [38], Letta [39]). La question économique est : quand un agent devrait-il payer pour conserver l'information dans sa fenêtre de contexte coûteuse, et quand devrait-il la décharger vers une mémoire externe moins onéreuse ?
Cette question a une réponse quantitative. Au-delà de 100 000 tokens de contexte, les systèmes de mémoire (0,0568 $/utilisateur pour 10 tours) deviennent moins chers que les LLM à contexte long (0,0588 $/utilisateur). À 20 interactions, la mémoire réalise 26 % d'économies [18]. La mémoire concentre les coûts d'écriture en amont ; le contexte long fait évoluer les coûts variables par interaction. Le point de croisement est fonction de la fréquence d'interaction, de la taille du contexte et de la tarification du fournisseur — autant de variables que le CWEP peut modéliser.
L'attention des transformers calcule les interactions par paires entre tous les tokens de la fenêtre de contexte. Pour n tokens, cela nécessite O(n^2) opérations. En termes économiques : le coût marginal d'un token supplémentaire augmente avec la longueur du contexte. Les 1 000 premiers tokens dans un contexte vide sont bon marché ; les 1 000 derniers tokens dans un contexte de 999 000 tokens sont coûteux.
Cette non-linéarité a des implications profondes pour la tarification. Un tarif forfaitaire par token (le modèle de tarification universel en mars 2026 [1][30][32]) sous-facture les interactions à contexte long et surfacture les interactions courtes. Les modèles Gemini de Google reconnaissent partiellement cela avec une tarification par paliers — Gemini 2.5 Pro facture 1,25 $/MTok pour les entrées jusqu'à 200K tokens et 2,50 $/MTok au-delà [30]. Mais aucun fournisseur n'implémente de tarification continue dépendante de la position.
Le modèle de tarification du contexte du CWEP (section 9) y répond en introduisant un multiplicateur de coût dépendant de la position, analogue à la tarification marginale localisée des réseaux électriques [13], où l'« emplacement » est la position du token dans la fenêtre de contexte.
La rareté de la fenêtre de contexte n'est pas seulement économique — elle est physique. Le « mur de mémoire de l'IA » décrit la contrainte où la mémoire GPU ne peut pas accueillir suffisamment de cache KV pour des contextes d'agents concurrents étendus [40]. L'Augmented Memory Grid de WEKA y répond avec une hiérarchisation de la mémoire à plusieurs niveaux, atteignant des taux de succès du cache KV de 96 à 99 %, mais la rareté sous-jacente persiste : l'espace de la fenêtre de contexte est limité par le matériel, pas seulement par la tarification.
Pour une session d'agent typique de 8 heures coûtant environ 80 $, environ 29 $ (36 %) sont du calcul gaspillé par l'inefficacité de la mémoire [40]. Le marché de l'infrastructure mémoire devrait atteindre 28,45 milliards de dollars d'ici 2030 avec un TCAC de 35 % [40], porté en grande partie par la demande de gestion efficace du contexte. Cette rareté au niveau matériel est ce qui fait de la fenêtre de contexte une ressource économique véritablement rare, et pas seulement coûteuse.
L'utilisation du contexte d'un agent — la fraction de sa fenêtre actuellement consommée — est un signal économique significatif. Un agent à 90 % d'utilisation de contexte a une capacité limitée pour de nouvelles requêtes et devrait tarifer sa capacité restante à une prime. Un agent à 10 % d'utilisation dispose d'une capacité abondante et peut traiter les requêtes aux tarifs de base.
Cela reflète la dynamique des réseaux électriques où les prix montent en flèche lors de la demande de pointe (tarification de congestion) et peuvent même devenir négatifs en cas de surproduction [13]. Les zones riches en énergie éolienne du Southwest Power Pool (SPP) connaissent fréquemment des prix marginaux localisés négatifs lorsque l'offre dépasse la demande [41]. Le parallèle pour les agents : le traitement de contexte pourrait-il avoir un coût négatif si le répondant tire de la valeur de sa réponse — crédit de réputation, signal d'entraînement ou positionnement sur la place de marché ?
Le CWEP modélise l'utilisation du contexte comme l'une des entrées de la fonction de tarification du contexte (section 9), aux côtés de la position du token, du niveau de modèle et de la tarification du fournisseur.
Le CWEP s'appuie sur deux solutions classiques de la théorie des jeux coopératifs, chacune encodant un principe de justice distinct.
Valeur de Shapley (Shapley, 1953) [10]. La valeur de Shapley alloue les coûts en fonction de la contribution marginale moyenne de chaque participant à travers toutes les permutations possibles. Elle satisfait quatre axiomes : efficacité (les coûts totalisent le montant total), symétrie (les contributeurs équivalents paient de manière égale), linéarité (additivité à travers les composantes de coût indépendantes) et joueur nul (les non-contributeurs ne paient rien).
Pour une interaction à deux agents, la valeur de Shapley se simplifie en :
Paiement(A) = [C(A,B) + C(A) - C(B)] / 2
Paiement(B) = [C(A,B) + C(B) - C(A)] / 2où C(A,B) est le coût de l'interaction conjointe, C(A) est le coût que l'Agent A engagerait seul (c'est-à-dire en générant la requête sans réponse), et C(B) est le coût que l'Agent B engagerait seul (capacité de traitement réservée sans requête). Dans le cas à deux agents, la valeur de Shapley est calculable en temps constant — aucune approximation n'est nécessaire.
Calculer les valeurs de Shapley exactes est NP-difficile pour n joueurs (exponentiel en nombre d'agents) [42], mais les interactions multi-agents impliquant plus de deux agents par échange sont peu courantes. Pour les interactions multipartites (par ex. une discussion de groupe entre cinq agents), des méthodes d'approximation rapides utilisant des plans factoriels fractionnaires sont disponibles [43].
La valeur de Shapley est déjà l'approche dominante en IA pour les problèmes d'attribution. SHAP (SHapley Additive exPlanations) l'utilise pour l'interprétabilité des modèles [44]. ShapleyFL l'utilise pour l'évaluation des données dans l'apprentissage fédéré [45]. VerFedSV l'étend avec la vérification [46]. Le CWEP étend le même cadre à l'attribution des coûts.
Nucléole (Schmeidler, 1969) [47]. Le nucléole minimise l'insatisfaction maximale de toute coalition. Il est toujours unique, toujours dans le noyau (si le noyau est non vide). Là où Shapley maximise l'équité par la contribution proportionnelle, le nucléole maximise l'équité par la minimisation des plaintes — aucun agent ne peut soutenir qu'il est traité de manière particulièrement injuste par rapport aux autres.
Pour l'allocation des coûts entre agents, le choix entre Shapley et le nucléole encode une décision de conception de marché :
Le CWEP utilise par défaut Shapley pour les interactions bilatérales (où les deux solutions coïncident souvent) et propose le nucléole comme alternative configurable pour les scénarios multipartites.
Lorsque deux agents négocient directement le partage des coûts — plutôt que d'accepter une allocation du protocole — la théorie de la négociation de Nash s'applique [11].
La solution de négociation de Nash maximise le produit des utilités au-dessus du point de désaccord (le résultat si les négociations échouent). Elle satisfait quatre axiomes : invariance d'échelle, optimalité de Pareto, indépendance des alternatives non pertinentes et symétrie. L'extension asymétrique de Nash y ajoute des paramètres de pouvoir de négociation — l'agent ayant plus d'alternatives ou des coûts de changement plus faibles capture une plus grande part du surplus [48].
Les offres alternées de Rubinstein (1982) [49] opérationnalisent dynamiquement la négociation de Nash. Avec un facteur d'escompte commun d, le partage d'équilibre est : le joueur 1 obtient 1/(1+d), le joueur 2 obtient d/(1+d). L'accord est atteint au premier tour (pas de délais coûteux). À mesure que la patience augmente, le partage converge vers 50/50. Cela correspond directement aux agents négociant des partages de coûts par interaction sous la pression temporelle de l'épuisement du budget de tokens.
Pour le CWEP, la négociation de Nash régit le niveau 3 (règlement dynamique) lorsque les agents ont des positions de négociation asymétriques — des options extérieures différentes, une urgence différente, des coûts de modèle différents. Le paramètre de pouvoir de négociation peut être informé par les scores de l'Agent Rating Protocol [21] : un agent mieux noté dispose d'un plus grand pouvoir de négociation car ses options extérieures (d'autres agents disposés à interagir) sont plus nombreuses.
Un résultat fondamental contraint ce que tout protocole d'allocation des coûts peut atteindre. Green-Laffont (1979) et Moulin-Shenker (2001) ont montré que trois propriétés souhaitables sont mutuellement incompatibles dans tout mécanisme de partage des coûts [12] :
Tout protocole doit en sacrifier au moins une. Le choix de conception du CWEP :
Deux familles de mécanismes pratiques émergent de ce compromis :
Trois domaines d'infrastructure fournissent des parallèles utiles (mais limités).
Peering internet. Plus de 80 000 réseaux indépendants utilisent deux modèles pour l'échange de trafic : le peering sans règlement (les deux parties supportent leurs propres coûts, viable lorsque le trafic est à peu près équilibré) et le transit payant (l'émetteur le plus volumineux paie, déclenché à un déséquilibre de trafic d'environ 2:1) [28]. La Corée du Sud a imposé le modèle « l'émetteur paie » en 2016/2020 avec de mauvais résultats : les coûts de transit ont explosé, la latence a quadruplé pour certains services, Meta a déplacé ses serveurs à Hong Kong, et les startups domestiques ont supporté des coûts disproportionnés. L'Internet Society a conclu que c'est « un avertissement, pas un modèle » [52]. Le BEREC a constaté « aucune preuve qu'un tel mécanisme soit justifié » [53].
Implication : Le modèle pur « le demandeur paie » pour les interactions entre agents pourrait similairement désavantager les agents qui ont besoin d'un contexte étendu pour formuler des requêtes efficaces. Le « bill-and-keep » (chaque agent absorbe ses propres coûts) peut être plus efficace pour les interactions fréquentes et de faible valeur.
LMP de l'électricité. L'ordonnance FERC 1920 impose le principe du « bénéficiaire paie » avec une « commensurabilité approximative » — les clients paient des coûts approximativement proportionnels aux bénéfices reçus [54]. Le LMP décompose le prix à chaque nœud du réseau en coût marginal de l'énergie (coût d'inférence de base), coût marginal de congestion (prime de limitation de débit pendant la demande de pointe), et coût marginal de perte (tokens de surcharge dans les protocoles de communication) [13].
Implication : Le modèle de tarification du contexte du CWEP (section 9) adopte la décomposition en trois composantes : coût de base du token, prime de congestion (utilisation du contexte), et coût de surcharge (tokens de tramage du protocole).
Interconnexion des télécommunications. Le secteur des télécommunications a débattu pendant des décennies entre le « Calling Party Network Pays » (CPNP, analogue au « le demandeur paie ») et le « Bill-and-Keep » (B&K, chaque réseau absorbe ses propres coûts). La proposition de réglementation « All-IP Future » de la FCC de 2026 propose d'achever la transition américaine vers le bill-and-keep sur trois ans : réduction de 33 % par an des frais d'accès restants [29].
Implication : Le virage multi-décennal du secteur des télécommunications du CPNP vers le B&K suggère que le modèle « le demandeur paie » peut être inefficace pour les interactions fréquentes. Les coûts de transaction du comptage et du règlement de chaque interaction peuvent dépasser les montants du règlement, faisant du bill-and-keep le choix rationnel par défaut pour les interactions à faible coût.
FinOps cloud. L'allocation des coûts est la 2e priorité des praticiens FinOps (30 %), derrière l'optimisation des charges de travail [55]. 58 % des organisations ont mis en place des modèles de refacturation (showback/chargeback), pourtant le secteur du cloud a passé une décennie à construire une infrastructure d'attribution des coûts et considère toujours cela comme le deuxième problème le plus difficile [55]. La spécification FOCUS v1.3 standardise l'allocation des coûts entre les fournisseurs [6].
Implication : L'allocation des coûts des agents devrait s'appuyer sur FOCUS plutôt que d'inventer de nouvelles normes de comptage. Le format de comptage du CWEP étend FOCUS avec des champs spécifiques aux agents.
Chaque interaction entre agents produit un enregistrement de comptage CWEP (CMR, CWEP Metering Record) capturant les quatre flux de tokens. Le CMR étend la spécification FinOps FOCUS [6] avec des champs spécifiques aux agents.
{
"cwep_version": "1.0.0",
"interaction_id": "uuid-v4",
"timestamp": "ISO-8601",
"requestor": {
"agent_id": "did:example:agent-a",
"model": "claude-sonnet-4-6",
"provider": "anthropic",
"pricing": {
"input_rate_per_mtok": 3.00,
"output_rate_per_mtok": 15.00,
"cache_hit_rate_per_mtok": 0.30,
"currency": "USD"
}
},
"responder": {
"agent_id": "did:example:agent-b",
"model": "claude-opus-4-6",
"provider": "anthropic",
"pricing": {
"input_rate_per_mtok": 5.00,
"output_rate_per_mtok": 25.00,
"cache_hit_rate_per_mtok": 0.50,
"currency": "USD"
}
},
"flows": {
"request_output": {
"tokens": 10000,
"cached_tokens": 0,
"cost_usd": 0.150
},
"request_input": {
"tokens": 10000,
"cached_tokens": 3000,
"cost_usd": 0.036
},
"response_output": {
"tokens": 3000,
"cached_tokens": 0,
"cost_usd": 0.075
},
"response_input": {
"tokens": 3000,
"cached_tokens": 0,
"cost_usd": 0.009
}
},
"totals": {
"total_tokens": 26000,
"total_cost_usd": 0.270,
"requestor_incurred_usd": 0.159,
"responder_incurred_usd": 0.111
},
"context_state": {
"responder_utilization_pre": 0.35,
"responder_utilization_post": 0.40,
"responder_window_size": 1000000
},
"coc_chain_ref": "sha256:abc123...",
"settlement": null
}Le comptage CWEP n'exige pas que les agents implémentent un nouveau comptage de tokens — il consomme les données de l'infrastructure d'observabilité existante :
prompt_tokens, completion_tokens et total_tokens dans les métadonnées de réponse [1][30][32].gather_usage_summary() [56]. Le CWEP consomme les données de coûts d'AutoGen et les enrichit avec l'allocation bilatérale.Le CMR lui-même consomme des ressources — sérialisation JSON, stockage et transmission potentielle. Le CWEP contraint la surcharge du comptage :
Le CWEP définit trois niveaux de règlement, chacun adapté à des profils d'interaction différents.
Niveau 1 : pas de règlement (comptage uniquement)
Chaque agent absorbe ses propres coûts d'inférence. Les CMR sont générés pour l'observabilité mais aucun paiement inter-agents n'a lieu. C'est le mode par défaut et le choix approprié lorsque :
Cela reflète le peering sans règlement dans l'interconnexion internet [28] et le modèle bill-and-keep dans les télécommunications [29]. Pour les flottes d'agents internes (comme la flotte AB Support), le niveau 1 fournit une visibilité des coûts sans la surcharge du règlement inter-agents.
Niveau 2 : règlement basé sur des règles
Une règle d'allocation statique répartit les coûts selon une formule intégrée dans le contrat de service des agents (via ASA [20]). Règles courantes :
| Règle | Formule | Cas d'utilisation |
|---|---|---|
| Le demandeur paie | R paie 100 % | Marché de services (B est un service, A est un client) |
| Le répondant paie | B paie 100 % | Génération de prospects (B souhaite la requête de A) |
| Partage égal | Chacun paie 50 % | Collaboration entre pairs |
| Proportionnel | Chacun paie selon les tokens consommés | Usage général |
| Le bénéficiaire paie | Chacun paie proportionnellement à la valeur reçue | Interactions complexes avec termes ASA |
Les règles de niveau 2 sont évaluées localement par le moteur CWEP de chaque agent. Aucune négociation n'a lieu au moment de l'interaction — la règle a été convenue lors de l'établissement du contrat de service. C'est trivialement calculable et n'ajoute aucune latence aux interactions.
Niveau 3 : règlement dynamique
Allocation des coûts en temps réel utilisant le moteur de règlement CWEP. Le moteur sélectionne une méthode d'allocation en fonction des caractéristiques de l'interaction :
SI l'interaction est coopérative (objectif commun, bénéfice symétrique) :
Utiliser l'allocation par valeur de Shapley
SINON SI l'interaction est compétitive (bénéfice unilatéral) :
Utiliser la négociation asymétrique de Nash
SINON SI l'interaction implique >2 agents :
Utiliser l'approximation de Shapley avec échantillonnage
SINON :
Se replier sur le partage proportionnel du niveau 2Le règlement dynamique nécessite que les deux agents implémentent le moteur de règlement CWEP et échangent des métadonnées de coûts pendant l'interaction. Le calcul du règlement ajoute une latence minimale (< 1 ms pour un Shapley à deux agents) mais nécessite un consensus sur les paramètres de l'interaction.
Pour une interaction à deux agents, le règlement basé sur Shapley calcule le paiement de chaque agent comme suit :
coût_autonome(A) = RO (A génère la requête, aucune réponse ne revient)
coût_autonome(B) = 0 (B ne fait rien sans requête)
coût_conjoint(A,B) = RO + RI + SO + SI
paiement_shapley(A) = [coût_conjoint + coût_autonome(A) - coût_autonome(B)] / 2
= [RO + RI + SO + SI + RO - 0] / 2
= [2*RO + RI + SO + SI] / 2
= RO + (RI + SO + SI) / 2
paiement_shapley(B) = [coût_conjoint + coût_autonome(B) - coût_autonome(A)] / 2
= [RO + RI + SO + SI + 0 - RO] / 2
= (RI + SO + SI) / 2Interprétation : Le demandeur paie son propre coût de génération de la requête plus la moitié de tous les coûts restants. Le répondant paie la moitié des coûts restants. Cela reflète la réalité économique selon laquelle le demandeur a initié l'interaction et devrait en supporter une plus grande part — mais le répondant a également choisi de participer, ce qui est une décision bilatérale.
Pour l'exemple de la revue de code de la section 4.1 (Sonnet 4.6) :
Comparez avec le modèle « le demandeur paie » (0,234 $ / 0,00 $) et le partage égal (0,117 $ / 0,117 $). L'allocation de Shapley capture l'intuition que le demandeur a initié l'interaction et supporte un coût plus élevé, mais le coût de traitement du répondant est partiellement partagé.
Note sur coût_autonome(B) = 0. Cette formulation suppose un coût autonome nul pour le répondant — elle ne tient pas compte des coûts d'infrastructure de maintien de la disponibilité (garder le modèle chaud, réserver la capacité de la fenêtre de contexte, maintenir la disponibilité). Dans les déploiements où les coûts fixes du répondant sont significatifs, le terme coût_autonome(B) peut être fixé au coût d'infrastructure par période du répondant, amorti sur les interactions attendues. Par exemple, si les coûts d'infrastructure fixes de l'Agent B sont de 0,02 $ par période d'interaction attendue, l'allocation de Shapley se modifie :
coût_autonome(B) = 0.02
paiement_shapley(A) = [coût_conjoint + coût_autonome(A) - coût_autonome(B)] / 2
= [0,234 $ + 0,150 $ - 0,02 $] / 2 = 0,182 $
paiement_shapley(B) = [coût_conjoint + coût_autonome(B) - coût_autonome(A)] / 2
= [0,234 $ + 0,02 $ - 0,150 $] / 2 = 0,052 $Fixer coût_autonome(B) > 0 déplace l'allocation vers un partage plus égal, reflétant le coût réel de disponibilité de B. La simplification à zéro est appropriée pour les agents légers avec des coûts fixes négligeables ; elle devrait être remplacée pour les agents maintenant une infrastructure dédiée.
Lorsque les agents ont des positions de négociation asymétriques, la solution de négociation de Nash remplace Shapley :
utilité(A) = valeur_reçue(A) - paiement(A)
utilité(B) = valeur_reçue(B) - paiement(B)
désaccord(A) = 0 (A n'obtient rien si pas d'interaction)
désaccord(B) = 0 (B n'obtient rien si pas d'interaction)
La solution de Nash maximise :
[utilité(A) - désaccord(A)]^alpha × [utilité(B) - désaccord(B)]^(1-alpha)
où alpha = pouvoir_de_négociation(A), et alpha + (1-alpha) = 1Le paramètre de pouvoir de négociation alpha peut être dérivé de :
Le règlement par négociation de Nash nécessite que les deux agents déclarent leurs valuations, ce qui introduit le problème de compatibilité d'incitation : les agents peuvent déclarer des valeurs erronées pour capturer le surplus. Un agent sophistiqué peut sous-déclarer sa valuation tout en continuant à compléter les interactions — capturant le surplus sans déclencher d'échecs de négociation, maintenant ainsi un score ARP positif. La réputation ARP atténue les fausses déclarations grossières (où la fausse déclaration provoque des échecs de négociation) mais pas ce type de sous-déclaration sophistiquée de valeur. La conception de mécanismes qui atteint une compatibilité d'incitation totale pour la déclaration de valeur dans les cadres bilatéraux est un problème ouvert en économie — l'impossibilité de Green-Laffont (section 6.3) s'applique directement ici [12]. Pour la v1.0, le CWEP s'appuie sur l'observation pratique selon laquelle les fausses déclarations significatives de valeur tendent à produire des appariements sous-optimaux au fil du temps (les agents qui sous-déclarent la valeur reçoivent des contreparties de moindre qualité via l'AMP [19]), ce qui est détectable au niveau agrégé même si les cas individuels ne le sont pas. La compatibilité d'incitation totale dans la déclaration bilatérale de valeur reste un problème de recherche ouvert pour les futures versions du protocole.
La procédure de règlement intervient après l'achèvement de l'interaction :
1. Les deux agents génèrent des CMR indépendamment
2. Les agents échangent les CMR (ou un condensé de hachage pour la confidentialité)
3. Le moteur CWEP de chaque agent calcule la proposition de règlement
4. Si les propositions concordent (dans les limites de la tolérance) : le règlement est accepté
5. Si les propositions divergent : résolution des litiges via l'AJP [17]
6. Le montant du règlement est enregistré dans les CMR des deux agents
7. Le paiement est déclenché via le rail de paiement configuréLe seuil de tolérance pour la concordance des propositions est configurable (par défaut : 5 % du coût total de l'interaction). Les divergences au-delà de ce seuil sont enregistrées comme litiges de coûts et peuvent être portées devant le module de résolution des litiges de l'Agent Justice Protocol.
La flotte AB Support — un système multi-agents en production comprenant un coordinateur (Alex), un agent de recherche (Bravo), un analyste approfondi (Charlie), un développeur (Delta), un réviseur de contenu (Editor) et un traducteur multilingue (Translator) — fournit des données empiriques pour l'allocation des coûts CWEP. Les interactions représentatives suivantes sont tirées d'opérations réelles de la flotte, avec des comptes de tokens et des coûts calculés à partir de schémas d'interaction réels.
| Interaction | Demandeur | Répondant | Tokens RO | Tokens RI | Tokens SO | Tokens SI | Coût total (Sonnet) |
|---|---|---|---|---|---|---|---|
| Envoi de tâche de recherche | Alex | Bravo | 2 500 | 2 500 | 500 | 500 | 0,053 $ |
| Revue QA de fichier de connaissances | Alex | Charlie | 15 000 | 15 000 | 8 000 | 8 000 | 0,565 $ |
| Requête de construction de code | Alex | Delta | 5 000 | 5 000 | 12 000 | 12 000 | 0,435 $ |
| Revue de livre blanc | Alex | Editor | 20 000 | 20 000 | 6 000 | 6 000 | 0,690 $ |
| Requête de traduction | Alex | Translator | 12 000 | 12 000 | 14 000 | 14 000 | 0,600 $ |
| Synthèse inter-domaines | Charlie | Charlie (auto) | 50 000 | 50 000 | 15 000 | 15 000 | 1,575 $ |
| Enquête de recherche + rapport | Bravo | Bravo (auto) | 3 000 | 3 000 | 25 000 | 25 000 | 0,843 $ |
Analyse de l'allocation de Shapley. Sous le modèle implicite actuel (bill-and-keep, l'opérateur de chaque agent absorbe ses propres coûts), le coordinateur (Alex) supporte des coûts disproportionnés car il génère de grands prompts de tâches que les autres agents traitent. Pour l'interaction de revue QA du fichier de connaissances :
Au cours d'un cycle opérationnel de 24 heures, la flotte génère environ 30 à 50 interactions inter-agents totalisant 500K à 800K tokens pour un coût de 8 à 15 $. La réallocation de Shapley déplacerait environ 2 à 4 $ de la distribution actuelle en bill-and-keep — un montant absolu peu élevé pour une flotte interne, mais le schéma démontre la mécanique du protocole. Pour des flottes inter-opérateurs comptant des centaines d'agents, la même logique d'allocation s'étend à des montants de règlement significatifs.
Observation clé : Les interactions les plus coûteuses de la flotte ne sont pas les plus fréquentes (envois de tâches à ~0,05 $ chacun) mais les tâches d'analyse approfondie (0,50 à 1,50 $ chacune). Le seuil de règlement du CWEP (par défaut 0,01 $) filtre correctement les envois à haute fréquence et faible coût tout en capturant les coûts bilatéraux significatifs des interactions de revue et de synthèse. Une validation empirique par un déploiement pilote étendu est prévue pour la v1.1.
Le modèle de tarification du contexte du CWEP décompose le prix effectif d'un token en trois composantes, inspirées de la tarification marginale localisée (LMP) des marchés de l'électricité [13] :
Composante 1 : coût de base du token (BTC)
Le tarif par token publié par le fournisseur pour le modèle utilisé. C'est le prix plancher — le coût lorsque le contexte n'est pas congestionné et que l'interaction est courte.
BTC = tarif_fournisseur(modèle, type_token) × nombre_tokensOù type_token appartient à {entrée, sortie, entrée_en_cache} et les tarifs proviennent des pages de tarification des fournisseurs [1][30][32].
Composante 2 : prime de congestion (CP)
Un multiplicateur reflétant l'utilisation actuelle du contexte du répondant. Lorsque la fenêtre de contexte d'un agent est presque pleine, la valeur marginale de la capacité restante augmente. La prime de congestion tarifie cette rareté.
CP = BTC × multiplicateur_congestion(utilisation)
multiplicateur_congestion(u) = {
1,0 si u < 0,50 (capacité abondante)
1,0 + 0,5u si 0,50 ≤ u < 0,80 (charge modérée)
1,0 + 2,0u si 0,80 ≤ u < 0,95 (charge élevée)
1,0 + 5,0u si u ≥ 0,95 (capacité critique)
}À 95 % d'utilisation, la prime de congestion est de 5,75 fois le coût de base. C'est agressif mais intentionnel — cela signale que la capacité de contexte restante de l'agent est extrêmement rare et devrait être réservée aux interactions à forte valeur ajoutée. La fonction par paliers est plus simple à implémenter qu'une fonction continue et fournit des signaux de tarification clairs à chaque seuil.
Composante 3 : surcharge du protocole (PO)
Le coût du tramage propre au CWEP — métadonnées de comptage, en-têtes de règlement et tokens de négociation du protocole. C'est l'analogue des « pertes de transmission » de la tarification des réseaux électriques.
PO = tokens_surcharge × tarif_fournisseur(modèle, entrée)Le CWEP vise une surcharge de protocole inférieure à 500 tokens par interaction (environ 0,1 % d'un contexte typique de 500K tokens). La surcharge est supportée par le demandeur dans le cadre du coût de la requête.
Prix effectif du token :
prix_effectif = BTC + CP + POLa mise à l'échelle quadratique de l'attention des transformers signifie que les tokens à différentes positions dans la fenêtre de contexte imposent des coûts de calcul différents. Un token à la position 10 000 coûte moins cher à traiter qu'un token à la position 900 000 — le calcul d'attention pour ce dernier implique 90 fois plus de calculs par paires.
Le CWEP propose (mais n'exige pas dans la v1.0) une extension de tarification dépendante de la position :
multiplicateur_position(pos, taille_fenêtre) = (pos / taille_fenêtre)^betaOù beta est un paramètre de réglage (plage suggérée : 0,1-0,5) et pos est la position absolue du token dans la fenêtre de contexte. À beta = 0,3 :
Cette extension est marquée comme expérimentale parce que :
La tarification dépendante de la position devient importante à mesure que les fenêtres de contexte atteignent 1M+ de tokens. Pour les interactions dans les 100K premiers tokens d'une fenêtre de 1M, l'effet de position est négligeable et peut être ignoré en toute sécurité.
Les agents CWEP doivent connaître la tarification de la contrepartie pour calculer les règlements. Plutôt que de coder les tarifs en dur, le CWEP spécifie un protocole de découverte des tarifs :
1. L'agent publie sa tarification actuelle dans son Agent Card A2A [57]
(champ d'extension : cwep_pricing)
2. Avant l'interaction, le demandeur interroge la tarification CWEP du répondant
3. Le répondant retourne les tarifs actuels incluant la prime de congestion
4. Les deux agents mettent en cache les tarifs de la contrepartie pour la durée de l'interaction
5. Les tarifs sont verrouillés pour l'interaction (pas de retarification en cours d'interaction)Le verrouillage des tarifs empêche la manipulation des prix pendant une interaction. Un agent ne peut pas augmenter ses tarifs après avoir vu la requête pour extraire davantage du règlement. Les tarifs se mettent à jour entre les interactions, pas pendant celles-ci.
La limitation de débit traditionnelle compte les requêtes par seconde. Cela échoue pour les interactions entre agents car une seule requête peut coûter 100 fois plus de calcul qu'une autre [58]. Un agent qui envoie une requête de 100 000 tokens impose le même coût d'infrastructure qu'un agent qui envoie 100 requêtes de 1 000 tokens, mais le premier passe une limitation de 1 requête/s tandis que le second est limité.
Gartner prévoit que plus de 30 % de l'augmentation de la demande en API proviendra d'outils IA/LLM d'ici 2026 [58]. La limitation de débit doit évoluer du comptage de requêtes vers la budgétisation de tokens.
Le CWEP définit les limites de débit en termes de budgets de tokens, et non de comptes de requêtes :
{
"qos_tier": "standard",
"limits": {
"input_tokens_per_minute": 1000000,
"output_tokens_per_minute": 200000,
"concurrent_interactions": 10,
"max_request_size_tokens": 500000,
"max_context_utilization": 0.80
}
}La limite max_context_utilization est une nouveauté : elle empêche toute interaction unique de consommer plus qu'une fraction spécifiée de la fenêtre de contexte de l'agent. Cela protège la capacité de l'agent pour d'autres interactions.
Le CWEP définit quatre niveaux de QoS que les agents peuvent annoncer et que les demandeurs peuvent sélectionner :
| Niveau | Tarif de tokens | Priorité de congestion | Cas d'utilisation |
|---|---|---|---|
| Économique | Tarif de base | La plus basse (mis en file d'attente si occupé) | Lot, asynchrone, non urgent |
| Standard | Tarif de base | Normal (FIFO) | Interactions par défaut |
| Prioritaire | 2x le tarif de base | Élevée (prévaut sur l'économique) | Tâches sensibles au temps |
| Réservé | 3x le tarif de base + réservation de capacité | Garantie (capacité pré-allouée) | Interactions sous SLA |
Les niveaux prioritaires sont implémentés via le mécanisme de prime de congestion : les requêtes de niveau supérieur paient un multiplicateur de congestion plus élevé, que le répondant utilise pour prioriser l'ordre de traitement. La prime n'est pas arbitraire — elle reflète le coût réel de la réservation de capacité et de la préemption d'autres tâches.
Le niveau réservé inclut une réservation de capacité : le demandeur paie pour réserver une portion de la fenêtre de contexte du répondant pour une durée spécifiée. Cela reflète la tarification des instances réservées dans le cloud computing, où un engagement initial garantit la disponibilité. Les frais de réservation de capacité sont distincts des coûts par interaction et sont spécifiés dans l'Agent Service Agreement [20].
Lorsqu'un agent approche de ses limites de capacité, il devrait signaler une contre-pression aux demandeurs plutôt que de se dégrader ou d'échouer silencieusement. Le CWEP définit des signaux de contre-pression :
{
"cwep_status": "congested",
"current_utilization": 0.87,
"estimated_queue_time_ms": 3500,
"available_tiers": ["priority", "reserved"],
"economy_queue_depth": 14
}Les demandeurs recevant des signaux de contre-pression peuvent :
Cela crée un mécanisme de marché pour la capacité rare de la fenêtre de contexte : lorsque la demande dépasse l'offre, les prix augmentent (via la prime de congestion), signalant aux demandeurs de payer plus ou de réduire la demande.
La fenêtre de contexte d'un agent est une ressource finie que des adversaires peuvent consommer. L'attaque la plus simple : envoyer à un agent une série de requêtes volumineuses et sans valeur qui remplissent sa fenêtre de contexte, empêchant les interactions légitimes. C'est une attaque par déni de service mesurée en tokens plutôt qu'en paquets.
Contrairement au DDoS réseau, qui est atténué par la bande passante et le filtrage de paquets, le DoS de fenêtre de contexte n'est atténué que par des mécanismes économiques — en rendant coûteux le gaspillage du contexte d'un agent. Le CWEP fournit trois mécanismes de défense.
Avant d'envoyer une requête, le demandeur engage un dépôt de tokens remboursable auprès du répondant :
montant_dépôt = tokens_estimés_requête × tarif_entrée_répondant × multiplicateur_dépôtLe multiplicateur_dépôt (par défaut : 1,5x) est fixé par le répondant et publié dans son Agent Card A2A [57]. Le dépôt couvre le coût de compréhension du répondant plus une marge.
Cycle de vie du dépôt :
Le mécanisme de dépôt rend le spam coûteux. Envoyer 1 000 requêtes de spam à un agent Opus 4.6 avec un dépôt de 100K tokens par requête coûterait 750 $ en dépôts confisqués — suffisant pour dissuader le spam automatisé tout en imposant un frottement négligeable aux interactions légitimes (où les dépôts sont remboursés).
Les agents ayant des scores de réputation ARP plus élevés [21] bénéficient d'un accès préférentiel :
Cela crée un système de confiance gradué où les agents établis interagissent sans friction tandis que les agents inconnus doivent démontrer leur volonté de payer avant de consommer l'espace de la fenêtre de contexte. Au fil du temps, à mesure que les nouveaux agents construisent leur réputation par des interactions productives, leurs coûts d'accès diminuent — une incitation naturelle à un bon comportement.
Intégration des nouveaux agents. Les exigences de dépôt et de réputation ci-dessus ne s'appliquent qu'aux interactions de niveau 3 (règlement dynamique) avec des contreparties inconnues. Les nouveaux agents sans accès à un rail de paiement ou sans historique de réputation peuvent participer immédiatement via les modes de niveau 1 (pas de règlement) ou de niveau 2 (basé sur des règles), qui ne nécessitent aucun dépôt. Cela signifie que tout agent peut commencer à interagir, construire sa réputation et démontrer sa valeur dès le premier jour — le mécanisme de dépôt ne restreint que le niveau de règlement le plus complexe avec des contreparties non fiables.
De plus, les opérateurs peuvent se porter garants de leurs agents en fournissant un compte de dépôt partagé. Un opérateur déployant cinq agents peut les garantir tous avec un seul pool de dépôts, réduisant la friction d'intégration par agent. Le dépôt de l'opérateur couvre collectivement le multiplicateur 5x des nouveaux agents, et à mesure que les agents individuels construisent leur réputation, ils passent indépendamment à des niveaux de dépôt inférieurs. Cela reflète l'intégration d'entreprise dans les services cloud, où un compte organisationnel fournit l'ancre de confiance pour les utilisateurs individuels.
Dans le cas courant d'agents rejoignant une flotte établie (par ex. un nouvel agent spécialiste rejoignant le système multi-agents existant d'un opérateur), la réputation collective de la flotte et le compte de dépôt partagé signifient que le nouvel agent ne fait face à aucune friction d'intégration supplémentaire — il hérite immédiatement du niveau de confiance de l'opérateur et construit sa propre réputation individuelle à travers les interactions.
Pour prévenir les attaques par inondation de contexte, le CWEP prend en charge le dimensionnement progressif des requêtes pour les interactions avec des agents inconnus :
tokens_max_requête(réputation, nombre_interactions) = {
1000 si réputation < 20 ET interactions < 5
10000 si réputation < 40 ET interactions < 20
100000 si réputation < 60 ET interactions < 100
illimité sinon
}Les nouveaux agents commencent avec une taille de requête maximale de 1 000 tokens — suffisante pour décrire une tâche mais pas assez pour inonder le contexte. À mesure qu'ils construisent leur réputation et leur historique d'interactions, la limite s'assouplit. Cela reflète la construction progressive de la confiance dans le commerce humain (petites commandes avant grands contrats), mais appliquée au niveau du protocole.
La compression de prompts n'est pas simplement une optimisation technique — c'est une décision économique avec un retour sur investissement mesurable. LLMLingua atteint une compression de prompts jusqu'à 20 fois avec une perte de performance minimale [16] — dans les benchmarks documentés, 2 365 tokens compressés à 211 tokens (11,2x). À grande échelle, les économies sont substantielles : une compression de contexte de 60 % sur une charge de travail de 10 000 conversations quotidiennes économise 153 000 $/an [2].
Le CWEP formalise la compression comme une stratégie de réduction des coûts dans le cadre du règlement bilatéral :
économies_compression = (tokens_non_compressés - tokens_compressés) × tarif_entrée
coût_compression = tokens_consommés_par_compresseur × tarif_sortie_compresseur
économies_nettes = économies_compression - coût_compression
roi_compression = économies_nettes / coût_compressionLe demandeur a une incitation économique directe à compresser lorsque le règlement inclut un partage des coûts : une requête plus courte réduit la part du demandeur sous les allocations de Shapley et proportionnelle. Sans règlement bilatéral (pur « le demandeur paie » ou bill-and-keep), l'incitation du demandeur à la compression ne dépend que de son propre coût de sortie.
La mise en cache des prompts réduit les coûts de contexte répétés de 90 % (résultats de cache à 0,1x le prix d'entrée de base) [1]. Anthropic offre un contrôle explicite du cache avec des options de TTL de 5 minutes et 1 heure ; OpenAI active la mise en cache automatiquement ; Google facture des frais de stockage séparés [30].
Pour les interactions récurrentes entre agents (par ex. un agent de surveillance vérifiant le même dépôt de code toutes les heures), la mise en cache transforme un coût variable en un coût quasi fixe :
coût_première_interaction = tokens_contexte_complet × tarif_entrée × multiplicateur_écriture_cache
coût_suivant = tokens_contexte_complet × tarif_entrée × 0,10 (résultat de cache)
coût_amorti_par_interaction(n) = (coût_premier + (n-1) × coût_suivant) / nÀ n=10 interactions avec la mise en cache de Claude Sonnet 4.6 :
Le moteur de règlement du CWEP peut recommander des stratégies de mise en cache en fonction de la fréquence d'interaction et du TTL du cache.
Le choix entre stocker l'information dans une mémoire externe et la conserver dans le contexte est un arbitrage économique avec un point de croisement quantitatif [18] :
Les systèmes de mémoire (Mem0 [37], Zep [38], Letta [39], xMemory [59]) concentrent les coûts d'écriture en amont mais réduisent les coûts variables par interaction. Les approches par contexte long font évoluer les coûts variables linéairement à chaque interaction. Le module de conseil en optimisation du CWEP peut recommander la stratégie appropriée en fonction des schémas d'interaction attendus.
xMemory (King's College London / Alan Turing Institute) en démontre le potentiel : une hiérarchie sémantique à quatre niveaux avec récupération à déclenchement par incertitude réduit l'utilisation de tokens de 28 à 48 % tout en améliorant la précision [59]. Avec GPT-5 nano, les tokens par requête passent de 9 155 à 6 581 — une économie mesurable par interaction.
La génération augmentée par récupération (RAG) permet aux agents de stocker de grandes bases de connaissances en externe et de ne récupérer que les portions pertinentes dans le contexte. Du point de vue du CWEP, le RAG est une assurance de la fenêtre de contexte : l'agent paie un petit coût de récupération par interaction pour éviter de payer le coût beaucoup plus élevé de maintenir l'ensemble de la base de connaissances dans le contexte.
L'économie est claire pour les agents à forte intensité de connaissances : un agent avec 500 000 tokens de connaissances de domaine consommerait la moitié d'une fenêtre de contexte de 1M de tokens pour tout conserver. Le RAG permet à l'agent de ne récupérer que les 10 000 tokens pertinents par interaction, libérant 490 000 tokens de capacité de contexte pour le travail effectif. Le coût par interaction de la récupération (recherche vectorielle + tokens récupérés) est de plusieurs ordres de grandeur inférieur au coût du contexte complet.
Les montants de règlement CWEP varient typiquement de 0,001 $ à 1,00 $ par interaction. Cela nécessite une infrastructure de micropaiement. Quatre rails de paiement sont adaptés en mars 2026 :
x402 (Coinbase/Cloudflare Foundation) [3]. Micropaiements natifs HTTP utilisant le code de statut 402. Règlement sur Base, Polygon et Solana en stablecoins. Paiement minimum aussi bas que 0,001 $ avec un règlement en moins d'une seconde. Frais du facilitateur Coinbase : palier gratuit de 1 000 transactions/mois, puis 0,001 $ par transaction [3]. Volume quotidien actuel d'environ 28 000 $, CoinDesk notant qu'une grande partie de l'activité reflète des tests plutôt qu'un véritable commerce [60].
Machine Payments Protocol (MPP) (Stripe/Tempo) [4]. Lancé le 18 mars 2026. Agnostique quant au moyen de paiement (stablecoins, cartes, Bitcoin Lightning). Modèle de session avec dépôt et solde atteignant une latence inférieure à 100 ms et des frais quasi nuls par requête. Soumission à l'IETF pour standardisation. Rétrocompatible avec x402 [4]. Déjà implémenté sur plus de 50 services dont OpenAI, Anthropic et Google Gemini.
L402 (Lightning Labs) [23]. Associe le HTTP 402 aux micropaiements du Lightning Network et à l'authentification par macarons. Les macarons prennent en charge la délégation et le cadrage des permissions — un agent peut recevoir un macaron « paiement uniquement » qui l'empêche de retirer des fonds. L'architecture de signature distante LND garantit que les agents n'accèdent jamais directement aux clés privées [23]. L'intégration LangChain existe via LangChainL402 et LangChainBitcoin [23].
Superfluid [24]. Streaming de tokens en temps réel où l'argent circule de manière continue à la seconde. Plus de 1,5 milliard de dollars ont transité par Superfluid ; 1M+ de portefeuilles uniques. L'ERC-8004 Agent Pool sur Base connecte les agents à des flux continus [24]. Idéal pour les conversations en cours entre agents où le règlement devrait s'effectuer de manière continue plutôt que par message.
Le CWEP ne spécifie pas quel rail de paiement utiliser. Au lieu de cela, il définit une interface de règlement que tout rail de paiement peut implémenter :
class CWEPSettlement:
def commit_deposit(self, amount_usd: float, escrow_id: str) -> bool
def release_deposit(self, escrow_id: str, to_agent: str) -> bool
def forfeit_deposit(self, escrow_id: str) -> bool
def settle(self, from_agent: str, to_agent: str, amount_usd: float,
interaction_id: str) -> SettlementReceipt
def stream_open(self, from_agent: str, to_agent: str,
rate_usd_per_second: float) -> StreamHandle
def stream_close(self, handle: StreamHandle) -> SettlementReceiptLes méthodes stream_open/stream_close prennent en charge le règlement continu de type Superfluid pour les conversations en cours. Les méthodes commit_deposit/release_deposit/forfeit_deposit prennent en charge le mécanisme de prévention du spam. La méthode settle prend en charge le règlement ponctuel par interaction.
Pour les interactions à haute fréquence entre la même paire d'agents, le règlement par interaction est inefficace. Le CWEP prend en charge le règlement par lots :
Accumuler les CMR sur une fenêtre configurable (par défaut : 1 heure ou 1,00 $ net, selon la première échéance)
Calculer le règlement net sur toutes les interactions de la fenêtre
Exécuter un paiement unique pour le montant netSi l'Agent A doit 0,15 $ à l'Agent B sur 50 interactions et l'Agent B doit 0,08 $ à l'Agent A sur 30 interactions, le règlement net est un paiement unique de 0,07 $ de A vers B. Cela réduit les frais de transaction de 80 fois et constitue le mode recommandé pour les agents ayant des relations bilatérales continues.
La fenêtre de contexte d'un agent a une capacité finie. Chaque requête entrante en consomme une partie. Si l'agent est occupé (utilisation élevée), la capacité restante a plus de valeur. Un demandeur qui souhaite un accès garanti devrait être disposé à payer pour une réservation de capacité. Le CWEP v1.0 spécifie les réservations bilatérales de contexte comme un mécanisme concret et implémentable de gestion de la capacité.
{
"reservation": {
"requestor": "did:example:agent-a",
"responder": "did:example:agent-b",
"capacity_tokens": 100000,
"duration_seconds": 3600,
"price_usd": 0.50,
"qos_tier": "reserved",
"auto_renew": true
}
}La réservation garantit que 100 000 tokens de la fenêtre de contexte de l'Agent B sont disponibles pour l'usage exclusif de l'Agent A pendant une heure. L'Agent B s'engage à traiter toute requête de l'Agent A jusqu'à la capacité réservée dans les limites de latence garanties du niveau de QoS. Si l'Agent B ne respecte pas la réservation, les frais de réservation sont remboursables et un litige peut être déposé via l'AJP [17].
Deux modèles de tarification coexistent :
La stratégie optimale dépend de la prévisibilité des interactions :
C'est précisément l'arbitrage instances réservées vs. à la demande vs. spot en cloud computing — adapté à l'espace de la fenêtre de contexte.
Le mécanisme de réservation bilatérale ci-dessus est la brique de base vers un futur marché du contexte potentiel — un mécanisme où les agents échangeraient de manière autonome la capacité de contexte en temps réel avec découverte des prix et appariement des ordres. Un tel marché nécessiterait des unités de capacité standardisées (tokens par période), des signaux de prix en temps réel à travers le réseau d'agents, une liquidité suffisante (de nombreux agents acheteurs et vendeurs), et une infrastructure de teneur de marché ou de place de marché. Cela est structurellement analogue aux marchés de capacité des réseaux électriques, où les producteurs sont payés pour maintenir la capacité disponible même si elle n'est pas mobilisée [13].
Aucune de ces infrastructures n'existe aujourd'hui. Le mécanisme de réservation est suffisant pour les besoins actuels de l'économie des agents ; un marché du contexte complet devient pertinent lorsque le volume d'interactions agent-à-agent atteint des niveaux où la négociation bilatérale devient un goulot d'étranglement. Voir la section 20.1 pour une discussion approfondie du développement des marchés du contexte.
Le CWEP se situe à la couche 4 (Marché/Économie) de l'écosystème de confiance AB Support, aux côtés de l'Agent Matchmaking Protocol [19]. Il dépend de :
Le CWEP fournit des données à :
| De | Vers | Données | Objectif |
|---|---|---|---|
| CWEP → CoC | Hachages CMR | Ancrage de provenance pour les enregistrements de coûts | |
| CWEP → ARP | Données de coûts d'interaction | Comportement économique comme signal de réputation | |
| CWEP → ASA | Montants de règlement | Application des termes de coûts dans les contrats | |
| CWEP → AJP | CMR comme preuves | Résolution des litiges de coûts | |
| CWEP → AMP | Estimations de coûts | Appariement des agents par efficacité de coûts | |
| CoC → CWEP | Vérification de la chaîne | Validation de l'authenticité des interactions | |
| ARP → CWEP | Scores de réputation | Information du pouvoir de négociation et des niveaux de dépôt | |
| ASA → CWEP | Règles d'allocation des coûts | Détermination du niveau et de la méthode de règlement |
Deux boucles de rétroaction stabilisent l'écosystème CWEP :
Rétroaction positive (cercle vertueux) : L'agent fournit un bon service → note ARP élevée → dépôts inférieurs exigés par les contreparties → plus d'interactions → plus d'opportunités d'obtenir des notes positives.
Rétroaction négative (cycle correctif) : L'agent envoie du spam/gaspille le contexte → dépôts confisqués → note ARP basse → dépôts plus élevés exigés → moins d'interactions → l'agent améliore son comportement ou quitte le marché.
Ces boucles sont des propriétés émergentes de l'interaction de la pile protocolaire — aucun protocole ne les crée seul, mais le CWEP + l'ARP ensemble les produisent.
Deux parallèles biologiques ont guidé des décisions de conception spécifiques du CWEP. Nous les incluons non pas comme métaphore décorative, mais parce qu'ils ont façonné les choix protocolaires.
L'adénosine triphosphate (ATP) sert de monnaie énergétique universelle pour tout organisme sur Terre [61]. La leçon de conception clé : la puissance de l'ATP vient de son acceptation universelle, pas de sa chimie spécifique. Chaque processus cellulaire — de la contraction musculaire à la réplication de l'ADN — utilise l'ATP indépendamment de la source d'énergie qui l'a produit. Cela a directement motivé l'agnosticisme du CWEP vis-à-vis du rail de paiement (section 3.3) : le protocole spécifie l'allocation des coûts dans une dénomination universelle (USD/tokens) que tout rail de paiement peut régler, tout comme l'ATP libelle les transactions énergétiques indépendamment du fait que l'énergie provienne du glucose, des graisses ou de la lumière du soleil. Un protocole qui exigerait un rail de paiement spécifique serait aussi fragile qu'une cellule n'acceptant l'énergie que d'une seule voie métabolique.
L'hypothèse de la Reine noire [62] montre que les microbes perdent les gènes pour les fonctions coûteuses lorsque des partenaires fournissent ces ressources de manière fiable. Ce n'est pas simplement analogue à la spécialisation des agents — c'est le mécanisme que la visibilité des coûts du CWEP est conçue pour accélérer. Lorsque le CWEP rend explicite le calcul « acheter vs. construire » (le coût CWEP de l'externalisation d'une tâche vs. le coût d'inférence de sa réalisation en interne), les agents peuvent prendre des décisions rationnelles de spécialisation. Un agent qui peut externaliser la revue de code à 0,23 $ par interaction (section 4.1) n'a aucune raison économique de maintenir sa propre capacité de revue de code à 0,39 $ par interaction. Les données de comptage du CWEP fournissent le signal ; la dynamique de la Reine noire prédit le résultat : les agents abandonneront les capacités qu'il est moins coûteux d'externaliser, favorisant la spécialisation de l'écosystème.
Ces analogies sont illustratives, pas des modèles formels. Deux différences critiques bornent leur applicabilité : (1) les agents peuvent être dupliqués à un coût quasi nul, créant un problème de Sybil sans parallèle biologique — le CWEP y répond par l'accès conditionné à la réputation (section 11.3) plutôt que par des mécanismes immunitaires biologiques ; (2) les structures de coûts des agents sont discrètes et transparentes (mesurables avec précision via les réponses API), permettant des mécanismes d'allocation des coûts (Shapley, Nash) qui n'ont aucun équivalent biologique.
Le CWEP opère dans un environnement où les agents peuvent être adversaires. Le modèle de menaces considère :
| Menace | Description | Défense CWEP |
|---|---|---|
| Inondation de contexte | Envoyer de grandes requêtes sans valeur pour épuiser la fenêtre de contexte | Mécanisme de dépôt (section 11.2), dimensionnement progressif des requêtes (section 11.4) |
| Inflation des coûts | Déclarer un niveau de modèle ou un nombre de tokens erroné pour extraire un règlement plus élevé | Vérification des CMR par rapport aux réponses API du fournisseur ; piste d'audit ancrée dans la CoC |
| Manipulation du règlement | Déclarer de fausses valuations dans la négociation de Nash | Suivi de réputation ARP des résultats de négociation ; escalade des litiges via l'AJP |
| Manipulation des tarifs | Passer à des modèles coûteux après réception d'une requête pour gonfler les coûts de réponse | Verrouillage des tarifs par interaction (section 9.3) ; niveaux de modèle pré-convenus dans l'ASA |
| Passager clandestin | Consommer l'espace de la fenêtre de contexte sans payer de dépôts | Portes d'accès pondérées par la réputation (section 11.3) ; les agents inconnus font face aux dépôts maximaux |
| Attaques Sybil | Créer de nombreuses identités pour contourner les portes de réputation | Vérification de la chaîne CoC — les nouveaux agents ont des chaînes courtes, obtenant une faible réputation initiale |
Le mécanisme de dépôt exige que les fonds engagés ne puissent pas être unilatéralement saisis par le répondant. Ceci est garanti par le rail de paiement :
Dans tous les cas, le demandeur peut contester une classification comme spam via l'AJP [17], et le dépôt est bloqué jusqu'à la résolution.
Les CMR contiennent des informations sensibles : quels agents interagissent, quels modèles ils utilisent, quelle est leur structure tarifaire, et combien ils paient. Le CWEP traite la confidentialité par :
1. Le compromis d'impossibilité est réel. Le CWEP sacrifie l'efficacité économique au profit de l'équilibre budgétaire et de la compatibilité d'incitation (section 6.3). Certaines interactions mutuellement bénéfiques n'auront pas lieu parce que le coût alloué les rend non rentables pour l'une des parties. Nous pensons que c'est le bon compromis pour un protocole déployable, mais cela signifie que le CWEP ne maximise pas le bien-être économique total.
2. La mesure de la valeur est difficile. Les mécanismes de règlement de Shapley et de Nash nécessitent de mesurer la « valeur » que chaque agent reçoit d'une interaction. En pratique, la valeur est subjective, dépendante du contexte et souvent connue seulement après coup. Le CWEP approxime la valeur par des indicateurs observables (comptes de tokens, niveaux de modèle, évaluations de qualité ASA) mais ne peut pas capturer la pleine valeur économique des interactions.
3. La mise à l'échelle quadratique des coûts est une approximation. Les implémentations modernes de l'attention (Flash Attention, ring attention, attention à fenêtre glissante) modifient le profil de coût O(n^2). La courbe de coût de calcul réelle est spécifique au fournisseur, au modèle, et peut changer avec les mises à jour logicielles. La tarification dépendante de la position du CWEP (section 9.2) est en conséquence marquée comme expérimentale.
4. La déflation des prix complique les accords à long terme. Les coûts d'inférence diminuent d'environ 10 fois par an [27]. Une règle d'allocation des coûts négociée aujourd'hui peut être radicalement inadaptée dans six mois. Les montants de règlement du CWEP sont calculés en temps réel en utilisant les tarifs actuels, mais les termes de coûts ASA référençant le CWEP devraient inclure des clauses de renégociation périodique.
1. Pas de standardisation des coûts inter-fournisseurs. La tarification des fournisseurs varie de 10 fois pour des modèles open source identiques [64]. Le CWEP utilise la tarification réelle du fournisseur de chaque agent pour le règlement, ce qui signifie que la même interaction coûte des montants différents selon les fournisseurs utilisés par les agents. Une « unité de coût de token » standardisée indépendante du fournisseur simplifierait le règlement mais n'existe pas.
2. Pas de normalisation des modèles de raisonnement. Les modèles de raisonnement (o3 [32], DeepSeek R1 [65]) génèrent considérablement plus de tokens par tâche — dans les cas extrêmes, plus de 600 tokens pour générer deux mots [14]. Le CWEP compte tous les tokens de manière égale, y compris les tokens de raisonnement interne qui peuvent ou non apparaître dans la sortie. Cela surtaxe les demandeurs dans les interactions à forte composante de raisonnement.
3. Pas de prise en charge des agents hors ligne. Le CWEP suppose une interaction en temps réel ou quasi temps réel. Les interactions asynchrones entre agents de type stocker-et-transmettre (où les requêtes s'accumulent pendant des heures) nécessitent des extensions au protocole de règlement qui ne sont pas spécifiées dans la v1.0.
L'implémentation de référence du CWEP fournit :
L'intégration CWEP la plus simple (niveau 1 : comptage uniquement) nécessite d'encapsuler les appels API LLM avec la bibliothèque cwep-meter :
from cwep import Meter
meter = Meter(agent_id="did:example:my-agent")
# Encapsulation de l'appel LLM existant
response = meter.track(
llm_client.chat(messages=[...]),
counterparty="did:example:other-agent",
interaction_id="uuid-v4"
)
# Le CMR est automatiquement émis vers le stockage local
# response.cwep contient les données de comptage
print(response.cwep.total_cost_usd)L'intégration CWEP complète (niveau 3 : règlement dynamique) nécessite le moteur de règlement :
from cwep import Meter, SettlementEngine, NashBargaining
meter = Meter(agent_id="did:example:my-agent")
engine = SettlementEngine(
method=NashBargaining(
bargaining_power=0.6, # Dérivé du score ARP
disagreement_value=0.0
),
settlement_threshold_usd=0.01,
payment_rail="mpp"
)
# Suivi de l'interaction
response = meter.track(llm_client.chat(...), ...)
# Calcul et exécution du règlement
proposal = engine.propose(response.cwep.cmr)
if proposal.amount_usd > engine.threshold:
receipt = engine.settle(proposal)pip install context-window-economicsPublié sous licence Apache 2.0 sur PyPI et GitHub (vibeagentmaking/context-window-economics).
Le CWEP v1.0 spécifie les réservations bilatérales de contexte (section 14). Les futures versions devraient explorer des marchés multilatéraux du contexte où les agents échangeraient de manière autonome la capacité en temps réel — une véritable place de marché avec découverte des prix, appariement des ordres et règlement. Cela nécessite des unités de capacité standardisées (tokens par période), des signaux de prix en temps réel à travers le réseau d'agents, une liquidité suffisante (de nombreux agents acheteurs et vendeurs), et une infrastructure de teneur de marché ou de place de marché. Le marché de capacité de l'électricité, où les producteurs sont payés pour maintenir la capacité disponible même si elle n'est pas mobilisée [13], fournit le modèle architectural le plus proche. Un marché du contexte complet devient pertinent lorsque le volume d'interactions agent-à-agent atteint des niveaux où la négociation bilatérale devient un goulot d'étranglement.
Le partage des coûts en temps réel sur différents réseaux blockchain introduit des contraintes de latence de règlement. Les travaux futurs devraient évaluer la latence de règlement sur x402 (Base, Polygon, Solana) [3], MPP (réseau Tempo) [4] et L402 (Lightning) [23] pour déterminer quels rails prennent en charge le règlement au niveau de l'interaction (< 1 seconde) vs. le règlement par lots (horaire).
Si les coûts d'inférence diminuent de manière prévisible de 10 fois par an [27], les agents pourraient couvrir les coûts futurs par des contrats à terme — verrouillant les tarifs actuels de tokens pour des interactions futures. Cela créerait un marché de contrats à terme sur les coûts d'inférence, analogue aux contrats à terme sur les matières premières. L'infrastructure pour cela n'existe pas, mais la logique économique est solide.
Le CWEP v1.0 approxime la valeur de l'interaction par les comptes de tokens et les niveaux de modèle. La véritable mesure de la valeur nécessiterait d'évaluer le contenu sémantique d'une interaction — un problème fondamentalement plus difficile qui touche au défi de la vérification de l'intégrité sémantique identifié dans l'architecture de l'écosystème de confiance comme potentiellement insoluble avec la technologie actuelle [66].
Les transactions financières d'agents autonomes évoluent dans une zone grise juridique. Lorsque l'Agent A paie l'Agent B pour le traitement du contexte, qui est la contrepartie juridique ? L'agent, l'opérateur de l'agent, ou le fournisseur de LLM ? Les cadres réglementaires pour le commerce autonome entre agents sont naissants ; le règlement européen sur l'IA traite du comportement des agents mais pas de l'économie des agents. Les futures versions du CWEP devraient intégrer les exigences de conformité réglementaire au fur et à mesure de leur apparition.
La fenêtre de contexte est la ressource la plus rare de l'économie des agents. Elle est finie, coûteuse, non linéaire en coût, et actuellement non tarifée. Chaque interaction entre agents la consomme ; aucun protocole n'en alloue le coût.
Le CWEP y répond avec six mécanismes : le comptage (mesurer les quatre flux de coûts), le règlement bilatéral (Shapley pour les interactions coopératives, Nash pour les interactions compétitives), la tarification du contexte (coûts dépendants de la position reflétant la mise à l'échelle quadratique de l'attention), les niveaux de QoS (limitation de débit par budget de tokens et traitement prioritaire), la prévention du spam (filtrage basé sur les dépôts avec accès conditionné à la réputation) et l'économie de l'optimisation (modèles formels de ROI pour la compression, la mise en cache, la mémoire et le RAG).
Le protocole est honnête sur ce qu'il ne peut pas faire. Le résultat d'impossibilité de Green-Laffont/Moulin-Shenker signifie que l'allocation parfaite des coûts est irréalisable — le CWEP sacrifie une certaine efficacité économique au profit de l'équilibre budgétaire et de la compatibilité d'incitation. La mesure de la valeur est approximative. La mise à l'échelle quadratique des coûts est un modèle idéalisé que les implémentations matérielles réelles approximent à des degrés divers.
Ce que le CWEP réalise, c'est un cadre structuré pour un problème qui n'avait auparavant aucun cadre. Avant le CWEP, les agents absorbaient leurs propres coûts sans aucune visibilité sur la structure bilatérale des coûts de leurs interactions. Après le CWEP, chaque interaction est mesurée, chaque coût est attribuable, et chaque allocation est auditable via le système de provenance Chain of Consciousness.
C'est le fondement économique que l'économie des agents requiert. La provenance (CoC), la réputation (ARP), les contrats (ASA), la responsabilité (AJP), le cycle de vie (ALP), et l'appariement (AMP) fournissent l'infrastructure institutionnelle. Le CWEP fournit l'infrastructure économique — le mécanisme par lequel les agents négocient, allouent et règlent les coûts de la compréhension mutuelle.
Le problème est véritablement nouveau. Nous n'avons pas simplement traduit les modèles du commerce humain en langage d'agents — nous avons identifié une primitive économique fondamentalement nouvelle (le coût de compréhension) et construit un protocole pour la tarifer. L'économie des agents ne ressemblera pas à l'économie humaine dans ses structures de coûts ; le CWEP est conçu pour l'économie qui émerge réellement, et non pour celle que l'on pourrait attendre par analogie.
[1] Anthropic. « Pricing. » platform.claude.com. Consulté en mars 2026.
[2] Stevens Institute ; Koombea. « Hidden Economics of AI Agents » ; « LLM Cost Optimization. » 2025.
[3] Coinbase. « Introducing x402. » coinbase.com. Mai 2025. Voir aussi : Coinbase, « Welcome to x402, » docs.cdp.coinbase.com, 2025.
[4] Stripe. « Introducing the Machine Payments Protocol. » stripe.com/blog. 18 mars 2026. Voir aussi : mpp.dev, documentation Stripe MPP, mars 2026.
[5] Google. « Announcing AP2. » cloud.google.com. Septembre 2025. Voir aussi : Google, « A2A x402 Extension, » cloud.google.com, 2025.
[6] FinOps Foundation. « FOCUS Specification v1.3. » finops.org. Ratifiée le 5 décembre 2025.
[7] Langfuse. « Token & Cost Tracking. » langfuse.com. Licence MIT. 2025. Voir aussi : Langfuse, « Pricing Tiers for Accurate Model Cost Tracking, » décembre 2025.
[8] BerriAI. « LiteLLM. » GitHub. 2025. Voir aussi : LiteLLM, « Agent (A2A) Gateway with agent cost tracking, » docs.litellm.ai, 2025.
[9] Portkey. « Tracking LLM Token Usage Across Providers, Teams and Workloads. » portkey.ai. 2025.
[10] Shapley, L. S. « Notes on the n-Person Game — II: The Value of an n-Person Game. » RAND Corporation, 1951. Publié sous : « A Value for n-Person Games, » Contributions to the Theory of Games (H. W. Kuhn et A. W. Tucker, éd.), Annals of Mathematics Studies 28, Princeton University Press, 1953.
[11] Nash, J. « The Bargaining Problem. » Econometrica 18(2), 1950.
[12] Green, J. et Laffont, J.-J. Incentives in Public Decision Making. North-Holland, 1979. Voir aussi : Moulin, H. et Shenker, S. « Strategyproof Sharing of Submodular Costs: Budget Balance versus Efficiency. » Economic Theory 18(3), 2001.
[13] PCI Energy Solutions. « Understanding Locational Marginal Pricing (LMP). » 2025.
[14] iKangAI. « The LLM Cost Paradox: How Cheaper AI Models Are Breaking Budgets. » 2025. Voir aussi : Holter, A. « AI Costs in 2025: Cheaper Tokens, Pricier Workflows. » 2025.
[15] Zuplo. « Token-Based Rate Limiting for AI APIs. » 2025. Voir aussi : TrueFoundry, Gartner Market Guide for AI Gateways, 2025.
[16] Kuldeep Paul. « Prompt Compression Techniques: LLMLingua. » Medium, 2025.
[17] Agent Justice Protocol. AB Support LLC. 2026.
[18] arXiv:2603.04814. « Memory vs. Long-Context Cost Analysis. » 2026.
[19] Agent Matchmaking Protocol. AB Support LLC. 2026.
[20] Agent Service Agreements Protocol. AB Support LLC. 2026.
[21] Agent Rating Protocol v2. AB Support LLC. 2026.
[22] Chain of Consciousness v3. AB Support LLC. 2026.
[23] Lightning Labs. « Lightning Agent Tools. » 12 février 2026. Voir aussi : Bitcoin Magazine, couverture de Lightning Agent Tools, février 2026.
[24] Superfluid. « ERC-8004 Agent Pool. » superfluid.org. 2026. Voir aussi : Sablier Protocol, sablier.com, 2026.
[25] arXiv:2512.08296. « Towards a Science of Scaling Agent Systems. » Décembre 2025.
[26] MarkAICode. « LangGraph vs CrewAI: Multi-Agent Performance and Cost in Production 2026. » 2026.
[27] a16z. « LLMflation: LLM Inference Cost. » a16z.com. Novembre 2024. Voir aussi : Epoch AI, « LLM Inference Price Trends, » 2025.
[28] Internet Society. « Interconnection and Regulated Traffic Obligations. » Mars 2025.
[29] FCC. « All-IP Future, » WC Docket Nos. 25-311, Notice of Proposed Rulemaking. 28 janvier 2026.
[30] Google. « Gemini Developer API Pricing. » ai.google.dev. Consulté en mars 2026.
[31] Maxim.ai. « Context Engineering for AI Agents: The 100:1 Input-Output Ratio. » 2025.
[32] OpenAI. « Pricing. » developers.openai.com. Consulté en mars 2026.
[33] Hardin, G. « The Tragedy of the Commons. » Science 162(3859), 1968.
[34] Simon, H. A. « Designing Organizations for an Information-Rich World. » Computers, Communications, and the Public Interest (M. Greenberger, éd.), Johns Hopkins Press, 1971.
[35] Anthropic. « Effective Context Engineering for AI Agents. » 2025.
[36] Heitmayer, M. « Second Wave of Attention Economics. » Interacting with Computers 37(1), 2024.
[37] Mem0. mem0.ai. 2025.
[38] Zep. zep.ai. 2025.
[39] Letta. letta.com. 2025.
[40] VentureBeat. « WEKA Augmented Memory Grid. » 2025. Voir aussi : WEKA, « Token Warehousing, » 2025.
[41] PCI Energy Solutions. « Negative LMP Events in SPP. » 2025.
[42] Deng, X. et Papadimitriou, C. H. « On the Complexity of Cooperative Solution Concepts. » Mathematics of Operations Research 19(2), 1994.
[43] Fast Approximation of Shapley Values Using Fractional Factorial Designs. Journal of the American Statistical Association (JASA), 2025.
[44] Lundberg, S. M. et Lee, S.-I. « A Unified Approach to Interpreting Model Predictions. » NeurIPS, 2017.
[45] Wang, J. et al. « ShapleyFL: Robust Federated Learning Based on Shapley Value. » KDD, 2023.
[46] VerFedSV. « Verified Federated Shapley Value. » 2024.
[47] Schmeidler, D. « The Nucleolus of a Characteristic Function Game. » SIAM Journal on Applied Mathematics 17(6), 1969.
[48] Kalai, E. « Nonsymmetric Nash Solutions and Replications of 2-Person Bargaining. » International Journal of Game Theory 6(3), 1977.
[49] Rubinstein, A. « Perfect Equilibrium in a Bargaining Model. » Econometrica 50(1), 1982.
[50] Moulin, H. « Incremental Cost Sharing: Characterization by Coalition Strategy-Proofness. » Social Choice and Welfare 16(2), 1999.
[51] Vickrey, W. « Counterspeculation, Auctions, and Competitive Sealed Tenders. » Journal of Finance 16(1), 1961. Voir aussi : Clarke, E. H. « Multipart Pricing of Public Goods. » Public Choice 11(1), 1971 ; Groves, T. « Incentives in Teams. » Econometrica 41(4), 1973.
[52] Internet Society. « South Korea 'Sender Pays' Analysis. » 2025.
[53] BEREC. « Preliminary Assessment of Payments from Large CAPs to ISPs. » 2023.
[54] FERC. « Order 1920 Fact Sheet. » 13 mai 2024.
[55] State of FinOps Report. FinOps Foundation. 2025. Voir aussi : Datadog, statistiques de gaspillage des conteneurs, 2025.
[56] AG2. « Usage Tracking. » docs.ag2.ai. 2025.
[57] Google. « A2A Agent Card Specification. » 2025.
[58] Gartner. « Market Guide for AI Gateways. » 2025. Voir aussi : TrueFoundry, Zuplo, 2025.
[59] VentureBeat. « xMemory: Four-Level Semantic Hierarchy. » King's College London / Alan Turing Institute. 2025.
[60] CoinDesk. « Coinbase-backed AI payments protocol wants to fix micropayment but demand is just not there yet. » 11 mars 2026.
[61] ScienceDirect. « Evolution of Energy Currencies: From ATP to Digital Money. » Octobre 2025.
[62] Mostafa, A. et al. « Biological Market Theory Applied to Microbial Communities. » Microlife, 2024.
[63] PNAS. « Host-Symbiont Mutualisms and Employment Contract Theory. » 2010.
[64] Introl. « Inference Unit Economics: True Cost Per Million Tokens Guide. » 2025.
[65] DeepSeek. « DeepSeek R1 Pricing. » deepseek.com. 2026.
[66] AB Support Trust Ecosystem Architecture. « Semantic Integrity Verification — Research Frontier. » 2026.
Copyright 2026 AB Support LLC. Sous licence Apache, version 2.0.
Ancrage Chain of Consciousness : livre blanc du protocole v1.0.0