Le forfait Cursor à 20 $ vidé en un après-midi

L'après-midi où le porte-monnaie s'est vidé

Imaginez ouvrir Cursor un mardi, lancer une poignée de prompts vers un agent de coding, et regarder l'allocation d'un mois tout neuf s'évaporer avant le déjeuner. C'est à peu près ce qu'a décrit une vague d'utilisateurs Cursor Pro fin juin 2025 — et quelques semaines plus tard, le PDG de l'entreprise s'est assis pour écrire des excuses. Je trouve ces histoires utiles précisément parce que personne n'a rien fait de mal. Pas de boucle emballée, pas de tâche d'arrière-plan oubliée. Juste des développeurs utilisant un outil comme ils l'avaient toujours fait, après que le compteur en dessous a discrètement changé de forme.

Ce qui a changé le 16 juin

Pendant la majeure partie de son existence, le forfait Pro de Cursor vous vendait des requêtes. Comme l'entreprise l'a expliqué par la suite, il y avait une limite de 500 requêtes par mois, les modèles Sonnet coûtant deux requêtes chacun — donc en pratique vous obteniez de l'ordre de 225 tours Sonnet lourds, puis un repli plus lent mais illimité. Prévisible. Ennuyeux. Facile à budgéter. Le 16 juin 2025, tout a basculé. Le nouveau forfait Pro vous donnait, selon les propres mots de Cursor, "20 $ d'usage de modèles frontier par mois au tarif API" plus un usage illimité du mode Auto. Le piège caché dans cette phrase : seul le mode Auto restait illimité. Chaque fois que vous choisissiez vous-même un modèle frontier — exactement ce que font les utilisateurs avancés — vous dépensiez désormais de vrais dollars API à partir d'un porte-monnaie de 20 $. TechCrunch a résumé l'échange clairement : au lieu de 500 réponses rapides sur les modèles avancés puis un nombre illimité de réponses plus lentes, les abonnés obtiendraient désormais 20 $ d'usage par mois, facturés au tarif API. Même étiquette à 20 $ sur la boîte. Un contenu complètement différent à l'intérieur.

Pourquoi les 20 $ allaient bien moins loin

Voici le mécanisme, car le chiffre seul n'explique pas le choc. Sous la tarification par requête, une « requête » était une unité forfaitaire — un tour Sonnet coûtait deux de vos 500, point final, peu importe ce qu'il calculait réellement sous le capot. Sous la tarification API, vous payez les tokens : chaque token que vous envoyez et chaque token que le modèle écrit en retour. Et un tour d'agentic coding est énorme du côté de l'input. L'agent renvoie le system prompt, le context window rempli de vos fichiers ouverts, les tours précédents, les définitions d'outils et leur output — à chaque étape. Cursor l'a lui-même concédé : "les nouveaux modèles peuvent dépenser plus de tokens par requête sur des tâches à horizon plus long", et les requêtes les plus difficiles coûtaient un ordre de grandeur de plus que les simples. Donc les 20 $ s'étiraient très différemment selon le modèle que vous sollicitiez. Des analyses indépendantes du nouveau forfait l'estimaient à environ 225 requêtes Claude 3.5 Sonnet, 500 requêtes GPT-4o, ou 550 requêtes Gemini pour vos 20 $ — et bien moins avec les modèles Claude les plus récents et les plus voraces. La chose même qui rendait Cursor excellent pour le coding, les modèles Claude d'Anthropic, était la chose même qui vidait le porte-monnaie le plus vite. C'est ça, le piège. Personne ne budgète en tokens. On budgète en « je vais faire quelques heures de coding ». Quand le compteur en dessous est basé sur les tokens et que votre agent relit tout le dépôt à chaque tour, « quelques heures » et « 20 $ » cessent d'être la même phrase.

Ce que ça a réellement coûté aux gens

