Comment Réduire les Coûts des Tokens d'Agent en Ligne de Commande (Guide 2026)

Un agent de codage CLI se sent libre jusqu'à ce que la facture arrive. Vous pointez Claude Code ou Codex vers un dépôt, lui demandez de refactoriser un module, et dix minutes plus tard, il a lu quarante fichiers, exécuté la suite de tests trois fois, et consommé des centaines de milliers de jetons sur un contexte que vous n'avez jamais eu besoin qu'il voie. Multipliez cela par une équipe de huit ingénieurs utilisant des agents toute la journée, et la facture cesse d'être une erreur d'arrondi. La consommation de jetons des agents de codage est principalement du gaspillage, et la majeure partie de ce gaspillage est réparable depuis la ligne de commande sans changer de modèles ni accepter une moins bonne qualité de sortie.

TL;DR

Réduisez les coûts de jetons des agents en limitant le contexte avant qu'il n'atteigne le modèle : délimitez l'ensemble de travail, gardez les fichiers de mémoire courts et compactez les longues sessions. Activez la mise en cache des invites pour les préfixes stables (environ 90 % de réduction sur les lectures répétées). Dirigez les sous-tâches bon marché vers un petit modèle. Limitez la sortie des outils. Mesurez le coût par exécution pour savoir ce qui a réellement changé.

Introduction

Le problème se manifeste de deux manières. Soit vous vous heurtez à une limite en cours de tâche parce que vous avez dépassé une limite hebdomadaire ou de session, soit la facture mensuelle d'API arrive et quelqu'un demande pourquoi un "assistant IA" coûte plus cher qu'un développeur junior. Les deux proviennent de la même cause profonde : les agents CLI sont gourmands en jetons par défaut. Ils lisent des fichiers entiers alors qu'ils n'ont besoin que de dix lignes, rejouent toute la conversation à chaque tour, déchargent la sortie brute des commandes dans le contexte et renvoient le même prompt système et la même carte de dépôt des milliers de fois par jour.

Rien de tout cela n'est inhérent au travail. Une refactorisation qui a réellement besoin de raisonner sur 2 000 jetons de code n'a pas besoin de 180 000 jetons de contexte pour y parvenir. L'écart entre ces deux nombres représente vos économies, et la quasi-totalité est récupérable avec des drapeaux, des fichiers de configuration et des habitudes que vous pouvez adopter dès aujourd'hui.

Ce guide explique où les jetons sont réellement dépensés lors de l'exécution d'un agent CLI, puis vous donne des tactiques concrètes pour réduire chaque catégorie : l'hygiène du contexte et les fichiers de mémoire, la mise en cache des invites, le routage des modèles, la réduction de la sortie des outils et de la récupération, et la mesure du coût par exécution afin que les économies soient réelles et non une supposition. Les exemples supposent Claude Code et Codex, mais les mécanismes s'appliquent à tout agent qui communique avec une API facturée par jetons.

Un coût connexe qu'il convient de mentionner dès le début : une grande partie des dépenses en jetons des agents est consacrée au débogage. Un agent qui appelle une API interne instable réessayera, lira les corps d'erreur, relira la documentation et bouclera, chaque itération payant le prix fort en jetons.

Où les jetons vont réellement lors de l'exécution d'un agent CLI

Avant d'optimiser, vous avez besoin d'un modèle mental de la facture. Un "tour" d'agent unique envoie une charge utile d'entrée au modèle et reçoit une charge utile de sortie en retour. Vous payez pour les deux, et chez la plupart des fournisseurs, la sortie coûte trois à six fois plus par jeton que l'entrée. Pour une famille de modèles de pointe à la mi-2026, l'entrée coûte environ 3 $ par million de jetons et la sortie environ 15 $ ; un modèle moins cher de la même famille est d'environ 1 $ pour l'entrée et 5 $ pour la sortie. Considérez ces chiffres comme illustratifs, pas comme des devis ; consultez les pages de tarifs en direct, car les fournisseurs les révisent. Le point structurel reste valable quels que soient les chiffres exacts : la sortie est chère, et le volume d'entrée est ce qui gonfle.

