Pourquoi votre agent IA ne cesse de brûler des jetons

Imaginez un correctif de bug qui modifie 12 lignes. L’agent lit le projet, rédige un plan, lance un assistant, exécute les tests, examine les échecs et réessaie avant de produire ce correctif.
La facture comprend chaque requête qui a permis d’y parvenir.
Cela rend étonnamment facile de trop payer pour une tâche courte. Une longue conversation peut entraîner d’anciens fichiers dans les requêtes suivantes. Un outil peut renvoyer des pages de données alors que la décision suivante ne nécessite qu’un seul enregistrement. Plusieurs agents peuvent répéter la même enquête.
Vous pouvez repérer ces coûts dans l’historique d’exécution. Commencez par une tâche, suivez tout ce qu’elle consomme et vérifiez si le résultat est réellement concluant. Ensuite, modifiez la partie qui effectue du travail inutile.
1. Attribuez un coût à une tâche terminée
Choisissez une tâche que vous répétez : corriger un bug signalé, préparer une synthèse de recherche ou vérifier un lot de dossiers clients. Définissez les critères de réussite avant de l’exécuter.
Pour corriger un bug, les critères d’acceptation peuvent exiger un test qui reproduit l’échec initial, un résultat concluant après la modification et l’absence d’échec dans les tests d’intégration concernés. Un message affirmant que le bug est corrigé ne suffit pas.
Attribuez un ID à la tâche. Conservez cet ID lors des nouvelles tentatives, des interventions des assistants, de la vérification et de l’obtention du résultat final. Enregistrez un ID de requête distinct pour chaque appel au modèle afin de repérer les doublons dans vos journaux.
Le calcul de base est le suivant :
Coût par tâche acceptée = dépenses totales enregistrées / nombre de tâches acceptées
Incluez les tentatives échouées. Si 10 tâches coûtent 8 $ au total et que seules 4 réussissent, le coût est de 2 $ par tâche acceptée. Indiquez également le taux d’acceptation de 40 %. Si aucune tâche ne réussit, indiquez les dépenses et le nombre zéro de tâches acceptées ; le ratio n’est pas défini.
Suivez séparément le temps consacré aux corrections humaines. Un flux de travail qui économise 1 $ de frais d’API, mais nécessite 20 minutes de nettoyage, présente un compromis qu’il est utile de connaître.
Pour les appels API, enregistrez la réponse d’utilisation du fournisseur, l’ID du modèle, la date des tarifs, les frais des outils, le résultat de la tâche et les horodatages. Si les données d’utilisation manquent après un délai d’attente dépassé, indiquez que le coût est inconnu et vérifiez-le à l’aide des relevés du fournisseur. L’absence de réponse ne signifie pas que la requête était gratuite. Si le prix d’une requête reste inconnu, indiquez que le total du lot est incomplet.
Les utilisateurs de Claude Code peuvent commencer par /usage et /context. La première commande aide à examiner l’utilisation ; la seconde montre ce qui occupe la conversation. Avec un abonnement, une estimation locale en dollars ne constitue pas une facture distincte, et la fenêtre de contexte est une limite différente du quota de votre forfait.
2. Repérez le contexte qui revient sans cesse
Votre dernier message ne constitue qu’une partie d’une requête au modèle. Dans Claude Code, les requêtes peuvent également contenir des instructions de projet, des descriptions d’outils, l’historique de la conversation, le contenu de fichiers et les résultats d’outils précédents.
Supposons qu’un document inchangé de 12 000 jetons apparaisse dans 8 requêtes. Sur l’ensemble de ces appels, le document représente 96 000 jetons d’entrée. Les lectures du cache admissibles peuvent être facturées à un tarif inférieur. Le document peut malgré tout être inutile pour certaines de ces décisions.
Examinez la séquence d’une seule tâche. Quels fichiers ont été lus ? Quels résultats sont restés dans la conversation ? Quelle requête a provoqué la plus forte augmentation ? L’agent utilisait-il encore ces détails à la fin ?
Pour un bug touchant le montant d’une facture, commencez par l’entrée qui échoue, le calcul, les fonctions qui l’appellent et les tests qui le couvrent. Laissez l’agent suivre les références lorsqu’il en a besoin. Charger tout un dépôt à l’avance peut faire en sorte que chaque échange ultérieur transporte du contenu qui n’a jamais contribué à la correction.
Conservez l’ensemble des preuves sur le disque. Renvoyez un résultat concis, accompagné du chemin du fichier et de suffisamment de détails pour consulter l’original. Pour une exécution de tests, indiquez la commande, le code de sortie, les noms des tests échoués, l’erreur pertinente et l’emplacement du journal.
Un résumé qui omet l’unique indice disponible entraîne du travail supplémentaire. Conservez l’erreur exacte, l’identifiant concerné et les éléments nécessaires à l’action suivante.
3. Vérifiez si le cache est réellement utile
La mise en cache des invites réutilise une partie initiale de requête admissible et identique. Placez d’abord les instructions stables, puis les données de la tâche qui changent.
Dans un flux de travail personnalisé avec l’API Claude, un horodatage placé avant la limite du cache peut créer une entrée différente à chaque appel. Placez la limite après le contenu qui se répète. Consultez la documentation actuelle sur la mise en cache pour votre modèle et la structure de vos requêtes.
Comparez les lectures et les écritures du cache entre les requêtes. Si les écritures répétées sont nombreuses et les lectures peu nombreuses, vérifiez les modifications de préfixe, la longueur minimale admissible, la durée de vie et le moment des appels.
Les lectures du cache coûtent toujours de l’argent. Un nombre élevé de lectures peut indiquer que la mise en cache fonctionne ; vérifiez aussi si ce contexte aide à terminer la tâche.
Dans Claude Code, les sous-agents ordinaires ont leur propre contexte et leur propre comportement de mise en cache. Un fork fonctionne différemment. La compaction utilise également une requête au modèle et reconstruit le contexte de la conversation. Évitez de programmer une compaction manuelle toutes les quelques minutes sans en mesurer les résultats.
4. Réduisez le contenu renvoyé par les outils
La réponse d’un outil peut être transmise aux appels ultérieurs du modèle. Une réponse volumineuse peut donc avoir un impact au-delà de la requête qui l’a récupérée.
Prenons un rapport quotidien sur les commandes. Un outil récupère toutes les commandes, le modèle lit chaque ligne, puis une autre requête lui demande de calculer les totaux. Un script peut filtrer les enregistrements, calculer les totaux et renvoyer les exceptions qui nécessitent un jugement.
Cela modifie ce qui est transmis au modèle. Cela crée aussi un calcul que vous pouvez tester indépendamment.
Utilisez la même approche pour les journaux, les feuilles de calcul et les résultats de recherche. Filtrez les données selon le client, la date, l’erreur ou le type d’enregistrement pertinent avant de les renvoyer. Indiquez le filtre utilisé, le nombre d’éléments traités, toute troncature ainsi qu’un chemin ou un identifiant permettant d’accéder aux preuves d’origine.
Vérifiez la pagination. Traiter la première page et la présenter comme l’ensemble des données vous donne une réponse erronée à moindre coût.
Les résultats intermédiaires peuvent rester dans l’environnement d’exécution, tandis que seules les données sélectionnées sont transmises au modèle. Vous pouvez appliquer ce principe dans un petit script local sans construire un système d’agents complexe.
Les définitions des outils occupent également du contexte lorsqu’elles sont chargées. Certains clients reportent déjà le chargement complet des définitions jusqu’à ce qu’elles soient nécessaires. Examinez votre configuration réelle avant de supprimer des intégrations : le seul nombre de connexions ne vous renseigne pas sur leur coût en jetons.
5. Enregistrez la procédure une fois que vous l’avez comprise
Repérez les tâches où l’agent redécouvre sans cesse les mêmes commandes, réécrit le même plan ou décide à partir de zéro quels tests exécuter.
Une fois la procédure comprise, enregistrez-la. Consignez les instructions propres au projet dans un guide court et réutilisable. Mettez les calculs fixes, les transformations de fichiers et les séquences de commandes dans un script testé.
Pour le bug de facturation, un script peut préparer un jeu de données de test, exécuter le calcul, comparer la valeur attendue et signaler le résultat. L’agent doit toujours diagnostiquer une divergence inattendue et choisir la bonne correction. Il n’a pas besoin d’inventer la commande de test à chaque fois.
Faites en sorte que la procédure reste liée à ses hypothèses. Consignez les dépendances requises, les entrées attendues et les conditions qui doivent entraîner l’arrêt. Quand l’environnement change, un échec manifeste est plus facile à diagnostiquer qu’un message de réussite plausible.
Les vérifications d’état répétées méritent le même traitement. Si un service fournit un ID de tâche, utilisez son événement de fin ou une fonction de vérification périodique avec une limite définie. Sollicitez à nouveau le modèle lorsque la tâche est terminée, échoue ou dépasse son délai imparti.
Les actions qui créent ou envoient quelque chose exigent une attention particulière en cas de nouvelle tentative. Vérifiez si la première tentative a réussi avant de la répéter. La réutilisation d’une clé d’idempotence, si elle est prise en charge, peut éviter qu’une réponse incertaine ne se transforme en deux commandes ou deux messages.
6. Attribuez une mission distincte à chaque agent
Les agents parallèles peuvent réduire le temps écoulé. Leurs appels, leur contexte et leur coordination contribuent aussi au coût total.
Répartissez le travail lorsque les missions sont indépendantes et que leurs résultats sont faciles à combiner. Un agent peut reproduire un bug signalé pendant qu’un autre vérifie le contrat de l’interface concernée. Donnez à chacun une question claire et un résultat attendu bien défini.
Évitez de demander à plusieurs assistants d’examiner tout le projet avec la même consigne générale. Cela peut produire plusieurs versions de la même enquête, suivies d’une autre passe pour concilier leurs résumés.
Un transfert utile précise la tâche, les fichiers concernés, les modifications autorisées, le résultat attendu et la condition d’arrêt. Demandez les chemins des preuves et les conclusions nécessaires à l’étape suivante. Laissez les travaux intermédiaires détaillés à disposition dans les fichiers de l’assistant.
Planifiez délibérément la vérification. Effectuez des contrôles ciblés pendant l’implémentation, puis lancez les vérifications plus larges requises sur le résultat combiné. Répétez un contrôle si le code a changé, si une exécution précédente a échoué ou si de nouveaux éléments le justifient. Notez la raison de chaque exécution.
Mesurez séparément les changements de modèle et les changements de flux de travail. Gardez le même ensemble de tâches et les mêmes tests d’acceptation lorsque vous essayez un autre modèle ou un autre paramètre de raisonnement. Incluez les nouvelles tentatives et le temps consacré aux corrections dans la comparaison. Un coût inférieur par appel n’est avantageux que si la tâche complète reste rentable.
7. Interprétez correctement les champs d’utilisation
Les fournisseurs ne déclarent pas tous les entrées mises en cache de la même façon. Reprendre la formule d’un fournisseur pour l’appliquer aux journaux d’un autre peut donner une facture convaincante, mais erronée.
Dans une réponse standard de l’API Claude Messages, input_tokens, cache_creation_input_tokens et cache_read_input_tokens sont des catégories d’entrée distinctes. La création du cache peut aussi être ventilée selon sa durée de vie. Appliquez le tarif correspondant à chaque catégorie.
Dans le schéma actuel de l’API OpenAI Responses, les entrées mises en cache et les décomptes de cache en écriture applicables sont inclus dans le total des entrées. Il faut les soustraire selon la méthode documentée avant de calculer le prix des entrées ordinaires. Utilisez le calcul du fournisseur correspondant au modèle et à l’API que vous appelez réellement.
Conservez la réponse d’utilisation d’origine à côté de votre enregistrement normalisé. Vous pourrez ainsi corriger le calcul si votre fournisseur, votre modèle ou les tarifs changent.
Certaines fonctionnalités génèrent aussi du travail supplémentaire facturé. Avec la compaction de l’API Claude, les nombres d’entrées et de sorties de premier niveau excluent l’itération de compaction. Calculez une seule fois le prix des entrées dans usage.iterations, à partir des champs d’utilisation de chacune. N’ajoutez pas à nouveau les nombres de premier niveau.
L’exécution d’outils, la recherche, l’hébergement et le stockage peuvent entraîner des frais distincts. Si ces frais ne sont pas inclus, indiquez qu’il s’agit du coût du modèle. Pour les requêtes diffusées en continu, utilisez les totaux d’utilisation définitifs lorsqu’ils sont disponibles et évitez de compter plusieurs fois les mises à jour cumulatives.
8. Passez en revue un lot
Voici un calcul illustratif que vous pouvez reproduire. Les nombres de requêtes, les volumes de jetons, les frais d’outils et les résultats ci-dessous sont fictifs. Aucun agent n’a été exécuté pour les obtenir.
Dans cet exemple, la tâche consiste à extraire trois valeurs et les passages qui les étayent pour chacun de quatre documents. Un résultat n’est accepté que si son JSON, ses valeurs et les preuves sources sont corrects.
Les deux scénarios supposent trois résultats acceptés, une tentative rejetée nécessitant une nouvelle tentative et une tâche qui finit par échouer. Cela représente cinq tentatives pour quatre tâches. Chaque tentative contribue à la facture.
Le premier scénario comporte 15 requêtes au modèle : 375 000 jetons d’entrée non mis en cache et 15 000 jetons de sortie. Aux tarifs standard de Claude Haiku 4.5 vérifiés le 7 septembre 2026, les entrées coûtent 1 $ par million de jetons et les sorties 5 $ par million. Le coût du modèle est de 0,45 $. Ajoutez 0,06 $ de frais fictifs pour les outils externes : le total s’élève à 0,51 $.
Divisez 0,51 $ par les trois résultats acceptés : 0,17 $ par résultat accepté.
Le deuxième scénario suppose 10 requêtes, avec moins d’entrées nouvelles et quelques entrées mises en cache. Le coût du modèle se décompose comme suit :
• 55 000 jetons d’entrée non mis en cache à 1 $ par million : 0,055 $.
• 25 000 jetons écrits dans le cache pendant cinq minutes à 1,25 $ par million : 0,03125 $.
• 25 000 jetons écrits dans le cache pendant une heure à 2 $ par million : 0,05 $.
• 50 000 jetons lus dans le cache à 0,10 $ par million : 0,005 $.
• 7 500 jetons de sortie à 5 $ par million : 0,0375 $.
Le coût du modèle s’élève à 0,17875 $. Ajoutez 0,05 $ de frais fictifs pour les outils externes : cela donne 0,22875 $ pour toutes les tentatives, soit 0,07625 $ par résultat accepté. Les différentes durées de vie du cache illustrent les catégories de facturation ; elles ne constituent pas une configuration recommandée.
Ces chiffres montrent le coût de l’utilisation indiquée. Ils ne prouvent pas que filtrer le contexte ou modifier une limite du cache donnera ces mêmes nombres ou préservera la qualité. Une comparaison réelle nécessite des requêtes enregistrées et des résultats vérifiés indépendamment. Les tâches échouées doivent tout de même être incluses dans le total.
9. Appliquez cette méthode à votre propre flux de travail
Choisissez un petit ensemble de tâches représentatives et gardez leurs entrées inchangées. Incluez une réussite ordinaire, un cas difficile et une tâche qui a déjà échoué. Rédigez les critères d’acceptation avant d’apporter des modifications.
Exécutez le flux de travail existant et enregistrez les données de ses requêtes. Repérez le moment où du contenu inutile a été ajouté à la conversation, où une procédure a été reconstruite, où une vérification a été répétée ou où une erreur inchangée a déclenché une nouvelle tentative.
Modifiez un seul mécanisme. Filtrez un résultat volumineux d’un outil. Enregistrez une séquence de commandes répétée. Corrigez une limite du cache. Réduisez la mission d’un assistant. Pour cette comparaison, gardez le modèle et les critères d’acceptation inchangés.
Relancez les mêmes entrées dans un environnement de test propre. Distinguez les premières exécutions de celles effectuées avec un cache prérempli. Répétez l’opération suffisamment de fois pour vérifier la constance du résultat et conservez les tentatives échouées dans les totaux.
Utilisez cette invite avec un agent de programmation qui peut accéder à votre implémentation et à vos journaux :
Examine ce flux de travail et les journaux d’exécution disponibles.
Définis les limites de la tâche et les critères d’acceptation. Retrace les appels du parent, les appels des assistants, les nouvelles tentatives, la vérification et le résultat final.
Crée un rapport local indiquant le coût enregistré du modèle, les frais distincts des outils, les données d’utilisation manquantes, les tâches acceptées, les tâches échouées, le temps écoulé et les interventions humaines. Utilise les champs d’utilisation propres au fournisseur et une grille tarifaire datée. Conserve les réponses d’utilisation brutes. Élimine les doublons d’ID de requête.
Repère le coût évitable le plus élevé étayé par les journaux. Indique les appels concernés et explique pourquoi ce travail était inutile. Distingue clairement les estimations des montants enregistrés.
Propose une modification et une comparaison utilisant les mêmes entrées, le même modèle et les mêmes critères d’acceptation. Distingue les premières exécutions de celles effectuées avec un cache prérempli. Arrête-toi si les preuves requises manquent et précise exactement ce qui est nécessaire.
N’effectue pas d’appels payants à l’API et ne modifie pas le flux de travail en production pendant cette inspection. Enregistre le rapport et la modification proposée pour examen.
Les critères d’acceptation garantissent l’impartialité de la comparaison. Si le filtrage d’un journal masque l’échec ou si un modèle plus petit nécessite des corrections répétées, consigne le résultat et révise la modification.
Je partage ici des conseils pratiques sur les flux de travail IA. Suivez-moi pour découvrir le prochain.