I would like to propose a feature improvement related to the current pricing and token usage policy for Cursor Pro. Specifically, I suggest implementing a rollover system where any unused premium request quota in a given month can be carried over to the following month, rather than being reset.
I understand this may appear to reduce short-term revenue potential by extending the usability of the existing quota. However, introducing such a system would significantly enhance the perceived value of Cursor Pro for users—especially for those whose workloads fluctuate month to month.
This change would reflect a strong user-first philosophy and could foster even deeper trust and loyalty within the developer community. In the long run, it could strengthen Cursor’s reputation and position as the go-to AI-driven coding tool.
Totally agree with this.
A rollover system would make Cursor feel like a tool that respects how developers actually work - some months are intense, others aren’t. Flexibility like this would turn Cursor Pro into a no-brainer to keep long-term.
@cursoradmin Even beyond individual users - our org has hundreds of people that are on Cursor and they don’t always use all their requiests, or they go on leave and the just fall through the cracks. Token or request usage should be more dynamic I have 250 seasts so I have paid for 1,25M requests. Just allow us to set some limits for users (like with the $) and let the rest draw from the pool.
If we pay for 500 requests for every user, that that should just be part of the organisational cap.
This is consumption that is paid for and not used is treated almost like like its a gym membership.
A much more equitable approached could be:
Roll over request for users from prior months (like some data phone plans). That would help manage fluctuating periods where we run out mid month in some teams.
Unused tokens are reclaimed by the organisational pool, and when people run out it depletes the organisational pool first before it consumes overage credits.
Allow admins to control tokens like we do with overage. Instead of giving every user 500 let us set the per user caps and manage the request pool ourselves. So organisation can set individual request limit and use the pool before we go for overage. This is important as we have a varied profile of users analysts, product and testers have different consumption profile to developers. Yet the limits are the same.
Gift tokens - so team members can send some of their tokens if their coleagues are blocked.
The counter agument - reasons for not doing this is that you are expecting people not to use their tokens so you actually benefit from underutilisation. This is like insurance companies, gyms and other memberships. Thats such a poor model for the customer, puts a lot of people off using the product becuase its not set up to encourage use. Have you accounted for 100 usage for each seat? Or have you banked those differences?
So tell me… in my situatin as the technical product owner for Cursor in my company - when I recieve complaints that individuals are out of tokens mid-month - yet I can see that there are people that dont use their limits - how is this an encouraging narrative for adoption?
We are instead having to consider offboading people for lack of consumption and shifting them to other products. It doesnt help you
100% agreed, this would make enterprise adoption far more compelling. With AI still a grey area in many orgs, we’re seeing pushback when costs look unjustified by under-used seats, especially when we can’t pool or reallocate requests :((
Yep. Its hard enough to demonstrate the AI value with existing telemetry without also having to justify irregular utilisation. It would be one less difficult conversation I have to have at budget time and saves me having to run regular license purges to keep things under control. We could hook up Claude Code to our bedrock account and just pay for what we use. At least its transparent.
