Quand j’ai ouvert mon profil public Cursor et que j’y ai vu environ 1,1 milliard de tokens, le chiffre m’a impressionné moi-même. J’utilise effectivement beaucoup Cursor, parfois plusieurs heures d’affilée, mais un milliard en un mois m’a tout de même fait réfléchir : est-ce un volume normal pour un usage intensif de l’IA, ou est-ce que je fais simplement transiter sans raison un contexte gigantesque par le modèle ?
Pour comprendre, j’ai exporté le CSV d’utilisation et étudié la répartition de la consommation. C’était bien plus intéressant qu’un gros chiffre sur un profil. Un milliard de tokens, en soi, ne dit presque rien de l’efficacité : il faut savoir de quels tokens il s’agit, quels modèles les ont utilisés, quelle part correspondait à du nouveau contexte et quelle part Cursor relisait simplement depuis le cache.
Ce que contient un milliard de tokens
Mon export contenait 725 événements d’utilisation distincts et un total de 1 064 143 356 tokens. Parmi eux, environ 989,8 millions, soit 93 %, de Cache Read. L’Input ordinaire représentait environ 63,1 millions, le Cache Write, 4,6 millions, et l’Output directement produit par les modèles, seulement 6,6 millions de tokens.
La proportion est assez inhabituelle. En surface, on voit plus d’un milliard de tokens, mais seuls environ 6 % sont du nouvel input, et le texte et le code générés directement représentent moins de 1 % du total. L’essentiel est du contexte que Cursor avait déjà vu et renvoyait au modèle via le cache.
C’est là qu’on comprend l’origine d’un tel chiffre. J’utilise souvent de longues sessions Agent où le modèle travaille plusieurs heures sur un même projet : il étudie les fichiers, modifie le code, lance l’application, corrige les erreurs et revient sur des parties déjà connues. Le contexte voyage sans cesse avec la session, même si une grande partie est déjà en cache.
Quels modèles ont le plus consommé ?
Le principal consommateur était Grok 4.6 High, environ 595,7 millions de tokens, soit plus de la moitié de ma consommation totale. Vient ensuite Composer 2.5 avec 264,7 millions, puis Claude Fable 5 Thinking, environ 151 millions. Les autres modèles représentent une part relativement faible.
Certains jours ont aussi été particulièrement chargés. 14 août : 185,3 millions de tokens ; 13 août : 184,8 millions ; 18 août : 144,6 millions. Les seuls 13 et 14 août ont fait passer environ 370 millions de tokens dans Cursor.
Le CSV ne comptait pourtant que 17 jours actifs, soit une consommation moyenne d’environ 62,6 millions de tokens par jour d’utilisation réelle de Cursor. À ce niveau, il devient difficile de voir Cursor comme un simple éditeur de code à autocomplétion intelligente. Pour moi, il devient de plus en plus un environnement de travail où plusieurs modèles d’IA effectuent réellement une part importante du travail d’ingénierie.
Un milliard de tokens et 20 $ en plus
La partie la plus inattendue de l’analyse concerne le coût. Pour la même période, le tableau de bord Cursor affiche environ 948,9 millions de Total Tokens, dont 946,2 millions classés Included et seulement 2,7 millions en On-demand.
Dans le CSV, je n’ai trouvé que cinq événements On-demand payants, pour un total d’environ 20,43 $ de dépenses supplémentaires. J’ai donc réellement utilisé Cursor de manière très intensive, mais presque tout ce volume énorme relevait de l’usage inclus ou gratuit.
Après cela, la question « comment réduire le nombre de tokens ? » m’a beaucoup moins intéressé. Si le système permet de traiter des centaines de millions de tokens sans hausse proportionnelle des coûts, ce n’est pas le compteur lui-même qu’il faut optimiser. Une autre question importe bien davantage : le long contexte ne finit-il pas par dégrader la qualité du travail d’Agent ?.
Quand une longue session est utile
Ma plus longue session Agent a duré environ neuf heures, mais ce chiffre ne me fait plus peur en soi. Si Agent travaille tout ce temps sur une seule grande tâche, le contexte accumulé l’aide plutôt. Il connaît l’architecture, se souvient des décisions précédentes, a déjà vu les erreurs et comprend pourquoi certaines solutions ont été rejetées.
Si je refais entièrement une page d’accueil, par exemple, il est logique de mener tout le cycle dans un seul chat : étudier l’existant, proposer une structure, écrire les composants, adapter le mobile, lancer le projet, vérifier la page dans le navigateur, trouver les problèmes et achever les finitions. Ouvrir un nouveau chat après chaque petite modification ne ferait que gêner.
Le problème ne commence pas quand la session devient longue, mais quand la tâche change alors que l’ancien contexte continue de l’accompagner. Si, après la page d’accueil, je passe aux annonces, puis au SEO, puis à Cloudflare, avant de brancher soudain Telegram dans la même conversation, Agent reçoit une énorme quantité d’informations qui concernent formellement le projet, mais presque plus la tâche en cours.
Un chat, une tâche complète
D’où ma conclusion principale : ni un prompt par chat, ni un projet par chat. Un bloc de travail complet par chat.
La page d’accueil peut avoir sa propre session Agent, la section des courtiers une autre, les annonces encore une autre. Une migration d’infrastructure, le SEO, l’intégration Telegram ou un gros problème d’API méritent aussi leur conversation. Dans chacune, il est tout à fait normal de faire des dizaines d’itérations et de rester plusieurs heures.
La frontière ne passe ni entre les messages ni même entre les fichiers, mais entre les tâches cohérentes. Si Agent a créé une fiche de bien et qu’il reste à ajuster la mise en page mobile, le survol ou un espacement, c’est toujours la même tâche. Si je décide ensuite de changer entièrement l’architecture des filtres du catalogue, il faut envisager une nouvelle session.
Je me suis donné un indicateur simple. Si la demande suivante commence à peu près par « et maintenant, faisons aussi… », il faut vérifier si elle poursuit réellement la tâche en cours ou en ouvre déjà une autre.
Un nouveau chat ne doit pas signifier une perte de mémoire
Une question se pose naturellement : si l’on ouvre régulièrement de nouvelles sessions, comment éviter de réexpliquer chaque fois à Cursor la structure du projet, les règles de design et les contraintes techniques ?
La réponse est que les connaissances permanentes ne devraient jamais être stockées exclusivement dans l’historique du chat. C’est à cela que servent Project Rules, User Rules et AGENTS.md. C’est là qu’il est logique de placer l’architecture du projet, la stack, les conventions de nommage, l’arborescence, les règles de design, les contraintes, les commandes de lancement, les exigences responsive et tout ce qu’Agent doit connaître indépendamment de la tâche.
Un nouveau chat n’est alors plus un redémarrage du projet, mais simplement un nettoyage de la mémoire de travail. Les connaissances fondamentales restent en place, mais des dizaines d’anciennes décisions intermédiaires, erreurs et discussions n’occupent plus le contexte actuel.
Cette distinction me paraît particulièrement importante dans un usage intensif de l’IA : il y a la mémoire à long terme du projet, et il y a la mémoire de travail d’une tâche précise. Rien n’oblige à les mélanger dans une conversation sans fin.
Une grande tâche mérite d’abord un plan
Pour de petites modifications, je lance généralement Agent directement, mais les grandes tâches gagnent à commencer en Plan Mode. Si le changement touche de nombreux fichiers, plusieurs parties du système ou exige des choix d’architecture, quelques minutes d’étude préalable peuvent beaucoup simplifier la suite.
Au lieu d’ordonner « refais le système d’annonces », mieux vaut laisser Agent étudier l’architecture, les données, le routage et les dépendances existants, puis lui demander un plan concret. Après vérification de ce plan, on peut passer à l’implémentation.
Cela réduit le risque du scénario classique où l’IA écrit très vite les premiers 30 à 40 % de la solution, puis découvre une contrainte d’architecture et réécrit son travail. Plus la fonctionnalité est grande, plus il est utile de séparer les étapes de compréhension de la tâche et écriture du code.
Les Subagents comme petite équipe
Pour les tâches vraiment importantes apparaît un niveau supplémentaire : Subagents. L’Agent principal peut garder la tâche globale et confier les recherches distinctes à des agents spécialisés disposant de leur propre contexte.
Par exemple, l’Agent principal est responsable d’un nouveau système d’annonces. Un subagent étudie l’architecture, un autre vérifie l’API et les données, un troisième relit le code, un quatrième cherche les problèmes de mobile et d’accessibilité. L’Agent principal n’a pas besoin de conserver chaque action intermédiaire de ces recherches, mais leurs conclusions.
Le mode de travail change alors un peu. À la place d’un immense chat d’IA apparaît une structure de petite équipe, où l’Agent principal coordonne et rassemble les résultats de spécialistes distincts.
Le code n’est pas encore le résultat
Une autre conclusion concerne la fin de session. Je considère de moins en moins la tâche comme terminée lorsqu’Agent annonce qu’il a écrit le code.
Un cycle de travail normal doit se poursuivre : implémenter, lancer, vérifier le résultat, trouver les erreurs, les corriger et vérifier de nouveau. C’est particulièrement important pour les interfaces : un changement peut sembler correct dans le code, mais se casser dans le navigateur ou à une largeur d’écran donnée.
Si Agent a accès au navigateur, aux journaux de console et au trafic réseau, il est logique de lui faire utiliser ces outils lui-même. La génération de code n’est qu’une étape intermédiaire. Le résultat doit être une fonctionnalité opérationnelle et vérifiée.
Comment savoir quand fermer l’ancien chat
Je ne vois pas l’intérêt d’une limite artificielle comme « un nouveau chat toutes les heures » ou « un reset obligatoire après un certain nombre de tokens ». La durée d’une session ne dit rien, à elle seule, de la qualité du contexte.
Mais les signes de dégradation sont généralement visibles. Agent oublie les contraintes convenues, repose des questions déjà traitées, touche des fichiers sans rapport avec la tâche, réintroduit des erreurs corrigées ou contredit ses propres décisions. Parfois, la raison est encore plus simple : le travail actuel s’est trop éloigné de la tâche d’origine.
À ce stade, un nouveau chat ne fait pas perdre le savoir accumulé si le contexte à long terme est correctement consigné dans les règles du projet. C’est simplement une occasion de redonner au modèle un espace propre pour résoudre le problème suivant.
Mon cycle de travail avec Cursor
J’ai finalement abouti à une séquence assez simple :
TÂCHE → PLAN → CONSTRUCTION → VÉRIFICATION → COMMIT → NOUVEAU CHAT
D’abord, une tâche clairement formulée. Si elle est importante, une phase de planification distincte. Ensuite, Agent étudie le projet et réalise la solution, puis vérifie lui-même le résultat et corrige les problèmes trouvés. Quand un bloc de travail complet est vérifié, on peut le figer par un commit et passer à la tâche suivante dans une nouvelle session.
Les connaissances permanentes restent dans Rules et AGENTS.md, tandis que les grandes recherches distinctes sont confiées aux Subagents si nécessaire. Une architecture apparaît ainsi non seulement dans le projet logiciel, mais aussi dans le processus de travail avec l’IA.
Ce que m’a appris le premier milliard
Au départ, 1 064 143 356 tokens semblaient prouver que j’utilisais Cursor de façon totalement inefficace. Après analyse, la conclusion était presque inverse : environ 93 % de Cache Read, moins de 1 % d’Output réel et seulement une vingtaine de dollars de dépenses On-demand supplémentaires sur la période.
Mon objectif ne sera donc certainement pas de réduire la consommation à tout prix. Si un gros volume de calcul permet d’accomplir en quelques jours ce qui prenait auparavant des semaines, le compteur de tokens n’est pas un problème en soi.
Ce qu’il faut optimiser, c’est la qualité du contexte, les limites des tâches et la capacité d’Agent à mener le travail de manière autonome jusqu’à un résultat vérifié. Et il se produit peut-être là un changement plus important qu’une énième amélioration du prompt engineering : nous cessons progressivement d’apprendre à parler à un seul modèle pour apprendre à gérer les agents d’IA comme un véritable système de travail.
@nevsky_alexander
Sur Instagram, Dubaï au-delà de la carte postale : la famille, la ville, les trouvailles et la vie entre deux projets. Sur Threads, des réflexions à voix haute sur le design et l’IA. Sur YouTube, des vidéos qui ont besoin de plus de place qu’une story. Retrouvez-moi là où vous vous sentez bien, et gardons le contact