Comment réduire la consommation de tokens de Cursor

Cursor brûle des tokens avec le contexte @-codebase, la récupération indexée, les manifestes MCP et les longs fils agent. Voici comment couper chacun sans abrutir le modèle.

Profile photo of Paul Irolla

Par Paul Irolla

Founder · AI & developer tools · Tokenade

Ph.D. in AI · builds token-optimization tooling for AI coding agents

Voir la page de l'auteur
8 min de lecture
Résumer avec l'IA
Citer cette page

Comment réduire la consommation de tokens de Cursor ?

Vous réduisez la consommation de tokens de Cursor en contrôlant ce qui est entassé dans le prompt : le contexte du codebase qu'il tire via les mentions @ et la récupération indexée, la sortie de terminal brute qu'il avale en mode Agent, le manifeste d'outils MCP qu'il renvoie à chaque tour, et l'historique de conversation qu'il refacture à chaque étape. Resserrez ces quatre points et le coût chute fortement — sans rendre le modèle moins bon, parce que vous coupez le bruit, pas le signal sur lequel il raisonne réellement. Ceci est le compagnon spécifique à Cursor de Comment réduire la consommation de tokens d'un agent de codage IA. Si vous voulez d'abord la version agnostique de l'outil, commencez par là. Les leviers sont les mêmes d'un outil à l'autre — ce qui change, c'est la plomberie. Ici, je les applique au comportement concret de Cursor : comment son index alimente le context window, ce que le mode Agent déverse dans un fil, et où va réellement votre argent. Je suis un praticien titulaire d'un doctorat en IA et je construis des outils de tokens pour gagner ma vie, alors je serai direct sur un point d'emblée : la plupart des plaintes « Cursor coûte cher » ne portent pas sur un modèle gourmand. Elles portent sur le harness qui lui donne trois fois plus de contexte que la tâche n'en avait besoin. Ça se corrige.

Pourquoi Cursor consomme-t-il autant de tokens ?

Cursor consomme beaucoup de tokens parce qu'il relit l'intégralité du fil à chaque tour et charge le contexte du codebase de façon agressive en amont. L'architecture est la même boucle d'agentic coding que fait tourner tout outil de codage : à chaque étape, on renvoie au modèle la conversation complète plus tous les résultats d'outils. Donc un morceau surdimensionné tiré tôt est payé à nouveau à chaque tour qui suit. (Pour les mécanismes expliquant pourquoi la taille du contexte domine le coût, voir context window et token.) Quatre schémas génèrent l'essentiel de la facture : Le contexte du codebase via @ et l'indexation. Cursor indexe votre dépôt avec des embeddings et récupère les morceaux pertinents quand vous mentionnez des fichiers ou le codebase avec @. C'est vraiment utile — c'est de la retrieval-augmented generation appliquée à votre code. Mais « pertinent » est flou, et une requête @codebase large peut ramasser des dizaines de fichiers, dont la plupart sont survolés puis écartés par le modèle. Vous payez le prix input plein pour chaque morceau récupéré. La sortie de terminal non filtrée en mode Agent. Le mode Agent lance des commandes — npm test, tsc --noEmit, git diff, des étapes de build — et la sortie brute atterrit directement dans le fil. Un run de test en échec peut émettre 10 000+ tokens de stack traces, de coches vertes et de tableaux de timing. Le modèle avait besoin de peut-être 50 de ces tokens : le nom du test en échec et l'assertion cassée. Le reste est du fret, et vous le repayez à chaque tour suivant. Le manifeste MCP. Chaque serveur MCP que vous connectez annonce ses définitions d'outils complètes à chaque tour, qu'elles soient utilisées ou non. Une poignée de serveurs avec dix outils chacun, c'est un surcoût fixe qui s'accumule discrètement sur une longue session. Voir Les meilleurs serveurs MCP pour Claude Code — le principe du coût du manifeste est identique dans Cursor. Les longs fils Agent. L'Agent de Cursor laisse la conversation grossir. Au trentième tour, cette lecture de fichier de 8 000 tokens du début est renvoyée pour la trentième fois. Le fil n'oublie pas — il refacture.

Combien ça coûte réellement ?

Ça coûte le prix input de votre modèle, multiplié par chaque token redondant, multiplié par chaque tour qu'il survit — c'est pourquoi le gonflement du contexte se compose au lieu de s'additionner. La tarification actuelle des modèles de pointe rend le calcul concret :
ModèleInput ($/MTok)Output ($/MTok)
Claude Opus 4.8$5$25
Claude Sonnet 4.6$3$15
Claude Haiku 4.5$1$5
GPT-5.5$5$30
Disons que vous êtes sur Sonnet 4.6 à $3/MTok en input. Une seule lecture de fichier de 8 000 tokens qui suit pendant 25 tours vous coûte 200 000 input tokens — environ $0.60 — pour un fichier lu une seule fois. Multipliez par la douzaine de fichiers que touche une tâche non triviale et une seule session Agent dépense tranquillement quelques dollars rien qu'en relectures. Sur Opus 4.8 ou GPT-5.5 à $5/MTok, c'est pire. Une atténuation que Cursor et les fournisseurs vous offrent déjà est le prompt caching : les cache reads sont facturés à environ 10 % du tarif input. Ça aide pour le préfixe stable d'un fil, mais ça ne vous évite pas de récupérer les mauvais fichiers en premier lieu — vous payez quand même pour les écrire dans le cache, et un cache hit sur du bruit reste du bruit qui occupe le context window. Le caching est une remise sur une facture que vous devriez réduire, pas un substitut à la réduction. Pour le tableau tarifaire plus large, voir Coûts en tokens des agents de codage IA et Tarification des tokens d'API LLM.

