When I opened my public Cursor profile and saw roughly 1.1 billion tokens, the figure looked impressive even to me. I really do use Cursor a lot, sometimes for several hours at a stretch, but a billion in a month still made me stop and think: is this a normal volume for intensive work with AI, or am I simply hauling a gigantic context through the model for no good reason?
To work it out I exported the Usage CSV and looked at the structure of consumption. And here it was far more interesting than just a large number on a profile. A billion tokens by itself says almost nothing about how efficiently you work: what matters is which tokens they are, which models used them, how much of it was new context, and how much Cursor was simply rereading from cache.
What sits inside a billion tokens
The export contained 725 separate usage events and a total of 1,064,143,356 tokens. Of those, about 989.8 million, or 93%, was Cache Read. Ordinary Input was around 63.1 million, Cache Write — 4.6 million, and the models’ actual Output — only 6.6 million tokens.
That is a rather unusual proportion. On the surface you see more than a billion tokens, but only about 6% is new input, and the text and code the models actually generated takes up less than one percent of the total. The bulk is context Cursor had already seen and was feeding back to the model through the cache.
This is where the size of the number starts to make sense. I often run long Agent sessions in which the model works on one project for several hours: it studies files, changes code, starts the app, fixes bugs and comes back again to parts of the project it already knows. The context travels with the session the whole time, even when a large part of it is already cached.
Which models used the most
The main consumer turned out to be Grok 4.6 High — about 595.7 million tokens, more than half of my entire usage. Next comes Composer 2.5 with 264.7 million, then Claude Fable 5 Thinking — about 151 million. The remaining models account for a relatively small share.
There were also individual days of very high load. 14 August — 185.3 million tokens, 13 August — 184.8 million, 18 August — 144.6 million. On 13 and 14 August alone, roughly 370 million tokens passed through Cursor.
And there were only 17 active days in the CSV, so average consumption on a day when I was actually working in Cursor came to about 62.6 million tokens. At that level it is already hard to think of Cursor as merely a code editor with intelligent autocomplete. In my case it is increasingly a working environment in which several AI models are in fact doing a substantial share of the engineering.
A billion tokens and $20 on top
The most unexpected part of the analysis is cost. The Cursor Dashboard for the same period shows about 948.9 million Total Tokens, of which 946.2 million count as Included and only 2.7 million as On-demand.
In the CSV I found only five paid On-demand events, which together came to about $20.43 of extra spend. So I really was using Cursor very intensively, but almost all of that enormous volume sat inside included or free usage.
After that the question “how do I cut the number of tokens?” became much less interesting to me. If the system lets you run hundreds of millions of tokens without a proportional rise in cost, it makes more sense not to optimise the counter itself. What matters far more is something else: whether a long context is, over time, starting to degrade the Agent’s quality of work.
When a long session is useful
My longest Agent session ran for about nine hours, but the figure itself no longer frightens me. If the Agent is working on one large task the whole time, the accumulated context is more likely to help it. It knows the architecture, remembers earlier decisions, has already seen the errors, and understands why some implementation options were rejected.
If, for example, I am completely redoing a homepage, it is perfectly logical to run the whole cycle inside one chat: study the existing implementation, propose a new structure, write the components, adapt mobile, start the project, check the page in the browser, find problems and finish the final polish. Opening a new chat after every small change would only get in the way.
The problem does not start when the session gets long. It starts when the task changes and the old context keeps travelling with it. If after the homepage I start doing listings, then switch to SEO, then to Cloudflare, and in the same conversation suddenly begin wiring up Telegram, the Agent receives a huge amount of information that formally belongs to the project but barely belongs to the current task anymore.
One chat — one finished task
Which is why my main conclusion is: not one prompt — one chat, and not one project — one chat. One finished block of work — one chat.
A homepage can have its own Agent session. The brokers section — the next one. Listings — another. An infrastructure migration, SEO, a Telegram integration or a separate large API problem each get their own conversation. Inside each of those sessions it is perfectly normal to do dozens of iterations and stay there for several hours.
The boundary does not run between messages, or even between files, but between meaningful tasks. If the Agent has built a listing card and you need to tweak the mobile layout, a hover or a margin — that is still one task. If after that card I decide to rewrite the catalogue filtering architecture completely, it is already time to think about a new session.
For myself I have a simple indicator. If the next request starts roughly with “and now let’s also…”, it is worth checking whether this is really a continuation of the current task or already the start of the next one.
A new chat should not mean losing memory
A natural question follows: if you regularly start fresh sessions, how do you avoid explaining to Cursor, every time, the shape of the project, the design rules and the technical constraints?
The answer is that standing knowledge should not live exclusively in chat history at all. That is what Project Rules, User Rules and AGENTS.md are for. That is where it makes sense to put the project architecture, the stack, naming, directory structure, design rules, constraints, start commands, responsive requirements and everything else the Agent should know regardless of the specific task.
Then a new chat is no longer a restart of the project, but merely a clearing of working memory. The fundamental knowledge stays put, but dozens of old intermediate decisions, errors and discussions no longer occupy the current context.
That distinction, it seems to me, is especially important in intensive work with AI: there is the project’s long-term memory, and there is the working memory of a specific task. Mixing them in one endless conversation is not required.
A large task should be planned first
For small changes I usually put the Agent to work at once, but large tasks are worth starting in Plan Mode. If a change touches many files, several parts of the system, or needs architectural decisions, a few minutes of preliminary research can make the later implementation much simpler.
Instead of the command “rebuild the listings system”, for example, it is better first to let the Agent study the existing architecture, data, routing and dependencies, and then ask it to form a concrete plan. Once that plan has been checked, you can move to implementation.
That reduces the risk of a familiar scenario: the AI writes the first 30–40% of a solution very quickly, then discovers an architectural constraint and starts rewriting its own work. The larger the feature, the more useful it is to separate the stages of understanding the task and writing the code.
Subagents as a small team
For genuinely large tasks another layer appears — Subagents. The main Agent can keep the overall task and hand separate investigations to specialised agents with a context of their own.
The lead Agent, for example, is responsible for a new listings system. One subagent studies the existing architecture, another checks the API and data, a third does a code review, a fourth separately looks for problems in mobile and accessibility. The main Agent does not have to hold every intermediate action of those investigations — it needs their result.
The working model shifts a little as a result. Instead of one enormous AI chat you get a structure that looks like a small team, in which the main Agent plays coordinator and gathers the results of the individual specialists.
Code is not yet the result
Another conclusion concerns the end of a session. I am less and less inclined to treat a task as done at the moment the Agent reports that it has written the code.
A normal working cycle should continue: implement, run, check the result, find errors, fix them and check again. This matters especially for interfaces, where a change can look correct in the code and then fall apart in the browser or at a particular screen width.
If the Agent has access to the browser, console logs and network traffic, it makes sense to make it use those tools itself. Code generation is only an intermediate stage. The outcome should be a working, verified feature.
How to tell it is time to close the old chat
I see no point in an artificial limit such as “a new chat every hour” or “after a certain number of tokens you must reset”. The length of a session by itself says nothing about the quality of the context.
But the signs of its degradation are usually visible. The Agent starts forgetting constraints already agreed, asks again questions it has already had answered, touches files that do not belong to the task, brings back errors already fixed, or begins to contradict its own decisions. Sometimes the reason is simpler still: the current work has simply drifted too far from the original task.
At that point a new chat is not a loss of accumulated knowledge, if the long-term context has been properly moved into the project rules. It is merely a chance to give the model a clean space again for the next problem.
My working cycle with Cursor
In the end I arrived at a fairly simple sequence:
TASK → PLAN → BUILD → VERIFY → COMMIT → NEW CHAT
First, one clearly formulated task. If it is large — a separate planning stage. Then the Agent explores the project and implements the solution, after which it checks the result itself and fixes the problems it finds. When a finished piece of work has been verified, you can commit it and move to the next task in a fresh session.
Standing knowledge stays in Rules and AGENTS.md, and separate large investigations are handed to Subagents when needed. In that way architecture appears not only in the software project itself, but in the process of working with AI.
What the first billion taught me
At first 1,064,143,356 tokens looked like proof that I was using Cursor completely inefficiently. After unpacking the usage the conclusion was almost the opposite: about 93% of the volume was Cache Read, actual Output was less than one percent, and extra On-demand spend for the period was only about $20.
So my goal will definitely not be an attempt to cut usage at any cost. If a large volume of computation lets you do in a few days the work that used to take weeks, the token counter itself is not the problem.
What you need to optimise is the quality of context, the boundaries of tasks, and the Agent’s ability to take the work through to a verified result on its own. And perhaps a more important shift is happening here than another improvement in prompt engineering: we are gradually stopping learning how to talk to one model and starting to learn how to run AI agents as a full working system.
Discussion