L’utilisation de tokens par les agents OpenRouter est 5 fois supérieure au trafic humain, mais l’avance provient surtout du contexte mis en cache

L’utilisation de tokens par les agents OpenRouter a atteint 7,3 billions de tokens en août, soit plus de cinq fois les 1,4 billion attribués aux humains sur la plateforme. Pourtant, plus de 85 % de ces tokens d’agents proviendraient de prompts mis en cache, et non d’instructions nouvellement traitées ou de réponses générées.

Cette distinction complique l’affirmation selon laquelle l’IA utiliserait désormais davantage l’IA que les humains. Les agents génèrent clairement beaucoup plus de trafic de modèles par tâche. Toutefois, le graphique mesure les tokens acheminés via une seule plateforme, et non l’adoption mondiale de l’IA, les dépenses, le travail productif ou la valeur économique.

Daniel Newman, PDG de Futurum Group, a relayé ces chiffres dans une publication sur X le 30 septembre. Il a prédit que le ratio passerait de cinq à dix fois, puis continuerait d’augmenter. Le chiffre de cinq fois provient du trafic OpenRouter observé. Celui de dix fois reste une prévision sans échéance précisée ni modèle justificatif.

Le véritable enjeu n’oppose donc pas les agents aux humains. Il oppose le volume brut de tokens au travail utile. Cette distinction importe pour les développeurs qui gèrent des boucles d’agents, les entreprises qui évaluent les retours et les fournisseurs d’infrastructure qui planifient leur capacité mémoire.

L’utilisation de tokens des agents OpenRouter a franchi un seuil clair

Les données d’août montrent une évolution majeure du trafic des modèles, mais uniquement dans l’environnement mesuré par OpenRouter.

OpenRouter exploite une passerelle qui achemine les requêtes entre différents modèles et fournisseurs d’inférence. Cette position donne à l’entreprise une visibilité sur des trafics d’applications variés, y compris les conversations directes, les outils de programmation et les flux de travail autonomes.

Le graphique publié présente l’utilisation moyenne de tokens sur sept jours jusqu’au 10 août 2026. Le trafic agentique a atteint environ 7,3 billions de tokens, contre 1,4 billion pour le trafic humain.

Le ratio obtenu est d’environ 5,2 pour un. Il étaye l’affirmation plus limitée selon laquelle les agents ont généré cinq fois plus de trafic de tokens que les humains sur OpenRouter durant cette période de mesure.

Il n’établit pas le même ratio pour ChatGPT, Claude, Gemini, les déploiements de cloud privé ou les modèles hébergés localement. Ces systèmes représentent un trafic considérable qu’OpenRouter ne peut pas observer.

OpenRouter a également indiqué que l’utilisation agentique avait été multipliée par environ quatorze depuis le 6 février. L’utilisation humaine de tokens a augmenté d’environ 2,8 fois sur la même période. Le trafic mixte, qui combine comportements humains et apparentés aux agents, aurait progressé d’environ 4,7 fois.

Le 6 février était la dernière date observée à laquelle le trafic humain demeurait supérieur au trafic des agents dans l’ensemble de données. Cela rend le résultat d’août plus significatif qu’un simple pic quotidien. Les agents avaient maintenu et élargi leur avance pendant environ six mois.

OpenRouter a classé chaque clé API comme agentique, humaine ou mixte. Le système aurait utilisé sept signaux pondérés, notamment les taux d’appels d’outils, le nombre de tours et les écarts de temps entre les réponses.

Cette approche est plus instructive que de s’appuyer uniquement sur les noms des applications. Un client API générique peut exécuter une boucle autonome, tandis qu’une application commercialisée comme agent peut rester sous contrôle humain direct.

Cependant, la classification comportementale introduit de l’incertitude. Les clés API peuvent servir plusieurs produits, équipes ou cas d’usage. Une charge de travail peut aussi passer d’un comportement dirigé par l’humain à un comportement automatisé sans changement d’identifiants.

La catégorie mixte reconnaît cette ambiguïté, sans pour autant l’éliminer. Réattribuer une partie de ce trafic modifierait le ratio entre les agents et les humains.