Comment couper la consommation de tokens de Cursor dès aujourd'hui

Coupez la consommation de tokens de Cursor en étant délibéré sur la récupération, en filtrant la sortie d'outils, en élaguant les serveurs MCP et en gardant les fils courts. Voici l'ordre dans lequel je le ferais :
  1. Arrêtez d'utiliser @codebase par réflexe. Quand vous savez quels fichiers comptent, mentionnez-les par leur nom avec @. La récupération large du codebase est faite pour les vraies questions « où est X », pas pour « corrige cette fonction que j'ai déjà ouverte ». Un contexte précis est moins cher et produit de meilleures réponses — le modèle n'est pas distrait par douze fichiers presque corrects. C'est tout l'intérêt de la semantic code search : récupérer les symboles pertinents, pas les fichiers pertinents.
  2. Filtrez la sortie de terminal avant qu'elle n'entre dans le fil. Vous n'avez pas besoin de 200 lignes de tests qui passent ; vous avez besoin des échecs. Faites passer les commandes bruyantes par quelque chose qui garde le diagnostic et jette la décoration. C'est de l'output filtering, et sur une suite de tests instable, c'est souvent le gain unique le plus important.
  3. Élaguez vos serveurs MCP. Désactivez ceux que vous n'utilisez pas dans le projet courant. Chaque serveur connecté est un surcoût de manifeste à chaque tour. Charger les définitions d'outils à la demande — ne payer le manifeste d'un serveur que lorsque vous l'invoquez réellement — élimine la constante.
  4. Démarrez de nouveaux fils plus souvent. Quand la tâche change, ouvrez un nouveau fil Agent au lieu de continuer un monstre de 40 tours. Un fil propre ne traîne pas quarante tours d'historique refacturé. Traitez la longueur du fil comme un budget, pas comme une arrière-pensée.
  5. Demandez des skeletons, pas des fichiers entiers, pour vous orienter. Quand vous avez seulement besoin de connaître la forme d'un fichier — ses fonctions, ses exports, ses signatures — un skeleton de 300 tokens vaut mieux qu'une lecture complète de 6 000. Ne lisez le corps qu'une fois que vous savez de quel corps vous avez besoin.
Si faire tout ça à la main vous semble fastidieux, c'est parce que ça l'est. C'est exactement le genre de discipline mécanique qu'un outil devrait imposer à votre place — ce qui est la raison pour laquelle j'en ai construit un.

Un outil peut-il le faire automatiquement ?

Oui — automatiser ces quatre leviers est précisément ce que fait Tokenade, c'est pourquoi je ne vais pas prétendre que la discipline manuelle est une vraie réponse à long terme. Tokenade se place entre votre agent et le modèle et applique les coupes ci-dessus sans que vous y pensiez : semantic code search au lieu de déversements de fichiers gloutons, output filtering sur les résultats de commandes bruyants, skeleton context compression pour les lectures d'orientation, et chargement MCP à la demande pour que les serveurs dormants cessent de facturer. Un dashboard d'économies vous montre les tokens qu'il a réellement récupérés, par session — parce qu'une promesse d'économies que vous ne pouvez pas mesurer n'est que du marketing. Il fonctionne avec Cursor, Claude Code, Codex, Copilot, Windsurf et le reste — les leviers sont agnostiques de l'outil, donc l'implémentation devrait l'être aussi. Il est source-available sous licence MIT, vous pouvez donc lire exactement ce qu'il fait à vos prompts avant de lui faire confiance ; je voudrais la même chose. Le tier gratuit couvre jusqu'à environ 20M de tokens par mois, ce qui est largement suffisant pour voir s'il s'amortit. Pro est à $9.90/mo (hors taxe) aux États-Unis — 9,90 €/mois (TTC) en France — avec trois sièges. Si vous avez déjà lu Les meilleurs optimiseurs de tokens pour Claude Code, vous savez où il se situe dans le paysage.

Ce qui tourne mal (anti-patterns)

Les modes d'échec sont surtout des sur-corrections, et ils valent la peine d'être nommés parce que mal couper le contexte est pire que de ne pas le couper. Affamer le modèle. Si vous coupez le contexte au point que le modèle ne voit plus la fonction qu'il édite, il hallucine le code environnant. L'objectif est de retirer le bruit — relectures redondantes, sortie décorative, manifestes d'outils dormants — pas de retirer le signal sur lequel le modèle raisonne. Un bon optimiseur coupe les coches de la suite de tests et garde l'assertion en échec. Faire confiance à @codebase pour être précis. La récupération indexée est approximative par conception. Elle renvoie ce qui est similaire, ce qui sur un gros monorepo signifie une généreuse portion de fichiers plausibles-mais-faux. Nommer le fichier que vous visez est à la fois moins cher et plus précis. Ne rien mesurer. « Ça semble moins cher » n'est pas une métrique. Sans un chiffre — tokens économisés par session, coût avant et après — vous ne pouvez pas dire si vos changements ont aidé, nui, ou rien fait. C'est pourquoi j'insiste sur un dashboard plutôt que sur un ressenti. Confondre caching et réduction. Le prompt caching remise le contexte répété à ≈10 % du prix input, ce qui tente les gens d'arrêter de se soucier de ce qu'il y a dans le prompt. Mais du bruit en cache reste du bruit que le modèle doit parcourir, et vous avez quand même payé pour l'écrire. Cachez après avoir élagué, pas à la place.
À voir aussi :

Jusqu’à 88 % de tokens en moins. Sans configuration.

Tokenade est la façon la plus simple de réduire ce que votre agent de code envoie au modèle — installez-le une fois, économisez sur chaque prompt. Compatible avec Claude Code, Cursor, Codex, Copilot et plus.