• Invite système et définitions d'outils. Les instructions de l'agent plus le schéma JSON de chaque outil. Fixé par tour, souvent de 5 000 à 15 000 jetons, renvoyé à chaque tour.
• Fichiers de mémoire et de projet. Des éléments comme CLAUDE.md, les conventions de dépôt et les instructions persistantes. Chargés à chaque tour, qu'ils soient pertinents ou non.
• Historique de conversation. Chaque message utilisateur précédent, réponse du modèle, appel d'outil et résultat d'outil, rejoué entièrement à chaque tour. Cela croît sans limite et est généralement le poste de dépense le plus important dans une longue session.
• Contenu de fichier récupéré. Fichiers lus par l'agent. Une seule lecture (`Read`) sur un fichier de 1 200 lignes représente environ 12 000 à 18 000 jetons, et les agents adorent lire des fichiers entiers.
• Sortie d'outil. Journaux de l'exécuteur de tests, bruit de npm install, git diff d'un fichier de verrouillage généré, traces de pile. Brut et verbeux par défaut.

La charge utile de sortie est le raisonnement du modèle, les modifications de code et les explications. Plus petite que l'entrée sur la plupart des exécutions, mais avec le prix le plus élevé par jeton, donc un comportement verbeux "laissez-moi vous expliquer mon plan en six paragraphes" est coûteux.

Le fait le plus important : l'historique de conversation est rejoué à chaque tour. Une session de 30 tours ne coûte pas 30 fois un tour. Elle est plus proche de la somme d'un préfixe croissant, de sorte que les tours ultérieurs portent chacun le poids total de tout ce qui les précède. C'est pourquoi une session longue et sinueuse est la chose la plus coûteuse que vous puissiez faire, et pourquoi les tactiques ci-dessous ciblent de manière disproportionnée le contexte qui est renvoyé.

Si vous souhaitez un aperçu plus approfondi du fonctionnement de la comptabilité des sessions et des limites en pratique, l'explication détaillée dans comment la fenêtre de jetons Claude Code se réinitialise est un complément utile à cette section ; elle explique pourquoi une session qui "semble courte" peut quand même épuiser un budget.

Hygiène du contexte et fichiers de mémoire

Le jeton le moins cher est celui que vous n'envoyez jamais. L'hygiène du contexte est l'habitude la plus impactante car elle réduit la charge utile d'entrée à chaque tour pour le reste de la session.

Délimitez l'ensemble de travail avant de commencer. N'ouvrez pas un agent à la racine du dépôt en disant "refactorise la logique de facturation". Il va explorer partout. Au lieu de cela, dites-lui exactement quels fichiers sont importants :

# Au lieu d'une invite vague qui déclenche une exploration étendue :
claude "refactor the retry logic so it uses exponential backoff,
only in src/payments/retry.ts and its test file"

Nommer les fichiers empêche l'agent de lire vingt candidats pour trouver les deux qui comptent. Si vous devez le laisser explorer, pointez-le vers un répertoire, pas vers la racine.

Gardez les fichiers de mémoire courts et stables. Un CLAUDE.md (ou fichier de mémoire de projet équivalent) est chargé dans le contexte à chaque tour. Les équipes le traitent comme un wiki et le laissent atteindre 4 000 jetons de prose d'intégration. À, disons, 50 tours par jour pour 8 ingénieurs, un fichier de mémoire surchargé est renvoyé des centaines de fois par jour sans aucun bénéfice marginal. Auditez-le :

# Vérification approximative des jetons sur votre fichier de mémoire (caractères / 4 est une estimation décente) :
wc -c CLAUDE.md | awk '{print "≈", int($1/4), "tokens per turn"}'

Visez un fichier concis : commandes de build/test, conventions strictes et pointeurs vers l'emplacement de la documentation plus détaillée, et non la documentation elle-même. Si une section n'est pertinente que pour une tâche par mois, elle n'a pas sa place dans le fichier toujours chargé. Déplacez-la vers un document que l'agent lit à la demande.

Compactez ou réinitialisez les longues sessions. Lorsqu'une session a rempli son rôle et que vous passez à une tâche sans rapport, ne continuez pas à taper dans le même contexte. Chaque nouveau tour entraîne désormais la totalité de l'ancienne transcription. Utilisez la commande de compaction ou de nettoyage de l'agent :

# Dans Claude Code, lorsque la conversation devient longue :
/compact     # résume l'historique en un court aperçu, supprime la transcription brute
# ou, pour une rupture nette sur une nouvelle tâche :
/clear       # commence à zéro ; l'ancien contexte n'est plus renvoyé

/compact remplace généralement des dizaines de milliers de jetons d'historique brut par un résumé d'un dixième de la taille, et ce préfixe plus petit est ensuite ce que chaque tour ultérieur transporte. La discipline est simple : une tâche logique par session, compactez ou nettoyez entre les tâches. Les modèles de flux de travail dans les flux de travail de Claude Code s'appuient fortement sur cette habitude de délimitation, et il vaut la peine de l'adopter entièrement.

