Coût des LLM : ce qui le pilote et comment le réduire

Qu'est-ce qui pilote réellement le coût d'un LLM ?

Le coût d'un LLM est piloté par le nombre de tokens que vous envoyez, le nombre de fois où vous les renvoyez, et le palier de modèle qui les lit — dans cet ordre d'impact. Le prix affiché au million de tokens est la variable la moins intéressante : c'est la seule que vous ne pouvez pas changer, et celle sur laquelle tout le monde se focalise. L'erreur la plus fréquente consiste à raisonner comme sur une facture d'électricité : choisir un fournisseur moins cher, payer moins. Ça ne marche pas ainsi, parce qu'une même tâche peut coûter vingt fois plus ou moins sur le même modèle selon la façon dont la requête est construite. Deux développeurs sur des offres identiques, faisant un travail identique, constatent couramment des factures très différentes. L'écart ne vient presque jamais du tarif. Je construis des outils de réduction de tokens : je passe mes semaines à regarder où part réellement l'argent. Voici le découpage honnête, dans l'ordre qui compte.

Pourquoi l'entrée coûte-t-elle plus cher que la sortie en pratique ?

Parce que la sortie est petite et que l'entrée s'accumule. Au token, la sortie coûte davantage — typiquement cinq fois l'entrée. Au total, l'entrée domine, parce que vous la renvoyez encore et encore. Un échange de chat facture l'entrée une fois. Un agent ne fonctionne pas ainsi : il planifie, appelle un outil, lit le résultat, replanifie — et à chacune de ces étapes le modèle reçoit l'intégralité de la conversation précédente. Un fichier de 6 000 tokens lu au deuxième tour est encore dans la charge utile au vingtième. Vous l'avez payé dix-huit fois de plus. C'est l'effet de relecture, et c'est la chose la plus importante à comprendre sur le coût agentique. C'est aussi pourquoi « demande au modèle d'être bref » est un si mauvais conseil : la brièveté rogne la sortie, la petite direction, pendant que l'entrée renvoyée en boucle reste intacte. Deux conséquences à intégrer :

Une longue session n'est pas linéairement plus chère qu'une courte. Le coût croît avec la fenêtre de contexte accumulée : une session qui double de longueur fait plus que doubler de prix.
Le gaspillage précoce est le plus cher. Un fichier lu au deuxième tour est facturé à tous les tours suivants ; la même lecture au dix-neuvième ne l'est qu'une fois.

Le prompt caching rend-il tout cela gratuit ?

Non, mais il change nettement l'arithmétique : une lecture de cache revient à environ 10 % d'un token d'entrée neuf, une vraie remise sur la part dominante de la facture. Le piège est la condition. Le prompt caching ne s'applique qu'à un préfixe identique octet pour octet d'un tour à l'autre. Tout ce qui modifie le début de votre charge utile invalide la suite. En pratique :

Un système prompt et un CLAUDE.md stables valent de l'argent réel — voir comment un CLAUDE.md surchargé gonfle la facture.
Modifier les instructions projet en cours de session casse le cache et refacture tout le préfixe plein tarif.
Un transcript qui ne fait que croître se cache bien au début et mal à la fin — là où se trouvent vos lectures les plus récentes et les plus volumineuses.

Le caching récompense donc un contexte conçu pour être stable. Il ne rattrape pas un contexte qui s'agite.

Passer à un modèle moins cher règle-t-il le problème ?

Ça aide, et c'est le levier que tout le monde saisit en premier parce qu'il est le plus simple — mais il traite le symptôme. Les paliers de modèles varient d'environ un ordre de grandeur entre le moins cher et le frontier. Router le travail de routine vers le bas fait réellement économiser, et la plupart des sessions en contiennent beaucoup : reformatage, éditions mécaniques, recherches simples. Là où ça dérape, c'est quand le palier remplace l'hygiène de contexte. Une session gaspilleuse sur un modèle bon marché reste gaspilleuse : vous avez divisé un nombre que vous auriez dû réduire. L'ordre que je recommande : corriger ce que vous envoyez d'abord, choisir le palier ensuite. L'inverse revient à optimiser un multiplicateur que vous changerez de toute façon, sans jamais découvrir ce dont la tâche avait réellement besoin. Pour les chiffres actuels par modèle, la tarification des tokens des API LLM tient le tableau, et les coûts en tokens des agents de codage IA détaillent ce que donnent de vraies sessions. Le calculateur de coût de tokens fait le calcul sur vos propres chiffres.

Quels leviers réduisent réellement la facture ?

Quatre, par rendement décroissant sur une session de code typique. Aucun n'exige de changer de modèle ni d'écrire un prompt plus malin.

Récupérer plutôt que lire. Pointez le modèle sur le symbole dont il a besoin, pas sur le fichier qui le contient. La recherche sémantique de code renvoie un fragment pertinent au lieu de six mille tokens de fichier.
Filtrer les sorties d'outils. Un test qui échoue peut cracher 15 000 tokens dont une cinquantaine comptent — l'assertion en échec et sa position. L'output filtering garde le signal.
Borner la session. Un transcript par tâche. Le travail sans rapport traîné derrière soi refacture chaque lecture précoce pour le reste de la journée : c'est le coût évitable le plus courant.
Élaguer la surface d'outils. Chaque serveur MCP connecté annonce ses schémas à chaque tour, appelé ou non. Débranchez ce dont la session n'a pas besoin.

