Feature request for product/service
AI Models
Describe the request
The Problem With Cursor’s Weekly Reset Isn’t the Reset. It’s the Lack of Choice.
A weekly reset isn’t inherently bad. The problem is imposing it on everyone, regardless of how they work.
There are two fundamentally different types of users.
1. Users who automate everything.
They run agents, bots, and pipelines autonomously. For them, a weekly cap can be a useful safeguard. Their systems consume tokens rapidly, sometimes unpredictably, and usage limits help prevent runaway costs. For this group, the constraint makes sense.
2. Developers who work interactively with AI.
They write code alongside an agent, working through problems step by step. For them, a weekly cap isn’t protection. It’s friction.
You start a task, check your remaining usage, and wonder whether you’ll have enough to finish. Your attention shifts from solving problems to managing tokens. A persistent, low-level anxiety creeps into the workflow: Will I make it through the week?
That’s not an environment conducive to deep work or great software.
The billing model doesn’t help
There’s also a fundamental mismatch: we pay monthly, but our usable capacity is divided into weekly windows.
If you barely use your allocation during one week, that unused capacity doesn’t carry forward. You pay for a month, but your usage is effectively divided into four separate seven-day periods.
And when the marketing promises “at least double” the Pro usage, the framing becomes questionable. A larger monthly allowance doesn’t necessarily translate into greater practical freedom when access is constrained by weekly limits.
The distinction matters: total allocation and usable allocation aren’t the same thing.
A user request isn’t a universal requirement
Before October, weekly limits were something users had requested. That’s legitimate feedback, but a request from part of the user base doesn’t establish that everyone wants the same constraint.
Now, the weekly reset is the default, with no option to choose an alternative.
That’s the mistake: treating two fundamentally different workflows as if they were identical.
Autonomous usage and interactive development are not the same use case. They shouldn’t have to operate under the same constraints.
The solution is simple: give users a choice
Offer two options:
- Weekly reset: For users who want predictable usage boundaries and protection against runaway consumption.
- Monthly reset: For developers who need flexibility to work continuously without an arbitrary weekly deadline.
Let users decide which model fits their workflow.
Those who value the guardrails can keep them. Those who need uninterrupted development can opt out.
This isn’t an unreasonable demand for unlimited usage. It’s a request for control over how an existing subscription is consumed.
At this level, choice should be the baseline, not a premium feature.
The broader contradiction
One final observation, not an accusation.
SpaceXSI presents itself as an organization built around first-principles thinking: eliminate unnecessary friction, question inherited assumptions, and move faster by removing what doesn’t serve the mission.
Yet Cursor, under the same ownership, now imposes a constraint on day-to-day developers without giving them the option to opt out.
Perhaps the decision is driven by compute economics, capacity planning, or a broader product strategy. Without knowing the reasoning, it would be unfair to claim otherwise.
But the contrast is worth examining.
If the principle is to remove unnecessary friction, why introduce a rigid constraint that disrupts legitimate workflows when a simple user-controlled setting could accommodate both?
The issue isn’t weekly resets. It’s a one-size-fits-all policy in a product built around adapting AI to the way people work.
Give users the choice. Let the workflow determine the limit, not the other way around.