Il existe un autre enjeu sémantique important. Les agents ne sont pas des clients indépendants au sens économique habituel. Des humains et des organisations les déploient, définissent leurs objectifs, financent leurs requêtes et décident si leurs résultats ont de la valeur.

Les agents sont mieux compris comme des intermédiaires automatisés. Une requête humaine peut déclencher la planification, la récupération d’informations, l’exécution d’outils, la validation, la correction et des appels répétés aux modèles.

Cet effet multiplicateur est le fait central. La demande en IA n’est plus déterminée uniquement par le nombre de personnes qui ouvrent une fenêtre de chat. Elle dépend de plus en plus de l’activité machine que déclenche chaque requête humaine.

La précédente étude sur 100 billions de tokens d’OpenRouter a identifié le même changement structurel. Elle décrit l’inférence agentique comme une séquence étendue comprenant planification, outils, révisions et interactions répétées avec les modèles.

L’étude a constaté que la programmation était devenue une source majeure de croissance des prompts. À la fin de 2025, les prompts de programmation avaient également une longueur moyenne plusieurs fois supérieure à celle des prompts généralistes.

Ces tendances aident à expliquer pourquoi les agents ont franchi ce seuil. Une personne peut soumettre une seule demande de programmation. Un agent peut inspecter les fichiers à répétition, appeler des outils, examiner les résultats de tests et renvoyer son contexte de travail.

Le graphique d’août saisit cette amplification à l’échelle de la plateforme. Il ne prouve pas que les logiciels autonomes ont remplacé la demande humaine. Il montre que la demande humaine passe de plus en plus par des systèmes qui créent de nombreuses requêtes en aval.

Une instruction humaine peut déclencher des milliers d’opérations de modèle

Les agents consomment davantage de tokens parce qu’ils transforment une requête unique en processus de calcul continu.

Une interaction classique avec un chatbot suit généralement un rythme visible. Une personne rédige un prompt, reçoit une réponse et décide si elle souhaite poursuivre. Chaque nouveau tour dépend d’une nouvelle action humaine.

Un agent peut continuer sans cette pause. Il interprète un objectif, crée des étapes, choisit des outils, évalue les résultats et décide si une autre tentative est nécessaire.

Prenons une migration logicielle. Un développeur peut demander à un agent de déplacer une application d’un service cloud vers un autre.

Le premier appel au modèle peut examiner la requête et établir un plan. Les appels suivants peuvent inspecter les fichiers de configuration, rechercher de la documentation, modifier le code, exécuter des tests, diagnostiquer les échecs et réviser l’implémentation.

Chaque appel inclut souvent davantage que l’instruction la plus récente. Il peut transporter les règles système, les définitions d’outils, les détails du dépôt, les messages précédents, la sortie des commandes et les décisions antérieures de l’agent.

Cet ensemble accumulé constitue la fenêtre de contexte, c’est-à-dire le texte et les données structurées disponibles pour le modèle lors d’une requête. À mesure que la tâche progresse, ce contexte peut devenir beaucoup plus volumineux que le prompt humain initial.

L’utilisation d’outils accroît encore le trafic. Un modèle peut générer une requête de base de données, inspecter le résultat, puis appeler à nouveau le modèle afin de déterminer la suite.

Des agents parallèles peuvent multiplier à nouveau le processus. Un coordinateur peut déléguer la recherche, le codage, les tests et la revue à des travailleurs distincts. Chaque travailleur conserve ses propres instructions et son historique de tâches.

Cela explique pourquoi le volume de tokens peut croître bien plus vite que le nombre d’utilisateurs. L’unité fondamentale est passée du tour de conversation à l’étape de flux de travail.

Les données d’OpenRouter reflètent également la croissance des charges de travail de raisonnement et de programmation. Ces tâches se prêtent naturellement à des interactions plus longues, car elles impliquent un état intermédiaire, des outils externes et des validations répétées.

Des données académiques suggèrent que l’amplification peut devenir extrême. Une étude de 2026 sur le codage agentique a révélé que les tâches d’agents consommaient environ 1 000 fois plus de tokens que le chat de code dans son cadre expérimental.

La recherche sur le coût des agents a également relevé de fortes variations entre les exécutions répétées. Dans les tests des chercheurs, l’utilisation de tokens pour une même tâche variait jusqu’à trente fois.

Surtout, un plus grand nombre de tokens ne produisait pas systématiquement de meilleurs résultats. Les performances atteignaient souvent un pic à un niveau intermédiaire avant que la consommation additionnelle ne cesse d’apporter des gains correspondants.

Cette constatation renforce la principale tension derrière l’utilisation de tokens par les agents OpenRouter. Un total en hausse peut représenter une automatisation productive, des répétitions inutiles, ou un mélange des deux.

Les concepteurs d’agents sont donc soumis à une pression pour mesurer le travail accompli, et non seulement l’activité générée. Parmi les indicateurs utiles figurent les modifications de code acceptées, les cas de support résolus, les transactions réussies et les tâches achevées sans intervention humaine corrective.

Un token n’est qu’une unité de traitement de texte. Il n’intègre aucune mesure de précision, de difficulté, de nouveauté ou de valeur commerciale.

Deux flux de travail peuvent consommer le même nombre de tokens tout en produisant des résultats très différents. L’un peut résoudre un problème d’ingénierie complexe. L’autre peut répéter un plan défaillant jusqu’à ce qu’une limite l’arrête.

La conception du système environnant détermine quel résultat est le plus probable. Des critères clairs d’achèvement aident un agent à reconnaître le succès. Des politiques de relance limitées empêchent une tâche en échec de s’exécuter indéfiniment.

De bons outils réduisent également le besoin de longs raisonnements textuels. Une API structurée peut renvoyer un résultat précis qui nécessiterait autrement des recherches et interprétations répétées.

L’architecture de la mémoire compte pour la même raison. Un agent n’a pas besoin de chaque ancien détail à chaque étape. Il a besoin du sous-ensemble qui demeure pertinent pour la décision actuelle.

C’est là qu’une base de connaissances personnelle interrogeable peut soutenir des flux de travail dirigés par l’humain. Les éléments récupérés peuvent remplacer un historique indifférencié lorsque le système sélectionne soigneusement le contexte.

La pression dépasse les développeurs. Les acheteurs en entreprise doivent désormais évaluer la manière dont les produits contrôlent les boucles, récupèrent le contexte et rendent compte de la consommation.

Un produit peut sembler efficace lors d’une courte démonstration, mais se comporter différemment dans des charges de travail de longue durée. Les tâches de production rencontrent des autorisations manquantes, des objectifs ambigus, des données changeantes et des réponses d’outils inattendues.

Ces conditions génèrent des relances. Elles révèlent aussi si l’agent dispose de règles d’arrêt fiables ou s’il continue simplement à produire des étapes suivantes plausibles.

L’adoption humaine demeure importante, mais elle ne prédit plus à elle seule la demande d’inférence. La formule plus utile comprend les utilisateurs, les tâches déléguées, les appels de modèle par tâche et les tokens par appel.

Cette formule rend un ratio de dix fois plausible en principe. Elle ne rend pas la prévision de Newman inévitable. Le ratio dépendra aussi de l’optimisation, du comportement des modèles, de la conception des applications et du trafic hors d’OpenRouter.

Les prompts mis en cache expliquent l’essentiel de l’explosion des tokens

La plus grande part de l’avance des agents semble provenir de contexte répété, et non de raisonnement ou de production entièrement nouveaux.

Plus de 85 % des tokens d’agents dans la présentation a16z proviendraient de prompts mis en cache. Les prompts mis en cache sont des segments d’entrée déjà traités qu’un fournisseur peut réutiliser lorsqu’une requête ultérieure commence par un contenu identique.

Un agent renvoie souvent du contenu stable. Ce contenu peut inclure des instructions système, des descriptions d’outils, des fichiers de projet, des politiques et l’historique de conversations antérieures.

Traiter ce même préfixe depuis zéro à chaque appel gaspillerait de la puissance de calcul. La mise en cache des prompts permet au fournisseur de réutiliser des résultats intermédiaires associés à ce préfixe.

