Économiser les tokens comme un problème de transport

Il faut compter toute la trajectoire de l’agent

Je ne compterais pas les tokens d’une seule requête, mais le coût attendu de toute la trajectoire de l’agent. Dans la discussion initiale, l’utilisateur 1497575255 a comparé la minimisation des tokens à un problème de transport : le résultat doit aller du point A au point B avec une consommation minimale de ressources. C’est plus juste que le classique « raccourcissons le prompt ».

Pour chaque étape, le coût des entrées et sorties est connu ou estimé. L’entrée comprend l’instruction, l’historique, les schémas d’outils et les documents retrouvés. La sortie dépend du type de tâche, du modèle choisi, du budget de génération et d’un éventuel nouvel appel.

Au niveau du pipeline, les variables se multiplient :

• quel modèle confier au planificateur, à l’exécutant et au vérificateur ;
• quels fragments de contexte conserver ou compresser ;
• combien d’itérations et de tentatives autoriser ;
• quand appeler un outil et quand arrêter une branche.

La fonction objectif ne minimise alors pas seulement le nombre de tokens, mais le coût total sous contraintes de qualité, de latence et de fiabilité. Affecter une tâche à l’un de plusieurs modèles devient un problème de choix entier. Si le flux de requêtes est réparti entre modèles, configurations ou régions, l’analogie avec le transport devient presque littérale.

Le choix du contexte constitue aussi un sous-problème distinct. Chaque fragment a une taille et une utilité attendue, tandis que la fenêtre totale est limitée par un budget. Sa structure évoque un problème de sac à dos, relié au routage des modèles dans un même schéma d’optimisation.

La longueur exacte de l’entrée peut généralement être calculée avant l’envoi. Pour la sortie, c’est plus complexe : il faut une prévision par classe de tâche et par modèle, tout en tenant compte de la probabilité d’étapes supplémentaires. Au 6 novembre 2026, il ne s’agit pas d’une annonce de produit, mais d’une formulation d’ingénierie utile.

L’économie ne commence pas par le modèle le moins cher

Le principal gain vient de la gestion des décisions de l’agent, non du remplacement mécanique d’un modèle puissant par un modèle plus faible. Un appel coûteux peut être plus rentable s’il évite plusieurs répétitions, une recherche inutile ou une longue branche de raisonnement.

Une architecture pratique comporte deux parties. Un prédicteur estime les tokens, la qualité, la latence et le risque des actions possibles. Un contrôleur choisit l’option la moins coûteuse qui respecte les contraintes, puis recalcule après chaque étape selon le budget restant.

La faiblesse est évidente : une erreur de prévision de qualité peut coûter davantage que les tokens économisés. Je surveillerais donc surtout les appels répétés, l’historique qui enfle et la transmission des résultats complets d’outils. C’est là que les pipelines agentiques brûlent souvent leur budget sans bruit.

Dans ce système, les tokens ne sont plus un simple compteur après exécution, mais une ressource de planification. Une question demeure : dans quelle mesure le routeur peut-il prévoir le coût d’une erreur avant qu’un chemin bon marché ne devienne un coûteux détour ?

Nous avons auparavant analysé l’impact des configurations de Claude Opus 4.6, du raisonnement étendu et de la longueur du contexte sur le coût des requêtes. Cela complète l’idée que l’optimisation des tokens consiste à répartir un budget limité entre les parties du contexte.