Mon premier mois à faire tourner des agents à un volume réel, j'ai brûlé 1 400 dollars et la majorité c'était du gaspillage. Pas le modèle qui réfléchit intensément à des problèmes difficiles — ça, c'est de l'argent bien dépensé. Non, c'était le renvoi du même prompt système de 40 000 tokens sans cache à chaque requête, l'exécution de tout à effort maximal, et l'utilisation d'Opus pour faire des grep de fichiers. De la pure fuite.
L'objectif n'est pas de rendre votre agent moins cher en le rendant plus bête. N'importe qui peut passer à un modèle plus petit et appeler ça du contrôle des coûts. L'objectif est d'éliminer le gaspillage tout en conservant l'intelligence là où elle compte. Voici où l'argent part vraiment et comment colmater chaque fuite.
Le cache de prompts est le levier le plus puissant
Si vous faites tourner un agent avec un prompt système stable et volumineux et que votre cache_read_input_tokens est à zéro, vous brûlez de l'argent. Le cache fonctionne par correspondance de préfixe — l'API met en cache le prompt rendu jusqu'à un point de rupture, et les lectures coûtent environ un dixième du prix d'entrée normal.
Le piège : tout changement d'octet n'importe où dans le préfixe invalide tout ce qui suit. Le classique qui tue le cache, c'est un horodatage dans le prompt système.
system = f"You are an agent. Current time: {datetime.now()}" # cache dead on arrival
Ce datetime.now() fait de chaque requête un préfixe unique. Rien ne se met jamais en cache. Déplacez les éléments volatils — horodatages, identifiants de requête, la question réelle — à la fin, après votre dernier point de rupture de cache. Gardez le prompt système et la liste d'outils figés et identiques octet par octet.
Comment savoir si ça fonctionne : vérifiez usage.cache_read_input_tokens sur des requêtes répétées. Si c'est un grand nombre, vous êtes en train de mettre en cache. Si c'est zéro, comparez deux prompts rendus et trouvez l'octet qui change. C'est toujours quelque chose de stupide — un dump JSON non trié, un UUID, une date. Sur une longue session d'agent, c'est la différence entre une exécution à 4 dollars et une à 0,40 dollar, et ça ne change rien à la qualité de sortie. De l'argent gratuit.
Régler l'effort par route, ne pas tout mettre au maximum
Le paramètre effort contrôle l'intensité de réflexion du modèle. L'instinct est de le monter à max partout pour que l'agent soit le plus intelligent possible. Mauvais instinct. Sur les modèles Opus actuels, high est le point optimal pour la plupart des tâches, et max brûle souvent des tokens supplémentaires sur de la surréflexion avec des rendements décroissants.
Et surtout : toutes les étapes d'une boucle d'agent n'ont pas besoin de la même puissance cérébrale. Une étape de classification, une décision « quel fichier regarder », une porte oui/non — ces étapes fonctionnent très bien à low ou medium. Réservez high et xhigh pour le vrai raisonnement difficile et la planification à long horizon.
# cheap gate
client.messages.create(model="claude-opus-4-8", output_config={"effort": "low"}, ...)
# the real work
client.messages.create(model="claude-opus-4-8", output_config={"effort": "high"}, ...)
J'ai effectué un balayage d'effort sur mon propre ensemble d'évaluation — medium, high, xhigh — et j'ai constaté que high correspondait à xhigh en qualité pour la plupart de mes routes avec une dépense en tokens nettement inférieure. Vous ne connaîtrez vos chiffres qu'en les mesurant. Ne mettez pas tout au maximum par peur.
Des sous-agents pour le travail bon marché
Voici une astuce qui est à la fois un levier de coût et un levier de cache. Quand vous avez besoin d'effectuer une sous-tâche peu coûteuse — explorer un répertoire, résumer un fichier, faire un grep — ne le faites pas en ligne dans votre boucle principale coûteuse. Lancez un sous-agent sur un modèle moins cher.
Pourquoi c'est aussi un avantage pour le cache : changer de modèle en cours de conversation invalide votre cache, car les caches sont liés au modèle. Si vous passez votre boucle principale d'Opus à Haiku pour un grep puis revenez, vous avez détruit votre cache de préfixe deux fois. Un sous-agent garde la boucle principale sur un modèle et un cache, tandis que le travail bon marché se passe sur le côté avec Haiku. Claude Code fait exactement ça — ses sous-agents d'exploration tournent sur Haiku précisément pour cette raison.
Édition du contexte et compaction pour les longues exécutions
Les longues sessions d'agent accumulent des résultats d'outils périmés et d'anciens blocs de réflexion. À chaque tour vous les renvoyez tous au prix d'entrée plein. Deux outils corrigent ça.
L'édition du contexte supprime les anciens résultats d'outils de la transcription avant que le modèle ne les voie. La compaction résume l'historique côté serveur quand vous approchez de la limite de fenêtre. Ce sont deux choses différentes — l'édition élague, la compaction condense — et les agents longs utilisent souvent les deux. Les économies se cumulent : une session de 40 tours qui renverrait 200 000 tokens de résultats d'outils morts à chaque tour envoie à la place un résumé condensé.
Un écueil qui piège tout le monde avec la compaction : ajoutez le response.content complet à chaque tour, pas seulement le texte extrait. L'état de compaction vit dans ces blocs de contenu. Extrayez seulement le texte et vous le perdez silencieusement, et vos coûts remontent pendant que vous vous demandez pourquoi.
Surveiller le bon chiffre
Dernière chose. Quand vous déboguez les coûts, ne regardez pas input_tokens seul. Le total réel est input_tokens + cache_creation_input_tokens + cache_read_input_tokens. J'ai vu des gens paniquer parce qu'un agent de longue durée n'affiche que 4 000 input_tokens et supposer que quelque chose est cassé — non, le reste a été servi depuis le cache. Ces 4 000 représentent le reste non mis en cache. Additionnez les trois ou vous lisez le compteur de travers.
Rien de tout ça ne rend votre agent plus bête. Le cache est gratuit. Le réglage de l'effort conserve la puissance cérébrale là où elle compte. Les sous-agents placent le travail bon marché sur des modèles bon marché. La décision stupide, c'est celle qui semble intelligente : passer à un modèle plus faible partout et regarder la qualité s'effondrer pour économiser quelques euros. Éliminez le gaspillage d'abord. Le gaspillage est énorme, et il se cache dans un horodatage que vous avez oublié.