La télémétrie de cache d’OpenRouter distingue les tokens mis en cache des tokens de prompts nouvellement traités. Elle peut également identifier les tokens écrits dans un cache pour une réutilisation ultérieure.

Cela signifie que 7,3 billions de tokens ne doivent pas être interprétés comme 7,3 billions d’unités de travail frais du modèle. Une grande part représente des informations que le système a déjà rencontrées.

Cette distinction affecte les coûts. Les fournisseurs facturent généralement moins une lecture de cache que le traitement de nouvelles entrées, car une grande partie du calcul précédent a déjà eu lieu.

Cependant, le cache ne signifie pas que cela soit gratuit. Le système doit identifier l’entrée de cache, récupérer ses données et rendre l’état de modèle associé disponible pendant l’inférence.

L’état de modèle concerné est souvent appelé cache clé-valeur, ou cache KV. Il stocke les informations d’attention dérivées des tokens précédents afin que le modèle puisse poursuivre sans recalculer chaque position antérieure.

Des prompts plus longs créent des caches KV plus volumineux. Davantage de sessions d’agents simultanées en créent davantage. Les workflows de longue durée peuvent également nécessiter des accès répétés à un contexte stocké conséquent.

Cela déplace le goulot d’étranglement de l’infrastructure. Le calcul reste important, mais la capacité mémoire, la bande passante mémoire et les déplacements de données prennent une importance croissante.

C’est pourquoi la part mise en cache ne rend pas les données d’OpenRouter dénuées de sens. Elle change la signification de ces données.

Le graphique constitue une preuve moins solide d’une demande de raisonnement nouveau. Il constitue une preuve plus solide que les systèmes d’agents transportent à répétition de longs historiques au fil de nombreux appels de modèles.

La différence ressemble à la consultation répétée du même gros classeur de projet. Relire des pages déjà connues demande moins de préparation qu’analyser de nouvelles pages, mais le classeur doit rester disponible.

La mise en cache peut aussi rendre financièrement tolérable une conception d’agent inefficace. Un workflow peut renvoyer un énorme prompt système parce que la lecture de cache à tarif réduit masque une partie du coût.

Cette conception consomme tout de même de la capacité. Elle peut accroître la latence, compliquer le routage et créer une dépendance à des préfixes de prompt stables.

Les accès au cache ne sont pas garantis dans toutes les configurations. Modifier une partie initiale du prompt peut invalider le matériel mis en cache par la suite. Le routage des requêtes entre fournisseurs peut également affecter la réutilisation.

Les données dynamiques posent un autre défi. Si des horodatages, des documents récupérés, des résultats d’outils ou des détails propres à l’utilisateur apparaissent près du début, ils peuvent réduire la stabilité du préfixe.

Les développeurs d’agents ont donc besoin d’une structure de contexte délibérée. Les instructions stables doivent se trouver au début, tandis que les informations changeantes devraient apparaître après les sections réutilisables lorsque le comportement du fournisseur le permet.

L’affinité de session peut également compter. Les requêtes qui restent associées à un fournisseur compatible sont plus susceptibles de réutiliser un contexte antérieur que celles routées de manière imprévisible.

Le chiffre de 85 % mérite aussi une attribution prudente. Il est apparu dans le cadrage d’a16z des données d’OpenRouter, selon le rapport source. L’analyse originale d’OpenRouter a également été décrite comme affichant une part plus faible selon un autre calcul.

Des dénominateurs différents peuvent produire des pourcentages différents. Une méthode peut agréger l’ensemble du volume de tokens, tandis qu’une autre calcule la moyenne de la part mise en cache entre les requêtes.

Quelques workflows énormes peuvent dominer le volume total sans représenter la requête typique. À l’inverse, un pourcentage moyen par requête peut sous-estimer l’influence des charges de travail les plus importantes.

Les deux mesures peuvent être exactes tout en répondant à des questions différentes. Le graphique public ne fournit pas assez de détails méthodologiques pour réconcilier indépendamment chaque pourcentage de cache rapporté.

La conclusion la plus sûre est donc directionnelle. Le contexte mis en cache constitue la nette majorité du trafic de tokens des agents, tandis que la part précise dépend de la manière dont la plateforme agrège les requêtes.

Cela remet également en question l’expression « l’IA utilise l’IA ». Les agents n’accomplissent pas nécessairement des milliers de milliards d’actes de raisonnement indépendants. Une grande partie de leur trafic consiste à restaurer le contexte nécessaire pour poursuivre un travail délégué.

Ce comportement peut néanmoins générer une vraie valeur. Un agent de programmation a besoin de l’état du dépôt et des décisions antérieures pour éviter de repartir de zéro après chaque appel d’outil.

La question d’efficacité concerne la sélection. L’agent recharge-t-il le plus petit contexte utile, ou renvoie-t-il sans cesse tout le contenu parce que cette approche est plus facile à mettre en œuvre ?

À mesure que le volume de tokens augmente, cette différence devient un choix d’ingénierie important. Une gestion efficace du contexte peut réduire la demande mémoire sans affaiblir les performances de la tâche.

Cinq Fois Plus de Tokens Ne Signifie Pas Cinq Fois Plus de ROI

Le volume de tokens mesure l’utilisation, tandis que le retour sur investissement dépend des résultats obtenus et du coût total d’exploitation.

Newman a soutenu que les entreprises se concentrent trop sur l’adoption humaine lorsqu’elles évaluent les retours de l’IA. Son propos plus large est fondé, car un utilisateur peut désormais déclencher bien plus d’inférence qu’une métrique d’adoption fondée sur le chat ne le révèle.

Les utilisateurs actifs mensuels peuvent sous-estimer la demande d’infrastructure. Le nombre de licences peut également ne pas refléter le travail automatisé qui s’exécute continuellement après que les employés ont quitté leur bureau.

Pourtant, remplacer le nombre d’utilisateurs par le nombre de tokens crée une autre mesure incomplète. Les tokens révèlent une activité, mais ne montrent pas si cette activité a généré des revenus, réduit le travail humain, amélioré la qualité ou accru les risques.

Le ratio de cinq fois compare également deux catégories de trafic plutôt que deux acteurs économiques. Les requêtes d’agents restent en aval de décisions humaines ou organisationnelles.

Une entreprise ne génère pas un retour parce qu’un agent a consommé davantage de tokens. Elle en génère un lorsque l’agent accomplit un travail de valeur à un coût et à un niveau de risque acceptables.

Une évaluation utile commence par la réussite de la tâche. Les équipes doivent se demander si le workflow a réalisé l’action prévue et si un humain a accepté le résultat.

La question suivante concerne l’intervention. Un agent qui termine sans supervision présente un profil opérationnel différent de celui qui exige des corrections répétées.

La latence compte aussi. Un workflow qui finit par réussir peut tout de même échouer commercialement si les clients doivent attendre trop longtemps ou si les files d’infrastructure s’allongent lors des pics de charge.

Vient ensuite le coût total. Les frais liés aux tokens ne sont qu’une composante. Les appels d’outils, les services de recherche, les bases de données, les sandboxes, l’observabilité, les revues de sécurité et la remédiation humaine peuvent ajouter des dépenses importantes.

Les résultats ajustés au risque comptent également. Un agent qui modifie des systèmes de production nécessite des contrôles plus solides qu’un agent qui résume des documents publics.

Le graphique d’OpenRouter ne peut répondre à aucune de ces questions. Il a été conçu pour décrire le trafic, pas les retours des entreprises.

La même limite s’applique à la prédiction de Newman d’un facteur 10. Extrapoler ce ratio suppose que le trafic des agents continue de croître plus vite que le trafic humain sans correction d’efficacité comparable.

Cette hypothèse peut échouer pour plusieurs raisons. Les applications peuvent compresser le contexte, utiliser des modèles plus petits pour les étapes routinières, remplacer le raisonnement répété par des logiciels déterministes et arrêter les boucles plus tôt.

Les améliorations des modèles peuvent réduire les nouvelles tentatives. De meilleures interfaces d’outils peuvent également renvoyer des informations plus propres, réduisant le nombre d’appels nécessaires pour terminer une tâche.

La pression économique encouragera ces changements. Les entreprises ont intérêt à supprimer les appels qui n’améliorent pas les résultats, même lorsque les lectures de cache sont relativement peu coûteuses.

La discussion d’a16z sur la convergence des boucles met en évidence le même problème. Un agent peut continuer à produire du travail supplémentaire après que la majeure partie de la valeur disponible est déjà apparue.

Une boucle sans test externe de complétion peut confondre activité continue et progrès. Elle peut modifier à répétition un document, relancer une commande en échec ou affiner une réponse déjà acceptable.

Ce comportement est particulièrement difficile à détecter lorsque chaque appel individuel semble raisonnable. Le gaspillage apparaît sur l’ensemble de la trajectoire plutôt qu’au sein d’une seule réponse.

L’observabilité doit donc fonctionner au niveau de la tâche. Les développeurs ont besoin de traces qui relient chaque appel de modèle à l’utilisation d’outils, aux changements d’état, aux erreurs et aux résultats finaux.

Les budgets doivent également refléter la valeur de la tâche. Une enquête à forts enjeux peut justifier davantage d’itérations qu’une demande de mise en forme routinière.

Les règles d’escalade créent une autre limite. Lorsque l’agent rencontre des échecs répétés ou des autorisations incertaines, passer le contrôle à une personne peut être moins coûteux et plus sûr.

Le trafic d’OpenRouter présente également un effet de sélection. La plateforme sert des développeurs qui choisissent délibérément d’utiliser une passerelle de modèles, ce qui peut produire une répartition des charges de travail plus technique que les applications grand public.

La programmation et les frameworks d’agents peuvent donc occuper une part plus importante d’OpenRouter que de l’ensemble du marché de l’IA.

L’échelle d’OpenRouter rend néanmoins la tendance importante. Ses données couvrent un trafic réel substantiel, réparti entre de nombreux modèles et fournisseurs. Les résultats doivent simplement rester liés à ce périmètre.

Les relations de la plateforme introduisent une autre considération. Andreessen Horowitz a investi dans OpenRouter, ce qui donne à a16z un intérêt dans la croissance de l’infrastructure de routage des tokens.

Cela n’invalide pas les chiffres. Cela rend une méthodologie transparente et une réplication indépendante plus importantes, en particulier lorsque les données soutiennent de vastes affirmations sur l’économie de l’IA.

L’interprétation la plus solide évite les deux extrêmes. Le graphique n’est ni la preuve que les machines autonomes sont devenues les principaux clients de l’IA, ni un simple artefact vide de la mise en cache.

Il montre que les architectures d’agents amplifient la demande d’inférence. Il montre également que cette amplification repose actuellement fortement sur le transport et la récupération d’anciens contextes.

Pour les acheteurs, la question centrale n’est pas de savoir si un agent utilise beaucoup de tokens. Il s’agit de savoir si chaque cycle supplémentaire augmente la probabilité d’un résultat réussi et précieux.

Les Fournisseurs de Mémoire et les Plateformes d’Agents Subissent une Pression Immédiate

L’évolution du trafic récompense les systèmes qui gèrent efficacement le contexte et met sous pression les produits qui traitent la consommation de tokens comme un indicateur de progrès.

Les fournisseurs de modèles font face à une charge de travail plus complexe que le chat ordinaire de type requête-réponse. Les sessions d’agents peuvent rester actives plus longtemps, appeler des outils à répétition et conserver des historiques croissants.

Cette charge de travail exerce une pression sur les ordonnanceurs et les systèmes de routage. Les fournisseurs doivent équilibrer la localité du cache, la disponibilité des modèles, la latence et la fiabilité face à une demande changeante.

Les plateformes de passerelle telles qu’OpenRouter gagnent en importance stratégique, car les applications utilisent de plus en plus plusieurs modèles. Un workflow peut router la planification, la programmation, la validation et la synthèse vers différents endpoints.

Le routage dynamique peut réduire les coûts ou améliorer les performances, mais il peut aussi perturber la mise en cache. Une requête envoyée à un autre fournisseur peut perdre l’accès à un cache précédemment établi.

Les fournisseurs qui exposent des métriques de cache claires disposeront d’un avantage auprès d’acheteurs avertis. Les équipes doivent savoir combien de tokens étaient nouveaux, mis en cache, générés ou écrits dans le stockage.

