Over the last week, I’ve noticed a dramatic increase in my token consumption. Looking at the usage dashboard, the change seems to have started around 07.06.2026, even though my daily coding workflow has remained largely the same.
I understand that Composer 2.5 is more expensive than Composer 2.0, but I’m wondering whether others are seeing a similar increase in token usage.
Are there any best practices for keeping token consumption under control while still using Cursor intensively for software development? At the current rate, it feels like I could exhaust my monthly token budget within just a couple of weeks.
I’d be interested to hear how others are managing this and whether you’ve identified specific settings, workflows, or recent changes that have had a significant impact on token usage.
Hi @samlinux, Thanks for the post! I don’t notice any errors but it looks like you have a handful of super long running chats (I see that one chat had 65 messages that you sent). This is fine, but there’s a lot of tokens that are being read with each turn so even tho they are cached tokens and billed at a cheaper price, it’s definitely adding up. If you can start new chats more frequently, that would go a long way to reducing your usage.
We encourage 2.5 fast as a default over composer 2.5 regular because it’s snappy and an enjoyable experience with the speed, but if you are particularly conscious about conserving spend, perhaps it would be a good idea to use composer 2.5 regular instead of the fast speed.
Thanks @kevinn for the explanation. To be honest, I hadn’t realized that chat size could have such a significant impact. I’ll try to keep my conversations shorter and more focused going forward.
I have a couple of follow-up questions:
Can sub-agents be configured to use Composer Regular instead of Composer 2.5? If so, would that help reduce token consumption?
Does Plan Mode generally consume fewer tokens than Composer Mode, or does it mainly depend on the size of the generated output and context?
I’m trying to understand which settings and workflows have the biggest impact on token usage, especially since my consumption has increased dramatically over the last week.
My goal is to maintain a full-time coding workflow and make my monthly token budget last for the entire month, rather than running out after just a couple of weeks.
If by “Composer Regular” you mean Composer 2.5 with Fast mode turned off: yes, in the local IDE you can configure this for the explore sub-agents. Go to Cursor Settings > Agents > Subagents, then adjust the Explore subagent model. You can choose “Inherit from parent,” or select Composer and turn Fast off from the model picker/edit flow.
Be aware that the Explore Subagent is an important one but it is not the ONLY subagent model. Sometimes your agents will spin up subagents using other models when doing tasks other than exploring the codebase and it will try to pick the best model for the job (including frontier models where applicable). If you want to stop this behavior, you can just turn off the models in Cursor Settings → Models. If you turn a model off, your subagents won’t have access to it.
That can reduce spend, but mainly because regular Composer 2.5 has a lower cost per token than Composer 2.5 Fast. It does not necessarily reduce the number of tokens used. Sub-agents still consume tokens based on how much context they inspect, how many tool calls they make, and how much they return to the main agent.
For Plan Mode: it is not inherently “lower token” than Composer/Agent mode. Plan Mode researches the codebase and writes a plan before implementation, so it can use a meaningful amount of context and output tokens. It can reduce total usage when it prevents a bad implementation path or repeated retries, but the main drivers are still the selected model, context size, number of sub-agents/tool calls, and how much text/code gets generated.
Thanks for the suggestion to disable Fast Mode. With the regular mode, the process takes longer but appears to consume significantly fewer tokens.
As you know, I am using the Ultra plan. Yesterday was actually a relatively light coding day for me. I did not use the model for planning or documentation, as I handle those tasks with a different model. Despite that, I still consumed approximately 2–3% of my monthly allocation according to the usage dashboard.
This raises a concern for me: who is the Ultra plan intended for? A professional developer typically works with Cursor every day, often 5 days a week and around 8–9 hours per day. Even my current usage is lower than my normal workload before AI-assisted development.
My concern is that even the highest-tier subscription may not provide enough capacity for a full month of regular professional use. If that is the case, it suggests one of two things:
The model’s token consumption is too high relative to the included limits.
The included limits are too low for the price of the subscription.
Either way, a developer willing to purchase the highest available plan should be able to rely on it for daily work throughout an entire month without regularly hitting limits or facing unpredictable additional costs.
I would be interested to understand how Cursor envisions the Ultra plan being used by full-time developers and whether there are any recommendations for managing usage more effectively.
Hi @samlinux Thank you for sharing your feedback! While our plans are designed to provide a lot of value at each plan offering level, it’s understandable that some power users on Ultra may surpass the included usage of their plan prior to the end of the month. That’s not unusual for power users. We offer on-demand usage as a stopgap for users to continue to use Cursor once they’ve exhausted their included usage until their cycle resets.
Some tips for conserving usage:
Start new chats often
Monitor your context window by clicking on the circle in the prompt box and pressing View Report. If anything looks unusual or you have hundreds of skills, this could be eating up a lot of your context.
Make sure you’re using the right model for the job (e.g. don’t use Fast mode unless you need it)
Sharing a few other things I’ve done recently to dramatically reduce my token count in case it’s helpful:
As Kevin mentioned - Keep threads short. Context compounds with every thread. My threads are at most 3-4 messages. For small features/bugfixes typically one then archive it. For larger features, typically Ask or Plan->Execute->archive. Do not keep running follow-ups in the same thread you’ll see your costs balloon dramatically.
I use Composer-2.5 (set to not fast) for almost everything. I tap Claude Sonnet for more complex (e.g. 3D tech art challenges that require some taste/complex reasoning).
I workshop my plan for complex tasks via chatGPT in advance and then have it summarize a ~10 line implementation spec. This allows me to do alot of back and forth before actually committing.
I use Ask prompts (no code written) to investigate complex areas. Then use that same thread if i decide to implement (vs jumping in to execution immediately).
I use Plan prompts constantly for heavy / complex features. I refine the plan once or twice (usually w/ help of chatgpt to review) and feed back small response prompts before execution. If I have Sonnet generate the plan, I still switch to composer to execute.
Once per week (for big / long running projects) I have Cursor generate a plan to reduce token usage in my repo. It will audit my past 20-30 conversations, find patterns, and give me suggestions to reduce context bloat, make it eaiser for agents to navigate, etc. For example, it’ll find files that are getting grep’d/re-read constantly and suggest either breaking them up or adding documentation to reduce re-grep’s.
I make sure my documentation is setup for agents (not humans). I have slim README’s in every folder that contain a brief summray of the folder, key functions, etc. I have ‘router’ README’s in the root of my project. So agents just read a few short readme’s vs trying to read a ton of code to navigate the repo.
I work on alot of new projects so whenever I finish one, I have cursor take the best practices and update a template repo which i use for new projects. That way it doesn’t have to re-write boilerplate constantly or re-learn how to do server configuration, etc.
Thanks, these are excellent tips. I’m already using some of them, but I probably need to be more disciplined and consistent in applying them throughout my workflow.
