Comment empêcher les agents IA de gaspiller des tokens (Updated 2026)

Le « token killing » est généralement un problème de système

Lorsqu’un agent consomme beaucoup plus que prévu, le modèle n’est rarement que l’unique cause. Le système peut renvoyer toute la conversation à chaque tour, récupérer trop de preuves, exposer des outils verbeux, utiliser le raisonnement maximal pour des étapes simples, répéter des appels échoués ou coordonner plusieurs workers sans budget partagé. Réduire la réponse finale à trois phrases ne corrigera pas cette architecture.

Commencez par des preuves. Découpez une exécution coûteuse en étapes et attribuez les entrées, le cache, la sortie, le raisonnement, les appels d’outils, les tentatives, la latence et le résultat. Le plus grand message visible n’est pas forcément le principal coût. Les préfixes répétés, le raisonnement et les observations réinjectées peuvent dominer.

Cause un : tout rejouer

Un agent naïf accumule chaque message, plan, journal, document et résultat d’outil pour toujours. Chaque nouveau tour renvoie un historique croissant. Même avec une grande fenêtre, le coût et la latence augmentent, les anciennes instructions restent actives et les preuves dupliquées concurrencent la tâche actuelle.

Conservez un état de travail compact : objectif, contraintes actuelles, faits vérifiés, questions ouvertes, artefacts et prochaine action. Supprimez le brouillon terminé. Avec l’enchaînement des conversations Responses, suivez le modèle d’état documenté au lieu de dupliquer manuellement. Pour les processus longs, utilisez la compaction après des jalons significatifs.

La compaction réduit le contexte tout en transportant l’état utile dans un élément opaque. OpenAI propose la compaction serveur avec compact_threshold et une méthode autonome. Planifiez-la avant d’épuiser la fenêtre. Ne compactez pas à chaque tour : l’opération consomme elle-même et peut retirer des détails utiles sans jalon clair.

Cause deux : récupération incontrôlée

La recherche renvoie souvent ce qui correspond, pas ce dont la décision a besoin. Un agent demandant « tout sur ce client » peut recevoir des années d’emails, tickets, documents et événements CRM. Un agent de code peut charger un monorepo entier lorsque trois fichiers et une interface suffisent.

Récupérez par couches. Commencez avec métadonnées, titres, résumés, symboles ou résultats de recherche. Laissez l’agent demander des tranches précises lorsqu’une hypothèse l’exige. Limitez le nombre, la longueur, la période et les champs. Dédupliquez et gardez les identifiants de source afin de citer ou récupérer le détail sans renvoyer tout le contenu.

Mesurez la précision : la part du matériel retourné réellement utilisée dans la décision finale. Une faible précision est un problème de tokens et de qualité produit.

Cause trois : outils trop verbeux

Les outils conçus pour les humains renvoient souvent bannières, barres de progression, payloads complets, traces et centaines de lignes inchangées. Lorsque ce texte entre au tour suivant, il devient des tokens d’entrée. Une seule commande peut annuler les économies d’un prompt optimisé.

Ajoutez un mode compact aux outils d’agent. Retournez un état typé, les identifiants clés, des enregistrements bornés, un résumé et une adresse vers l’artefact complet. En cas d’échec, renvoyez la classe d’erreur, la cause probable, le caractère relançable et un court extrait. Paginer doit être intentionnel.

Pour le shell et les journaux, filtrez à la source. Demandez les tests échoués, les fichiers modifiés ou les dernières lignes pertinentes au lieu de tout afficher puis résumer.

Cause quatre : relances sans changement

La relance automatique aide lors d’un échec transitoire. Elle gaspille lorsque le même appel est répété avec les mêmes entrées après une erreur déterministe. Classez les erreurs : transitoire, permission, validation, entrée manquante ou inconnue. Donnez à chaque classe une politique.

Une relance doit modifier une variable pertinente ou attendre un état capable de changer. Un refus de permission demande une validation ou une configuration, pas cinq tentatives identiques. Une erreur de validation demande une entrée corrigée. Un contexte métier manquant demande une personne. Fixez des limites par outil et par erreur, ainsi qu’un maximum global.

Enregistrez la cause et le résultat de chaque relance. Un taux élevé peut révéler un mauvais contrat d’outil, une dépendance instable, un prompt ambigu ou un routage de modèle inadapté.

