La plupart des conseils sur la consommation de tokens optimisent le mauvais bout du problème. Le prompt que vous tapez est rarement ce qui coûte cher. Ce qui consomme des tokens, c’est tout ce que l’agent lit pour vous : le contenu des fichiers, la sortie des commandes, les journaux de tests et la transcription toujours plus longue de ses propres tours précédents.
Les techniques ci-dessous sont classées selon ce qu’elles économisent en pratique, et non selon leur ingéniosité.
Lire moins de chaque fichier
Un agent qui ouvre un fichier de 2 000 lignes pour modifier une seule fonction a dépensé l’essentiel de son budget en contexte qu’il ne réutilisera jamais. Cherchez d’abord, puis n’ouvrez que la plage nécessaire.
L’économie se cumule, car chaque fichier lu par l’agent reste dans la transcription jusqu’à la fin de la session. Un fichier lu une fois n’est pas payé une seule fois : celui lu au troisième tour est encore transporté au vingtième.
Filtrer la sortie des commandes avant qu’elle n’atteigne le modèle
Les journaux de build, les lanceurs de tests et les gestionnaires de paquets sont écrits pour des personnes qui regardent un terminal, pas pour un modèle facturé au token. Une suite de tests en échec produit sans peine plusieurs milliers de tokens de traces d’appels là où quarante suffiraient.
Faites passer les commandes bruyantes par quelque chose qui en extrait le signal :
pytest -q 2>&1 | tail -30
npm run build 2>&1 | grep -E "error|warning" | head -20
C’est peu spectaculaire, et c’est généralement la plus grande économie disponible à elle seule.
Garder la tâche circonscrite
Une longue conversation coûte plus cher par tour qu’une courte, puisque toute la transcription est renvoyée à chaque fois. Deux sessions ciblées reviennent moins cher qu’une seule session tentaculaire couvrant le même terrain, et donnent d’ordinaire de meilleurs résultats, car le modèle ne pèse pas vingt tours d’historique sans rapport.
Quand une tâche change nettement de direction, repartir de zéro est autant une décision de coût qu’une décision de qualité.
Ne pas coller ce que l’agent peut lire
Coller un fichier dans le prompt le compte deux fois : une fois dans votre message, et une autre quand l’agent ouvre ce fichier pour le modifier. Indiquez plutôt le chemin.
Ce qui n’aide pas beaucoup
Raccourcir vos propres prompts relève surtout de la mise en scène. Une instruction soigneusement compressée économise peut-être cinquante tokens ; une seule lecture de fichier inutile en coûte deux mille. Écrivez l’instruction la plus claire possible et portez votre attention sur ce que l’agent lit, non sur ce que vous écrivez.
Compresser le prompt système ou les définitions d’outils rapporte tout aussi peu à la plupart des utilisateurs, et échange de la fiabilité contre une économie négligeable face à une exécution de tests bavarde.