Where Cursor's Tokens Go, and How to Stop the Leak

Twenty dollars a month is what a Cursor Pro subscription costs, making it one of the most popular AI coding assistants. The sum looks modest, almost symbolic next to developer salaries. But behind that simplicity sits a complex billing mechanism that can turn a generous limit into a shortage long before the billing period ends. One user decided to find out exactly where the tokens go and shared the results of his investigation on Habr.

Token consumption in AI coding assistants is not just an accounting question. It is a fundamental feature of how modern language models are built, and it directly affects developer productivity. Each time Cursor calls the model, it sends not only your query but also context: fragments of open files, the conversation history, the results of project indexing. All of it is ground into tokens, and every token costs money. A user who simply types questions into the chat may not notice that behind the scenes the assistant chews through thousands of lines of code with every request.

The author audited his own use of Cursor and identified several key budget "eaters." The first and most obvious is the size of the context window. When you work on a large project with many files open, the assistant tries to take in as much information as possible, which bloats every request. The second factor is repeated and clarifying requests. An imprecise prompt produces an unsatisfactory answer, followed by another request, and another, each carrying the full context. The third is automatic indexing and background operations, which the user may not even notice but which steadily burn tokens.

This situation is not unique to Cursor. The entire market of AI coding assistants, from GitHub Copilot to Windsurf and Cline, faces the same dilemma: the more context the model gets, the better its answers, but the more expensive each request becomes. Tool makers balance quality against cost, and users end up hostage to that compromise. On a fixed $20 subscription, the request limit can run out in the first week of intensive work, while under a pay-as-you-go model the bill can deliver an unpleasant surprise at the end of the month.

Having grasped the scale of the problem, the author did not stop at stating the facts and built his own framework for optimizing token consumption. The core of the approach is deliberate context management. Instead of letting the assistant decide on its own which files to include in a request, the framework helps structure queries so the model gets exactly as much information as a given task requires. It is a kind of "diet" for the AI assistant: less superfluous context, more precise prompts, a minimum of repeated requests.

Such user initiatives signal an important shift in how AI tools are perceived. The era of thoughtless use, when developers simply "talked" to the assistant as they would to a colleague, is gradually giving way to a more engineering-minded approach. Programmers are starting to treat tokens as a computing resource to be optimized, just as they optimize memory, CPU time or network requests in their applications. A discipline of "prompt engineering for savings" is even emerging, where the goal is not just to get a good answer but to get it at minimal cost.

For the industry, this means that pricing for AI assistants remains an unsolved problem. Fixed subscriptions create an illusion of predictability but hide the real cost of use. Pay-per-token models are more honest but frightening in their unpredictable bills. The next generation of pricing plans will probably include more transparent usage metrics and built-in optimization tools, which is exactly what enthusiasts like the author of this study are now building by hand.

Twenty dollars a month is neither little nor much. It is just enough to make you think about how exactly you spend each token. And perhaps that awareness will ultimately turn ordinary users of AI tools into truly effective developers.