Cause cinq : raisonnement maximal partout

Un effort élevé peut améliorer les tâches difficiles, mais le routage, l’extraction, le formatage et les contrôles déterministes exigent rarement le maximum. Réglez l’effort par étape. Utilisez une configuration moins coûteuse pour la classification et les transformations simples, puis augmentez pour la synthèse ou le débogage lorsque les évaluations le justifient.

Ne déduisez pas la qualité de la consommation. Mesurez si l’effort supérieur améliore assez la réussite vérifiée pour compenser le coût et la latence. Si deux réglages passent les mêmes tests, choisissez le moins cher.

Cause six : éventail multi-agent

Les workers parallèles réduisent parfois le temps sur des problèmes indépendants, mais chacun peut recevoir le même préfixe, appeler les mêmes outils et renvoyer du contenu que le coordinateur doit lire. Quatre agents peuvent coûter plus de quatre fois un agent ciblé en incluant la coordination.

Déléguez seulement un travail séparable avec un livrable explicite. Donnez à chaque worker le contexte minimum, un budget et une frontière contre les doublons. Le coordinateur reçoit des conclusions concises et des liens de preuve, pas chaque transcription.

Comparez versions multi-agent et agent unique sur la réussite, les tokens, la latence et le temps de revue. Le parallélisme est un compromis, pas une preuve de sophistication.

Cause sept : aucune règle d’arrêt

Un agent sans définition de fini peut continuer à rechercher, améliorer, vérifier ou tester des variantes. Définissez la réussite comme une condition observable : tests réussis, destination contenant l’enregistrement attendu, sources requises citées ou écriture approuvée.

Définissez aussi les arrêts sans succès : appels, tentatives, plafond de tokens ou de dollars, échéance, état répété, permission manquante ou confiance insuffisante. Lorsque l’arrêt se déclenche, l’agent retourne le meilleur état vérifié, le blocage et la plus petite prochaine action.

Utilisez un détecteur de boucle basé sur les appels répétés, les résultats inchangés ou l’absence de progrès dans la métrique de vérification. « Ne pas s’arrêter » n’est pas une politique sûre sans autorité bornée et escalade.

Faire mériter sa place au cache

Le cache réduit coût et latence pour des préfixes identiques. Placez les instructions, schémas et outils stables au début et les variables ensuite. Suivez cached_tokens et, pour GPT-5.6 et versions ultérieures, cache_write_tokens. Un long prompt n’est pas efficace uniquement parce qu’une partie est en cache : le texte inutile complique toujours la tâche et l’écriture du cache a un coût.

Utilisez le cache pour du contenu stable dont de nombreuses exécutions ont besoin. Supprimez d’abord les règles dupliquées et les outils inutiles. Optimisez ensuite la stabilité et vérifiez que la réussite reste intacte.

Installer un budget d’exécution

Fixez un budget global et des budgets d’étape. Le global peut inclure entrées, sorties, raisonnement, outils, tentatives, durée et coût estimé. Les budgets d’étape empêchent une recherche initiale de consommer tout ce qui reste pour l’action et la vérification.

À chaque contrôle, estimez le travail restant. Si la tâche ne peut pas finir dans le budget, résumez l’état, réduisez le périmètre, demandez une extension ou arrêtez avec un blocage. Ne dépassez jamais silencieusement une limite annoncée.

Suivez p50, p90, p95 et maximum. Les moyennes cachent les exécutions incontrôlées. Alertez lorsque la distribution se déplace, que le ratio de cache chute ou que le coût par tâche acceptée augmente.

Une correction en trente minutes

Prenez une trace coûteuse. Retirez l’historique dupliqué et les anciennes sorties. Ajoutez des limites de lignes, octets et temps à l’outil le plus bruyant. Fixez les tentatives et un détecteur de boucle. Placez le contenu stable avant le contenu variable. Choisissez un raisonnement mesuré. Ajoutez un état compact après la plus grande phase terminée. Relancez la même tâche et comparez résultat, tokens, latence et revue.

Modifiez une chose à la fois pour savoir ce qui aide. L’objectif n’est pas le plus petit prompt, mais le plus petit système fiable qui termine avec des preuves.

Comment empêcher les agents IA de gaspiller des tokens