Utilisez un fichier d'ignorance de projet. Gardez les artefacts générés, les fichiers de verrouillage, la sortie de build et les dépendances tierces hors de portée de l'agent. Si l'agent ne voit jamais `dist/` ou `node_modules/`, il ne dépense jamais de jetons à les lire ou à les comparer. La plupart des agents respectent un fichier d'ignorance ; configurez-le une fois et les économies sont permanentes.

Mise en cache des invites : arrêtez de payer le prix fort pour le même préfixe

C'est le levier le plus important pour les exécutions répétées, et il est mécanique plutôt que comportemental. La mise en cache des invites permet au fournisseur de stocker un préfixe de votre requête (outils, invite système, contexte stable) afin que les requêtes ultérieures qui partagent ce préfixe le relisent avec une réduction importante au lieu de le retraiter.

L'économie, selon la documentation d'Anthropic sur la mise en cache des invites : une écriture en cache coûte plus cher qu'un jeton d'entrée normal (environ 1,25 fois l'entrée de base pour le cache par défaut de 5 minutes, environ 2 fois pour un cache d'une heure), mais une lecture en cache coûte environ 0,1 fois l'entrée de base ; cela représente une réduction d'environ 90 % sur la partie mise en cache. Parce que la prime d'écriture est faible et la réduction de lecture est importante, la mise en cache est rentabilisée après un seul accès au cache de courte durée, et après environ deux accès à celui de longue durée. La durée de vie du cache par défaut est courte (environ 5 minutes, rafraîchie à chaque fois qu'il est accédé), avec une option d'une heure disponible. Il y a une taille minimale de mise en cache ; les petits modèles et les plus grands modèles ont besoin de quelques milliers de jetons avant qu'un préfixe ne soit éligible, donc la mise en cache est la plus utile là où cela compte le plus : les grands préfixes stables.

La règle structurelle est de placer le contenu stable en premier et le contenu volatile en dernier, puis de mettre en cache la frontière. L'ordre est `outils → système → messages`, et modifier quoi que ce soit invalide ce niveau et tout ce qui suit. Vous voulez donc que les horodatages, le message entrant de l'utilisateur et le contenu de fichier fraîchement récupéré viennent après votre point d'arrêt de cache, et non avant.

Si vous pilotez un modèle directement depuis votre propre wrapper CLI, vous le définissez explicitement :

# Mettre en cache le préfixe stable (système + définitions d'outils + conventions de dépôt).
# Le tour utilisateur volatile vient après et NE fait PAS partie du préfixe mis en cache.
response = client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=2048,
    system=[
        {
            "type": "text",
            "text": SYSTEM_PROMPT + REPO_CONVENTIONS,   # stable à travers les exécutions
            "cache_control": {"type": "ephemeral"},       # point d'arrêt du cache ici
        }
    ],
    messages=[{"role": "user", "content": user_task}],     # change à chaque exécution
)

# Inspecter ce qui a été réellement mis en cache :
u = response.usage
print("cache write:", u.cache_creation_input_tokens)
print("cache read :", u.cache_read_input_tokens)   # ces jetons facturés ~10%
print("fresh input:", u.input_tokens)

Un agent de refactorisation quotidien qui exécute la même invite système et le même bloc de conventions de dépôt de 8 000 jetons sur 60 invocations par jour est le cas d'école. Sans mise en cache, vous payez le prix plein de l'entrée pour ce bloc de 8 000 jetons 60 fois. Avec la mise en cache, vous payez la prime d'écriture une fois (ou une fois par expiration de cache) et le prix de lecture d'environ 10 % les autres fois. Sur le seul bloc de conventions, cela représente près de 90 % de réduction, et cela s'ajoute à toutes les autres tactiques présentées ici.

Deux notes opérationnelles. Premièrement, gardez votre préfixe stable en octets ; un seul caractère modifié avant le point d'arrêt invalide le cache et vous payez une nouvelle écriture. Fixez votre invite système et vos conventions ; n'y insérez pas d'horodatage. Deuxièmement, le cache est de courte durée par défaut, donc regrouper les exécutions connexes (plutôt que de les étaler sur la journée) vous permet de toujours utiliser un cache chaud. L'API d'OpenAI applique automatiquement une réduction similaire aux entrées mises en cache sur les modèles pris en charge ; le principe est identique même si les mécanismes diffèrent. Les astuces de niveau gratuit et de routage dans l'exécution gratuite de GPT-5.5 via Codex sont un complément utile lorsque la mise en cache seule ne suffit pas.

Routage des modèles : modèle économique pour travail économique

