Les outils serveur sont une facture à part
Updated September 1, 2026 · first published September 1, 2026
La plupart des modèles de coût LLM n’ont qu’un compteur : tokens en entrée, tokens en sortie, prix au million. C’était exact tant qu’une requête ne faisait que générer du texte. Ça a cessé de l’être avec les outils côté serveur.
La recherche web, le fetch et l’exécution de code tournent sur l’infrastructure du fournisseur, et plusieurs portent leur propre frais à l’usage en plus des tokens qu’ils produisent. Un tour d’agent peut donc vous facturer deux fois.
La partie qui se cumule
C’est le second coût qu’on oublie. Chaque résultat d’outil est ajouté à la conversation, et chaque tour suivant renvoie l’ensemble en entrée. Dix recherches en début d’exécution, ce n’est pas dix frais : c’est dix frais plus leurs charges utiles relues à chaque tour suivant.
D’où des coûts d’agent qui semblent non linéaires alors que l’arithmétique des tokens les dit linéaires. Le frais à l’usage est la partie visible ; la croissance du contexte est la plus grosse, et elle atterrit dans votre ligne de tokens d’entrée sans étiquette.
Attribuez, sinon vous ne pilotez rien
Journalisez les appels d’outils par requête à côté de l’objet d’usage : quel outil, combien d’appels, et la taille en tokens de ce que chaque résultat a ajouté. Ce dernier champ rend le cumul visible.
Calculez ensuite le coût par exécution d’agent, pas par appel d’API.
Trois contrôles efficaces
Plafonnez les appels d’outils par exécution : cela borne les deux coûts d’un coup.
Tronquez ce qui entre dans le contexte : résumer un résultat avant de l’ajouter allège tous les tours suivants.
Mettez en cache le préfixe stable : prompt système et définitions d’outils sont constants, le cache supprime le plus gros coût répété.
Related
Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit →