Même IA, facture 29 fois plus élevée : comment les outils d'IA gonflent la consommation de tokens

Même IA, facture 29 fois plus élevée : comment les outils d'IA gonflent la consommation de tokens

iaprogrammationcoûtscursor

Sources:HN + web research · HN

Le 1er août, un outil de programmation par IA très populaire a discrètement modifié un paramètre : les utilisateurs ne peuvent plus voir combien d’argent ils ont dépensé.

Cet outil s’appelle Cursor, l’un des assistants de codage IA les plus en vue ces deux dernières années. Dans son éditeur, il suffit de décrire ses besoins en langage naturel pour qu’il modifie le code. Les utilisateurs paient un abonnement de 20 dollars par mois incluant un quota d’utilisation, le dépassement étant facturé au volume. Auparavant, la page d’utilisation affichait simultanément deux données : le nombre de « mots » (tokens) consommés dans le mois et leur équivalent en dollars. Le 1er août, des utilisateurs ont remarqué que la colonne des montants avait disparu, ne laissant qu’une suite de chiffres. Dans le fichier CSV d’exportation des factures, la colonne des montants était également absente.

« Je m’appuyais quotidiennement sur cette page pour surveiller mes dépenses, et aujourd’hui les montants se sont soudainement changés en nombre de tokens », a écrit un utilisateur sur le forum officiel de Cursor. Le message a rapidement été relayé sur Hacker News, accumulant 291 votes positifs et 125 commentaires en 24 heures. Quelques centaines de votes restent modestes sur ce forum, mais le sujet a touché un point sensible du quotidien des développeurs : personne ne sait expliquer comment est calculée sa facture d’IA. Un compte se présentant comme un employé de Cursor est intervenu pour expliquer que le montant total des dépenses reste visible sur la page principale du compte, que l’absence de montants dans l’export CSV était « une erreur survenue lors du nettoyage d’anciennes fonctionnalités, désormais corrigée », et concernant le graphique des dépenses : « certains utilisateurs interprétaient la valeur théorique en dollars du quota inclus comme une dépense réelle, nous l’avons donc retiré ».

Capture d'écran de la page de dépenses de Cursor Figure : Capture de la page de dépenses publiée par un utilisateur dans le débat — seuls les chiffres d’utilisation apparaissent, sans montants correspondants. Source : pasteboard.co

Cette explication n’a pas totalement éteint les doutes. Des utilisateurs ont souligné que l’indicateur circulaire de coût situé à côté de l’utilisation du contexte avait lui aussi été retiré : « Désormais, si l’on active par erreur un modèle coûteux, on ne s’en aperçoit qu’une fois le quota du forfait épuisé. » Ces deux décisions vont dans la même direction : l’utilisateur conserve la possibilité de consulter son « volume d’utilisation », mais il lui devient très difficile de convertir ce « volume » en « argent ».

Le jour même, une démonstration encore plus marquante est apparue dans les commentaires. Un développeur nommé tosh a exécuté 10 tâches identiques (calcul de sommes de contrôle de fichiers, fusion de feuilles de calcul, correction d’un pipeline de build) avec un même modèle d’IA sur une même machine virtuelle, en utilisant 6 outils de codage par IA différents. Le résultat : l’outil le plus économe n’a consommé que 173 000 tokens, tandis que le plus gourmand en a consommé 5 070 000 — soit un écart de 1 à 29. Tous les outils ont mené à bien les tâches avec des résultats identiques ; seule la facture variait.

Tableau comparatif de consommation de tokens Figure : Consommation réelle de tokens de 6 outils avec un même modèle et les mêmes tâches — de 173 000 à 5,07 millions de tokens. Source : news.ycombinator.com

Pour comprendre cet écart, deux notions méritent d’être précisées. Le token est la plus petite unité de facturation d’une IA, assimilable au nombre de mots. Avant chaque réponse, l’IA doit relire l’intégralité de la question, de la notice de l’outil et de l’historique de la conversation — chaque mot lu étant facturé. Quant à « l’outil », il désigne ici l’ensemble de l’enveloppe autour du modèle : prompt système, liste des outils disponibles, fichiers de mémoire, instructions du projet et tous les produits intermédiaires injectés dans l’échange.

Cet écart prouve une chose : ce n’est pas le modèle lui-même qui coûte cher, mais la façon dont l’outil l’exploite. En analysant les données, on s’aperçoit que le nombre de tokens « générés » (en sortie) par les 6 outils est sensiblement le même (de 30 000 à 50 000 tokens). La différence provient quasi exclusivement des tokens « injectés » (en entrée). L’outil le plus sobre ne comportait même pas de prompt système et fournissait un simple terminal au modèle ; le plus lourd embarquait à lui seul un « système de mémoire » de plus de 10 000 mots transmis à chaque tour de conversation. Selon un intervenant, ces préambules peuvent à eux seuls doubler le coût d’une tâche.

Un contexte trop chargé coûte cher, mais il dégrade aussi les performances. L’espace de travail d’un grand modèle de langage — appelé fenêtre de contexte — est limité, se situant généralement entre plusieurs centaines de milliers et un million de tokens. Une fois cet espace saturé, l’outil doit soit résumer les échanges précédents (au risque de perdre des détails et d’induire des hallucinations), soit réinitialiser le contexte. Plus subtil encore, un utilisateur a remarqué que ces éléments d’aide en apparence bienveillants détournent parfois le modèle, l’amenant à multiplier les étapes de raisonnement et à ralentir son exécution.

Certes, un écart de 1 à 29 correspond à un scénario extrême et ne reflète pas la facture quotidienne de chaque utilisateur. Certains commentaires rappellent qu’une grande partie des éléments injectés par les grands outils bénéficie de la mise en cache des prompts, ce qui réduit le coût du token jusqu’à 90 %. Les outils minimalistes, quant à eux, terminent souvent leur travail avant d’atteindre le seuil de mise en cache (moins de 1 024 tokens) et ne profitent pas de ce rabais. L’auteur du test a lui-même reconnu que son outil minimaliste manquait de capacités d’orchestration pour les tâches complexes. Ces nuances sont légitimes, mais le fait structurel demeure : pour un même travail, le volume de tokens consommés dépend avant tout des choix d’architecture de l’éditeur, et non des besoins réels de l’utilisateur.

Pour le grand public qui ne code pas, l’enseignement majeur de cette affaire est que, à l’ère de l’IA, l’unité de facturation passe de « l’argent visible » au « volume de mots invisible ». Le quota d’un abonnement est par nature une réserve de tokens. Lorsque les éditeurs masquent les montants en dollars sur l’interface pour ne laisser que le nombre de tokens, les utilisateurs perdent toute capacité de comparaison — une même tâche peut nécessiter quelques dizaines de milliers de tokens sur un outil et des millions sur un autre, sans moyen de savoir dans quelle catégorie on se situe. Un utilisateur a calculé qu’aux tarifs API bruts, les tokens consommés sur son forfait mensuel de 100 dollars représentaient environ 5 000 dollars de valeur réelle. L’abonnement étant déconnecté du coût réel, les éditeurs ont peu d’incitations financières à réduire le gaspillage de tokens.

Cursor indique que l’exportation CSV est réparée, mais le graphique des montants ne reviendra pas. Les discussions se poursuivent et certains développeurs ont commencé à créer leurs propres outils minimalistes. Pour les observateurs, la leçon est claire : quand les factures deviennent floues, les dépenses supplémentaires se nichent précisément dans ce flou.

Liens de référence :

  • Forum officiel de Cursor : Usage page to token amount
  • Discussion HN (item?id=49135257)
  • Publication X de tosh (données comparatives)