Coût de contexte d'un agent IA : mesurer les prompts et tool calls répétés

Lors du développement d’agents IA (Claude Code, Cline, Roo Code ou pipelines multi-étapes maison), l’usage de l’API peut augmenter à mesure que le contexte s’accumule. La composition précise de chaque requête dépend du client : elle peut inclure le prompt système, les schémas des outils disponibles, l’historique des messages et les résultats des appels de fonction.

Pour maîtriser le budget sans perdre de fonctionnalités, établissez une baseline sur une tâche fixe, identifiez la source principale de tokens superflus et optimisez l’environnement agentique en ne modifiant qu’une variable à la fois.

Anatomie du contexte d’un agent IA : pour quels tokens paie-t-on à chaque étape ?

Pour mesurer, répartissez le contexte envoyé au modèle en quatre composants observables :

1. Instructions et règles système (System Prompt) : exigences de style de base, contraintes de sécurité et contexte du dépôt.
2. Schémas d’outils (Tool Schemas) : descriptions JSON des fonctions connectées, paramètres et types de données, lorsque le client les inclut dans une requête.
3. Historique des messages (Message History) : messages précédents de l’utilisateur et réponses de l’agent qui s’accumulent au fil de la tâche.
4. Résultats d’outils (Tool Outputs) : contenu des fichiers lus, logs de commandes terminal et dumps d’API.

Ne multipliez pas aveuglément la taille de la première requête par le nombre d’étapes. Exportez l’usage de chaque appel : l’historique peut grossir, le client peut tronquer des données et le fournisseur peut comptabiliser les cached tokens séparément.

Tableau comparatif des sources de contexte et de leur optimisation

Composant de contexte	Ce qu’il faut mesurer	Risque principal de surcoût	Modification pour un test isolé
Tool Schemas	Taille de la liste effectivement envoyée	Outils inutilisés dans l’ensemble partagé	Ne garder que les tools nécessaires à la tâche
Tool Outputs	Taille de chaque résultat	Lire les fichiers entiers plutôt que des extraits ciblés	Limiter les plages de lignes et le volume des logs
Historique des étapes	Croissance de l’input d’un appel à l’autre	Accumulation de résultats devenus inutiles	Vérifier la réduction d’historique prise en charge par le client
System Prompt	Taille et stabilité du préfixe	Instructions répétées	Supprimer les doublons tout en conservant les règles obligatoires

Guide pas à pas : mesurer une baseline et réduire les dépenses

Commencez par relever les tarifs actuels du modèle. Pour calculer la baseline, utilisez les prix BetterToken actuels et non des valeurs tirées d’anciens exemples. Voir les prix BetterToken actuels

Pour une optimisation objective, appliquez une méthode de mesure à variable unique :

Étape 1. Fixer une tâche de contrôle pour le test

Choisissez un scénario d’ingénierie reproductible, par exemple : « trouver une fonction de validation dans un dépôt, ajouter la gestion d’un cas limite et lancer les tests unitaires ». La tâche doit avoir un critère d’achèvement clair, tel qu’un code de sortie 0 dans pytest ou bun test.

Étape 2. Mesurer la baseline (Input, Output, Cache)

Exécutez la tâche dans la configuration standard de l’agent. Notez dans les logs ou le tableau de suivi :

• le nombre d’étapes exécutées ;
• le volume total d’input tokens ;
• le volume total d’output tokens ;
• le volume de tokens mis en cache (cached tokens) ;
• le coût selon les tarifs actuels.

Vérifiez les tarifs actuels du modèle choisi sur la page des prix BetterToken. Dans Workspace, vous pouvez vérifier pour une requête acceptée le modèle, l’heure et le statut, les input/output tokens, les cached tokens lorsque le modèle les prend en charge et le coût de l’appel. Si une étape de l’agent crée plusieurs requêtes, ne présentez pas une entrée au niveau de la requête comme un découpage final par étape : rapprochez-les par l’heure et les données de votre propre client.

Étape 3. Modifier une variable de contexte

Effectuez des tests isolés en modifiant strictement un paramètre à chaque itération :

• Expérience A (Tool Filtering) : Ne gardez que les outils requis pour la tâche de contrôle et mesurez l’écart d’input tokens.
• Expérience B (Output Truncation) : Limitez la sortie du terminal aux 50 premières lignes d’une erreur au lieu d’un dump complet de 2 000 lignes.
• Expérience C (Prefix Stability) : Si le modèle et l’endpoint prennent en charge le prompt caching, gardez l’ordre du prompt système et des schémas d’outils inchangé, puis vérifiez les données réelles de cached tokens.

Étape 4. Évaluer l’économie et la qualité de la solution

Comparez les métriques finales avec la baseline initiale. Ne retenez une modification que si la tâche de contrôle satisfait toujours le même critère de qualité et si le temps ou la dépense mesuré s’améliore sur votre ensemble d’exécutions.

Recommandations pour configurer les environnements d’agents

1. Réduisez l’ensemble d’outils selon le rôle : un agent chargé de lire n’a pas besoin de fonctions d’écriture ; vérifiez si cela réduit l’input réel sans dégrader le résultat.
2. Conservez un préfixe stable : si le caching est pris en charge, ne changez pas sans nécessité l’ordre des règles communes et vérifiez les cached tokens au lieu de supposer une réduction.
3. Bornez la boucle : définissez un nombre fini de tentatives et une condition d’arrêt explicite adaptée à la tâche concernée.

Cas limites et erreurs fréquentes

• Erreur : désactiver des schémas de validation critiques. Si l’on réduit trop la description d’un schéma d’outil, le modèle peut envoyer du JSON invalide, ce qui déclenche une chaîne de requêtes répétées.
• Erreur : croire aveuglément les promesses d’économies des réseaux sociaux. L’effet de l’optimisation du contexte dépend de la structure de votre dépôt et de la taille moyenne des fichiers.
• Erreur : absence de télémétrie transparente. Si l’endpoint ne renvoie pas de statistiques séparées pour les input/cache tokens, n’estimez pas le cache sur des hypothèses ; marquez la valeur comme inconnue.