L'auteur a découvert après avoir analysé une charge de travail OpenClaw que 79 % de la consommation de tokens provient de la lecture répétée des préfixes en cache (cached prefix replay), et non des entrées des utilisateurs ou des sorties du modèle. Il a proposé trois grandes stratégies d'optimisation contextuelle pour réduire efficacement les coûts opérationnels de l'agent IA. Cet article est basé sur un texte écrit par MOSHIII (Pourquoi mes sessions OpenClaw ont consommé 21,5 millions de tokens en une journée (et ce qui a réellement corrigé le problème)), édité et traduit par Dongqu. (Résumé : MEXC se classe parmi les trois premières CEX mondiales, approfondissant son déploiement sur les marchés au comptant et des marchandises) (Contexte supplémentaire : En période de marché baissier, les stablecoins rapportent des intérêts : comparaison des taux d'intérêt sur différentes plateformes OSL 18%, MEXC 15%, Binance 8%…) J'ai analysé une charge de travail OpenClaw réelle et découvert un modèle que je pense que de nombreux utilisateurs d'agents reconnaîtront : la consommation de tokens semble très "active" Les réponses semblent également normales mais la consommation de tokens explose soudainement. Voici l'analyse de cette fois : décomposition structurelle, causes profondes et chemins de correction pratiques. Principal moteur de coûts : lecture répétée des préfixes en cache. Le principal moteur de coûts n'est pas que les messages des utilisateurs soient trop longs. Mais c'est la lecture répétée d'un énorme préfixe en cache. D'après les données de la session : Total tokens : 21 543 714 cacheRead : 17 105 970 (79,40%) input : 4 345 264 (20,17%) output : 92 480 (0,43%) En d'autres termes : la majorité des coûts des appels ne proviennent pas du traitement de nouvelles intentions des utilisateurs, mais de la lecture répétée d'un énorme contexte historique. Je pensais à l'origine que la forte consommation de tokens provenait : d'un prompt utilisateur très long, d'une génération de sortie massive ou d'appels d'outils coûteux. Mais le modèle dominant est : input : de quelques centaines à quelques milliers de tokens cacheRead : chaque appel 170 000 à 180 000 tokens Cela signifie que le modèle lit à chaque tour le même énorme préfixe stable. Décomposition des données de session. J'ai analysé les données à deux niveaux : 1. Journaux d'exécution (runtime logs) 2. Transcriptions de session (session transcripts) Il est à noter que : Les journaux d'exécution sont principalement utilisés pour observer les signaux de comportement (comme les redémarrages, les erreurs, les problèmes de configuration) Les statistiques précises des tokens proviennent du champ usage dans le JSONL de la session Les scripts utilisés : scripts/session_token_breakdown.py scripts/session_duplicate_waste_analysis.py Fichiers d'analyse générés : tmp/session_token_stats_v2.txt tmp/session_token_stats_v2.json tmp/session_duplicate_waste.txt tmp/session_duplicate_waste.json tmp/session_duplicate_waste.png Il y a une session dont la consommation est bien supérieure aux autres : 570587c3-dc42-47e4-9dd4-985c2a50af86 : 19 204 645 tokens puis une chute évidente : ef42abbb-d8a1-48d8-9924-2f869dea6d4a : 1 505 038 ea880b13-f97f-4d45-ba8c-a236cf6f2bb5 : 649 584 tokens principalement issus de : toolUse : 16 372 294 stop : 5 171 420 indiquant que le problème provient principalement des boucles d'appels d'outils, et non des conversations ordinaires. D'où viennent les pics de tokens ? Les pics de tokens ne sont pas aléatoires, mais concentrés sur quelques courtes périodes : 2026-03-08 16:00 : 4 105 105 2026-03-08 09:00 : 4 036 070 2026-03-08 07:00 : 2 793 648 Ce ne sont pas les contenus de dialogue, mais principalement de gros produits intermédiaires : de gros blocs de données toolResult de longues traces de raisonnement / réflexion de gros instantanés JSON Liste de fichiers Données extraites du navigateur Journal des dialogues des sous-agents Dans la session maximale, le nombre de caractères est d'environ : toolResult:text : 366 469 caractères assistant:thinking : 331 494 caractères assistant:toolCall : 53 039 caractères Une fois que ces contenus sont conservés dans le contexte historique, chaque appel suivant peut les lire à nouveau via le préfixe en cache. Des blocs de contexte énormes se répètent aux endroits suivants : sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:70 Journal JSON de gros portails (environ 37 000 caractères) sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:134 Instantané du navigateur + enveloppe de sécurité (environ 29 000 caractères) sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:219 Sortie de la liste de fichiers énorme (environ 41 000 caractères) sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:311 instantané de l'état de session/status + structure de prompt massive (environ 30 000 caractères) J'ai également mesuré le ratio de répétition du contenu au sein d'un appel unique : Ratio de répétition d'environ : 1,72% Il existe effectivement, mais ce n'est pas le problème principal. Le véritable problème est : la taille absolue du préfixe en cache est trop grande. La structure est : un énorme contexte historique, une lecture répétée à chaque appel, avec seulement peu de nouvelles entrées ajoutées. Ainsi, l'optimisation ne doit pas porter sur la dé-duplication, mais sur la conception de la structure contextuelle. Les trois mécanismes d'expansion du contexte Trois mécanismes s'additionnent : 1. Une grande quantité de sorties d'outils est écrite dans le contexte historique 2. Les boucles d'outils produisent un grand nombre d'appels à court intervalle 3. Les variations de préfixe sont très faibles → le cache est relu à chaque fois Si la compaction du contexte n'est pas déclenchée de manière stable, le problème s'aggravera rapidement. Stratégies d'optimisation en pratique Pour des sorties d'outils très grandes : · Conserver des résumés ...