Les preuves n'étaient pas subtiles. Des utilisateurs ont signalé être à court après seulement quelques prompts en utilisant les nouveaux modèles Claude d'Anthropic, et des cas documentés d'un abonnement épuisé en une seule journée d'usage normal ont largement circulé. Pour ancrer l'économie des tokens : à l'époque, le modèle phare d'Anthropic, Opus 4 / 4.1, était affiché à 15 $ par million de tokens d'input et 75 $ par million de tokens d'output, avec Sonnet à 3 $ / 15 $. À ces tarifs, un porte-monnaie de 20 $ représente à peine quelques millions de tokens d'output d'Opus — et une session agentic qui re-bourre un gros context window à chaque tour dévore les tokens d'input à un rythme effrayant. Le calcul du coût en tokens des agents de coding IA est brutal dès que l'input domine la facture, ce qui est presque toujours le cas. (Pour les tarifs sous-jacents par modèle, notre analyse des tarifs des tokens d'API LLM fait référence.) La réaction est devenue assez bruyante pour que, le 4 juillet 2025, le PDG d'Anysphere Michael Truell publie un mea culpa public : "Nous reconnaissons que nous n'avons pas bien géré ce déploiement tarifaire et nous en sommes désolés. Notre communication n'était pas assez claire et a surpris beaucoup d'entre vous." L'entreprise a proposé des remboursements pour l'usage imprévu entre le 16 juin et le 4 juillet, orientant les utilisateurs concernés vers une adresse de support tarifaire dédiée.

Ce qu'une discipline sur les tokens aurait changé (une estimation)

Soyons honnêtes sur ce qui est réparable ici et ce qui ne l'est pas. Vous ne pouvez pas vous soustraire au changement de tarif de quelqu'un d'autre. Ce que vous pouvez changer, c'est le nombre de tokens que votre agent brûle pour faire le même travail — et sous le nouveau compteur basé sur les tokens, c'est tout l'enjeu. Le coût dominant en agentic coding est l'input : les mêmes fichiers, le même historique et le même output d'outils renvoyés à chaque tour. C'est là qu'est le levier. Concrètement :

• Ne donnez pas des fichiers entiers au modèle. Lire un fichier de 400 lignes pour confirmer une seule signature de fonction est du pur gaspillage. Envoyer un squelette ou le symbole correspondant à la place peut réduire une lecture de 80 à 95 %.
• Mettez en cache le préfixe stable. Avec le prompt caching, le system prompt inchangé et le contexte projet coûtent une fraction à chaque tour suivant au lieu du plein tarif à chaque fois.
• Élaguez les outputs d'outils verbeux avant même qu'ils n'atterrissent dans le contexte.

Ce sont exactement les leviers de notre guide pour réduire l'usage de tokens d'un agent de coding IA. À titre d'estimation étiquetée, et non de résultat mesuré : si les tokens d'input représentent 80 à 90 % d'une facture agentic — ce qui est typiquement le cas — et qu'une récupération disciplinée plus du caching réduisent l'input de 40 à 60 % de façon conservatrice, alors une session qui vidait le porte-monnaie de 20 $ en un après-midi aurait duré de l'ordre de deux à trois fois plus longtemps pour le même travail. Cela n'annule pas le changement de tarif. Cela signifie que le compteur tourne bien plus lentement face aux mêmes 20 $.

La leçon : le compteur a changé, alors changez la combustion

L'épisode Cursor n'est pas vraiment l'histoire d'une entreprise qui a mal tarifé et s'est excusée — elle l'a fait, et elle s'est excusée. C'est l'histoire de ce qui arrive à tout le monde le jour où un outil à forfait devient un outil au compteur de tokens. Le travail n'est pas devenu plus cher. La comptabilité est devenue honnête. Et une comptabilité honnête des tokens punit la façon dont la plupart d'entre nous laissons les agents travailler — en relisant tout, à chaque tour, en entier. Vous ne pouvez pas contrôler le moment où Anthropic, OpenAI ou un éditeur d'outils repositionne le compteur. Vous pouvez contrôler combien de tokens le traversent. Tokenade se place entre votre agent de coding et le modèle et fait la part ingrate automatiquement : des squelettes au lieu de fichiers entiers, un output d'outils compacté, des préfixes cache-friendly — pour que le même travail envoie une fraction des tokens. Quand le prochain changement de tarif arrivera, une combustion plus légère est la seule couverture qui soit réellement entre vos mains. Commencer gratuitement → — et la prochaine fois que le compteur bouge sous vos pieds, vous le sentirez beaucoup moins.