Toutes les actions d'agent n'ont pas besoin d'un modèle de pointe. Renommer une variable dans trois fichiers, écrire un message de commit, résumer un diff ou générer un test générique ne nécessite pas le même modèle qui conçoit une architecture. Pourtant, le comportement par défaut de la plupart des agents CLI est de tout faire passer par un modèle coûteux pour toute la session.

Le routage consiste à envoyer délibérément les sous-tâches à faible enjeu à un modèle plus petit et moins cher, et à réserver le modèle coûteux pour un raisonnement authentique. L'écart de prix est important : un petit modèle d'une famille donnée peut être trois à cinq fois moins cher par jeton que le modèle phare, et pour les tâches mécaniques, la différence de qualité de sortie est négligeable.

Moyens pratiques de router depuis la CLI :

# 1. Choisissez le modèle par invocation en fonction de la tâche.
claude --model haiku   "write a conventional-commit message for the staged diff"
claude --model sonnet  "redesign the caching layer for the payments service"

# 2. Utilisez un modèle économique pour la boucle à haute fréquence et à faible enjeu
#    (messages de commit, entrées de changelog, explications rapides de lint)
#    et un modèle puissant uniquement lorsque vous invoquez explicitement la tâche difficile.

Définissez le modèle par défaut comme étant le moins cher et montez en gamme consciemment, plutôt que de vous baser sur le modèle coûteux et de ne jamais redescendre. La plupart des équipes ont la polarité inverse : elles utilisent le modèle phare pour tout "par sécurité" et paient cinq fois plus pour les messages de commit.

Un deuxième axe de routage est celui des sous-agents. Si votre framework d'agent prend en charge la délégation d'une sous-tâche étroite à un agent enfant, donnez à cet enfant un modèle économique et un contexte minuscule. L'enfant fait le gros du travail (recherche, résumé, brouillon) pour une bouchée de pain et renvoie un court résultat au parent coûteux, au lieu que le parent coûteux fasse le gros du travail lui-même au prix fort et avec un contexte complet. Les modèles de boucle autonome dans la commande "goal" entre Codex et Claude Code montrent comment structurer cette délégation afin que le modèle coûteux ne voie que les résultats distillés.

Une note sur les limites, pas seulement les dollars. Si vous avez un forfait avec un plafond d'utilisation plutôt qu'un pur paiement à l'usage, le routage étend également la portée de votre allocation. Dépenser votre budget de modèle premium pour des messages de commit est la façon dont les équipes se retrouvent bloquées le jeudi. L'augmentation récente de la limite hebdomadaire de Claude Code aide, mais le routage reste ce qui permet de faire durer l'allocation.

Réduction de la sortie et de la récupération des outils

La sortie d'outil est le tueur de budget silencieux car elle est invisible jusqu'à ce que vous la regardiez. Chaque commande exécutée par un agent renvoie du texte, et ce texte est directement réinjecté dans le contexte, où il est ensuite rejoué à chaque tour suivant. Un simple `npm install` peut renvoyer des milliers de lignes. Une exécution de test avec une journalisation verbeuse peut renvoyer des dizaines de milliers de jetons. Un `git diff` qui inclut un fichier de verrouillage régénéré peut être énorme. L'agent a rarement besoin de tout cela ; il a besoin du succès/échec et de l'échec pertinent.

Tactiques qui réduisent cela proprement :

Rendez les commandes silencieuses à la source. L'agent paie pour tout ce que la commande affiche. Configurez les outils pour être concis :

# Bruyant (l'agent paie pour chaque ligne) :
npm test

# Silencieux (seuls les échecs et un résumé sont renvoyés) :
npm test --silent -- --reporter=dot

# Bruyant :
npm install

# Silencieux :
npm install --silent --no-audit --no-fund

Filtrez avant que l'agent ne le voie. Lorsque vous contrôlez la commande exécutée par l'agent, redirigez le bruit pour que seul le signal soit renvoyé :

# Seules les lignes importantes sont réinjectées dans le contexte :
pytest -q 2>&1 | tail -n 30

# Statistiques de diff au lieu d'un diff complet de 4 000 lignes :
git diff --stat

# Grepper l'échec au lieu de vider tout le journal :
npm test 2>&1 | grep -E "(FAIL|✗|Error)" | head -n 20

Préférez les lectures ciblées aux lectures de fichiers entiers. Lire un fichier de 1 500 lignes pour modifier une seule fonction est un pur gaspillage. Encouragez l'agent à rechercher le symbole et à lire une fenêtre autour de celui-ci, et non le fichier entier. De nombreux agents le font lorsque l'invite les y pousse ("trouve et lis uniquement la fonction qui gère les réessais, pas le fichier entier"). Sur un grand fichier, c'est la différence entre environ 18 000 jetons et environ 800.

Restreignez le champ de récupération. Si votre agent effectue une recherche de codebase ou un RAG sur des documents, limitez le nombre de morceaux qu'il récupère et leur taille. Dix extraits de 200 jetons qui répondent à la question sont meilleurs que cinquante extraits de 800 jetons qui l'enterrent ; vous payez pour chaque jeton récupéré, que le modèle l'utilise ou non.

Ces changements sont principalement une configuration unique (rapporteurs de tests, drapeaux d'installation, un fichier d'ignorance) et ils rapportent à chaque exécution indéfiniment, ce qui en fait certains des meilleurs retours sur effort de toute cette liste.

Mesurer et attribuer le coût par exécution

Vous ne pouvez pas gérer ce que vous ne mesurez pas, et "la facture a baissé" n'est pas une mesure. Pour savoir si une tactique a fonctionné, vous avez besoin que le coût soit attribué à une exécution, idéalement à une tâche.

Commencez avec les données que l'API vous fournit déjà. Chaque réponse inclut un objet d'utilisation. Capturez-le :

u = response.usage
# Coût approximatif en dollars ; substituez les tarifs en direct pour votre modèle.
INPUT_RATE  = 3.00 / 1_000_000     # entrée de base $/jeton (illustratif)
OUTPUT_RATE = 15.00 / 1_000_000    # sortie $/jeton (illustratif)
CACHE_READ  = 0.30 / 1_000_000     # ~10% de l'entrée de base
CACHE_WRITE = 3.75 / 1_000_000     # ~1,25x l'entrée de base (cache de 5 min)

cost = (
    u.input_tokens          * INPUT_RATE  +
    u.output_tokens         * OUTPUT_RATE +
    u.cache_read_input_tokens  * CACHE_READ +
    u.cache_creation_input_tokens * CACHE_WRITE
)
print(f"coût d'exécution ≈ ${cost:.4f}  "
      f"(in={u.input_tokens} out={u.output_tokens} "
      f"lr={u.cache_read_input_tokens})")

Si vous utilisez la CLI de l'agent plutôt que votre propre wrapper, trois approches fonctionnent :

# 1. La plupart des CLI d'agent exposent une commande d'utilisation/coût pour la session.
#    Vérifiez-la après une tâche représentative et notez le chiffre.
claude /cost

# 2. Les consoles des fournisseurs rapportent les dépenses par clé API. Émettez une clé API dédiée
#    par agent ou par projet afin que les dépenses soient attribuables
#    au lieu d'être regroupées dans un total intraçable.

# 3. Étiquetez les exécutions. Enveloppez l'invocation de l'agent dans un script qui enregistre
#    l'horodatage, l'étiquette de tâche et les nombres de jetons rapportés dans un fichier CSV.
#    Une semaine de ce CSV vous indique quelles tâches sont coûteuses.

Estimez avant d'exécuter quoi que ce soit de grand. Collez l'invite et les fichiers que vous comptez inclure dans un tokeniseur (le tokeniseur public d'OpenAI est un moyen rapide de vérifier la taille) et regardez le décompte. Si "inclure tout le module" représente 90 000 jetons et que la version ciblée en est à 6 000, vous avez vu la décision avant de la payer.

Suivez un chiffre par tâche représentative au fil du temps : coût par "exécution de refactorisation quotidienne", coût par "exécution de révision de PR". Lorsque vous activez la mise en cache ou basculez une sous-tâche vers un modèle économique, ce chiffre devrait bouger. Si ce n'est pas le cas, la tactique ne fait pas ce que vous pensez, et vous l'avez appris pour le prix d'une exécution au lieu d'un mois de factures.

Comparaison des tactiques

Les plages d'économies sont illustratives et s'empilent multiplicativement ; le gain de chaque tactique dépend de votre gaspillage de référence.

Conclusion

Les coûts en jetons des agents sont principalement auto-infligés, et la ligne de commande est l'endroit où vous les corrigez. Le gaspillage réside dans le contexte que vous renvoyez, la sortie que vous ne lisez pas et les modèles trop chers pour la tâche en cours. Adressez-vous à ces problèmes et la facture diminuera sans affecter la qualité du travail.

Commencez par les éléments à faible effort ; la délimitation, la sortie silencieuse et un fichier de mémoire allégé ne coûtent rien et rapportent à chaque exécution à partir de maintenant. Ajoutez la mise en cache et le routage par-dessus et la différence est du genre que vous pouvez inclure dans un budget.