Les fabricants de mémoire font également face à une demande liée aux contextes plus larges et à un plus grand nombre de sessions simultanées. La mémoire à haute bande passante alimente les accélérateurs de modèles, tandis que la mémoire conventionnelle et le stockage soutiennent les systèmes environnants.

Cependant, le graphique ne quantifie pas les futurs achats de mémoire. Il montre le trafic de tokens, pas une correspondance exacte entre chaque token et une nouvelle capacité matérielle.

La demande matérielle dépend de l’architecture du modèle, des types de données, du batching, de l’éviction du cache, de la compression et du nombre de sessions simultanées. Les améliorations logicielles peuvent modifier chacune de ces relations.

Les plateformes d’agents subissent une pression venue d’une autre direction. Les clients compareront de plus en plus le travail utile par token, et non seulement l’accès à des modèles performants.

Les produits qui masquent la consommation derrière de larges affirmations d’usage peuvent rencontrer des difficultés lorsque les équipes financières des entreprises exigent une économie au niveau de la tâche. Les acheteurs voudront des preuves reproductibles sur leurs propres charges de travail.

Les agents de programmation offrent un premier test, car leurs résultats peuvent être évalués à l’aide de builds, de tests, de revues et de résultats de déploiement. Ces signaux créent des conditions d’arrêt mesurables.

D’autres domaines restent plus difficiles. La recherche, la stratégie et la rédaction manquent souvent d’un test objectif unique. Les agents peuvent continuer à affiner leurs résultats sans moment clair de complétion.

Cette incertitude rend la revue humaine plus importante, même lorsque les agents accomplissent la majeure partie du travail intermédiaire. Elle rend également l’efficacité en tokens plus difficile à comparer entre fournisseurs.

Les fournisseurs d’infrastructure peuvent répondre par la compression du contexte, la mise en cache des préfixes, les sessions avec état et les systèmes de récupération. Chaque approche vise à éviter de renvoyer des historiques inutiles.

Les développeurs d’applications peuvent dissocier la mémoire durable du contexte de travail. La mémoire durable stocke des informations potentiellement utiles, tandis que le contexte de travail ne contient que ce dont l’étape en cours a besoin.

Cette séparation réduit les répétitions de texte et limite les informations non pertinentes. Elle peut aussi améliorer la précision des modèles en maintenant les distractions hors du prompt actif.

Les logiciels déterministes devraient prendre en charge les tâches déterministes. Un agent n’a pas besoin de raisonner pour effectuer un calcul, valider un schéma ou vérifier un accès lorsque du code fiable peut s’en charger directement.

Les systèmes les plus efficaces combineront probablement des modèles et des logiciels conventionnels. Les modèles gèrent l’ambiguïté et la planification, tandis que le code applique les règles et exécute les opérations stables.

Cette conception hybride fragilise l’hypothèse selon laquelle le trafic des agents doit augmenter sans limite. De meilleurs systèmes peuvent accomplir davantage de tâches tout en réduisant le nombre de tokens par tâche.

Dans le même temps, la baisse des coûts unitaires peut accroître la demande totale. Lorsque chaque workflow devient moins coûteux, les développeurs peuvent déployer des agents dans davantage de contextes et les exécuter plus souvent.

L’effet rebond qui en résulte peut maintenir la croissance des infrastructures, même lorsque les tâches individuelles deviennent plus efficaces. Cette possibilité soutient l’orientation de la prévision de Newman, sans en valider le ratio précis.

Le trafic humain peut également augmenter. De meilleurs produits grand public, de nouvelles interfaces et une adoption plus large en entreprise pourraient accroître l’usage direct parallèlement au trafic des agents.

Le ratio futur dépend de la courbe qui croîtra le plus vite. Il ne découle pas uniquement de l’amélioration des agents.

La concurrence entre OpenAI, Anthropic, Google, les développeurs de modèles à poids ouverts et les fournisseurs spécialisés d’inférence façonnera cette courbe. Leurs règles de mise en cache et leurs capacités d’outillage diffèrent.

Le choix du modèle peut également évoluer au cours d’un workflow. Un petit modèle peut classer une demande, tandis qu’un modèle plus grand traite une décision difficile.

Cette architecture réduit la pertinence d’un unique décompte agrégé de tokens. Un token traité par un modèle compact présente un profil de ressources différent de celui traité par un modèle de pointe.

Les entreprises auront besoin de mesures normalisées combinant le choix du modèle, le type de token, la latence, l’énergie et la réussite des tâches. Aucune norme largement acceptée ne couvre actuellement l’ensemble du tableau.

En attendant qu’une telle norme émerge, l’usage des tokens d’agents sur OpenRouter demeure un indicateur avancé utile. Il révèle la forme de la demande avant que les rapports financiers puissent en expliquer la valeur.

Trois signaux mettront à l’épreuve la prévision de 10x

La prochaine phase devrait être évaluée selon la stabilité de la classification, la croissance des nouveaux tokens et le travail accompli par unité d’inférence.

Le premier signal sera de savoir si le ratio agents-humains d’OpenRouter continue d’augmenter après août. Une hausse durable étayerait l’idée que les workflows autonomes se développent plus rapidement que les interactions directes.

La comparaison devrait utiliser la même méthode de classification et la même fenêtre de mesure. Des changements de méthode pourraient créer une croissance apparente sans évolution équivalente des comportements.

Le trafic mixte mérite une attention particulière. S’il progresse plus vite que les deux catégories, la frontière entre usages humains et usages d’agents deviendra moins fiable.

Le deuxième signal concerne la composition des tokens d’agents. Une part croissante de tokens mis en cache indiquerait que la répétition du contexte, plutôt que le traitement de nouvelles requêtes par les modèles, demeure le principal moteur de croissance.

Une baisse de la part mise en cache, accompagnée d’une hausse du volume total, raconterait une autre histoire. Elle suggérerait que les agents effectuent davantage de nouvelles inférences au lieu de rejouer principalement un contexte établi.

Les rapports publics devraient distinguer les nouvelles entrées, les lectures de cache, les écritures de cache, les tokens de raisonnement et les sorties. Les regrouper en un seul chiffre masque des différences majeures de coût et de demande d’infrastructure.

Le troisième signal est l’efficacité des tâches. Les fournisseurs d’agents et les utilisateurs en entreprise devraient communiquer le travail accompli par appel de modèle, les tokens par tâche réussie et les interventions humaines par réalisation.

Si ces mesures s’améliorent tandis que le trafic total des agents augmente, l’argument en faveur de la croissance devient plus solide. Cela indiquerait que l’adoption et l’automatisation réussie progressent de concert.

Si l’utilisation de tokens augmente alors que la réussite reste stable, le graphique décrirait de plus en plus un gaspillage opérationnel. Un ratio plus élevé affaiblirait alors, plutôt que renforcerait, l’argument du ROI.

Des jeux de données indépendants renforceraient également la confiance. Le trafic provenant d’API directes de modèles, de plateformes cloud et de déploiements privés pourrait montrer si OpenRouter reflète le marché dans son ensemble.

Pour l’instant, les éléments disponibles étayent une conclusion plus restreinte que l’affirmation virale. Les agents ont généré plus de cinq fois le trafic de tokens humains observé sur OpenRouter en août 2026.

La majeure partie de ce trafic semble impliquer du contexte mis en cache. Ce contexte requiert toujours de la mémoire, du routage et une gestion rigoureuse, mais il ne doit pas être confondu avec une quantité équivalente de nouveau raisonnement.

Le passage à dix fois constitue une prévision, et non un résultat établi. Son importance dépendra de ce que ces tokens supplémentaires permettront d’accomplir.

Les développeurs devraient vérifier que chaque boucle possède un objectif, un budget et une condition d’arrêt clairs. Les acheteurs en entreprise devraient exiger des preuves au niveau des tâches avant de considérer la consommation comme une adoption.

La question utile n’est plus de savoir si les agents généreront davantage de trafic que les humains. Les données d’OpenRouter suggèrent qu’ils le font déjà. La question est de savoir si les mille milliards de tokens suivants accompliront davantage de travail, ou reliront simplement davantage le passé.