Aucun de ces leviers n'échange la qualité contre le coût — c'est la partie que l'on attend comme un compromis et qui n'en est pas un. Vous retirez des logs bruts, des corps de fichiers hors sujet et des définitions d'outils inutilisées, pas le signal sur lequel le modèle raisonne. Une fenêtre plus légère produit généralement de meilleures réponses, les modèles prêtant le moins d'attention à ce qui est enfoui dans une fenêtre saturée.

Comment savoir ce que tout cela vaut ?

Mesurez avant/après sur la même tâche. Pas sur un benchmark, pas sur le chiffre d'un vendeur : sur votre travail. La référence prend deux minutes : ouvrez une session fraîche, regardez ce qui occupe le contexte avant d'avoir tapé quoi que ce soit (système prompt, instructions projet, schémas MCP), et notez-le. Ce chiffre est votre surcoût permanent à chaque tour de chaque session, et il surprend la plupart des gens. Mesurer la consommation d'un agent traite la version multi-agents. Lancez ensuite une tâche représentative et comparez. Quiconque vous vend une réduction sans pouvoir montrer cette comparaison — nous compris — demande un acte de foi. Si vous préférez que les leviers s'appliquent seuls, Tokenade applique les quatre ci-dessus automatiquement dans Claude Code, Cursor, Codex, Copilot et Windsurf, et affiche des économies mesurées plutôt qu'une promesse. C'est source-available sous licence MIT : vous pouvez lire ce qu'il fait à votre contexte avant. La voie manuelle fonctionne aussi et, si vous vous y tenez, elle ne coûte rien.

Ce qui tourne mal (anti-patterns)

Chercher un prix au token moins cher. Le tarif est la variable que vous ne contrôlez pas. Le volume et la répétition sont celles que vous contrôlez. Optimiser la longueur de sortie. C'est la petite direction, plus chère au token mais envoyée une fois. L'entrée est la grande direction, moins chère et envoyée en boucle. Prendre une grande fenêtre de contexte pour de la capacité gratuite. Une fenêtre d'un million de tokens ne baisse pas le prix de ce que vous y mettez. Elle supprime la contrainte qui vous tenait discipliné. Modifier les instructions projet en cours de session. Chaque édition casse le préfixe caché et le refacture plein tarif pour le reste de la session. Croire qu'un modèle moins cher règle un problème de contexte. Il divise la facture, il ne la diagnostique pas. Le gaspillage est toujours là, et il revient dès que vous avez besoin du palier frontier.

Foire aux questions

Pourquoi ma facture LLM dépasse-t-elle mon ressenti d'usage ?

Presque toujours l'effet de relecture. Vous pensez en prompts envoyés ; vous êtes facturé sur le contexte complet renvoyé à chaque tour. Une session qui ressemble à vingt questions peut être vingt charges utiles de plus en plus lourdes, chacune contenant tout ce qui précède.

L'API est-elle moins chère qu'un abonnement ?

Cela dépend entièrement du volume et de l'efficacité de vos sessions. Un abonnement est un prix fixe avec un plafond d'usage ; l'API est du paiement au token sans plafond. Un usage intensif et bien optimisé favorise souvent l'API ; un usage léger ou gaspilleur favorise l'abonnement. Claude Code : abonnement ou API détaille le point de bascule.

Une fenêtre de contexte plus grande coûte-t-elle plus cher ?

Uniquement par ce que vous y mettez. Les fournisseurs ne facturent pas la marge disponible, et certains appliquent une tarification majorée au-delà d'un seuil de long contexte — vérifiez chez le vôtre. Le vrai effet d'une grande fenêtre est comportemental : elle supprime la pression qui gardait les sessions propres.

Quelle est la façon la moins chère de faire tourner un agent de code IA ?

Des sessions courtes, des lectures ciblées, des sorties de commandes filtrées et une surface d'outils réduite — sur le palier dont la tâche a réellement besoin. Cette combinaison bat n'importe quelle astuce isolée, y compris le choix du modèle, parce qu'elle attaque le volume que tous les autres facteurs multiplient.

Ces leviers valent-ils hors du code ?

Oui, partout où un modèle travaille sur un corpus qu'il n'a pas mémorisé : questions-réponses sur documents, agents de support, assistants de recherche. Les techniques précises changent, mais récupérer plutôt que déverser, filtrer les sorties bavardes et élaguer l'historique périmé valent pour tout ce qui a une fenêtre de contexte et une facture au bout.

À voir aussi :

Tarification des tokens des API LLM — les tarifs actuels par modèle.
Coûts en tokens des agents de codage IA — ce que donnent de vraies sessions.
Comment la context window détermine votre facture — l'arithmétique en détail.
Comment réduire la consommation de tokens des agents de codage IA — les six leviers.
Calculateur de coût de tokens LLM — vos propres chiffres.