Agents multi-tours : où partent vraiment les tokens
9 septembre 2026
Un appel LLM isolé coûte ce que coûte son prompt. Un agent qui boucle — observe, appelle un outil, relit le résultat, décide du prochain appel — renvoie tout l'historique à chaque tour. Le coût cumulé d'une conversation n'est pas la somme de N appels indépendants : chaque tour paie de nouveau pour tous les précédents.
Pourquoi la croissance est quadratique
Si chaque tour ajoute environ T tokens à l'historique (question, réponse, résultat d'outil), le tour N envoie environ N×T tokens de contexte. Sur une boucle de 10 tours, le dernier appel paie dix fois le coût du premier tour rien que pour relire l'historique — avant même de compter la génération elle-même.
C'est un problème structurel, pas un accident d'implémentation : un modèle de langage stateless n'a aucune autre façon de « se souvenir » d'un tour précédent que de le relire intégralement à chaque appel.
La compression d'historique, et sa vraie contrainte
L'approche standard : au-delà d'un seuil de tokens, résumer les messages les plus anciens via un appel LLM dédié (généralement un modèle plus léger que celui qui pilote l'agent), et injecter ce résumé à la place de l'historique brut. Les derniers messages restent intacts — un résumé ne doit jamais toucher le tour en cours, où le détail compte le plus.
Le vrai risque n'est pas le coût de l'appel de résumé (marginal comparé à ce qu'il économise), mais la perte d'information : un résumé trop agressif peut faire oublier à l'agent une contrainte posée trois tours plus tôt. D'où l'intérêt de préserver systématiquement un nombre fixe des tout derniers messages non résumés, et de ne déclencher la compression qu'au-delà d'un seuil réel plutôt qu'à chaque tour.
Un piège adjacent : le cache provider-side
Les providers qui exposent du prompt caching (voir le guide sur la décomposition des coûts) l'indexent généralement sur un préfixe stable du contexte. Réécrire le début de la conversation — même pour la compresser — invalide ce cache pour tout le tour suivant. Il y a donc une tension réelle entre « compresser pour réduire le contexte envoyé » et « préserver le préfixe pour garder le cache chaud » : les deux optimisations ne sont pas gratuites l'une envers l'autre, et l'arbitrage dépend de la longueur de la conversation restante.
Regrouper les tours pour pouvoir les mesurer
Un agent qui boucle produit un appel HTTP par tour. Sans un identifiant de conversation explicite propagé par l'appelant, chaque tour apparaît dans les logs comme une requête isolée sans lien avec les autres — impossible de répondre à « combien coûte cette conversation de bout en bout ? ». Un identifiant de session, fourni par le client et non deviné côté serveur (un hachage de préfixe de messages casse dès qu'un agent tronque son historique en fenêtre glissante), est ce qui rend visible le coût réel d'une boucle plutôt que celui de chacun de ses appels pris isolément.