Cursor Ultra Limits: Check Usage Pools, On-Demand, and Spend Caps

You pay $200 a month for Cursor Ultra, yet a warning says you are nearing a limit. The costly mistake is to treat every percentage as one shared allowance and immediately switch spending to No Limit. First identify the counter that is moving, then decide whether uninterrupted work is worth extra pay-as-you-go charges, and only then set a monthly cap you can accept.

The key point: Ultra does not have one universal usage meter

As of September 27, 2026, Cursor says Pro, Pro Plus, and Ultra include two separate model-usage pools, and each pool resets with the monthly billing cycle: Cursor Models and Other Models. Ultra is listed at $200 per month and includes both pools, but the model you select changes how quickly included usage is consumed.

• Cursor Models currently covers Grok 4.7, Grok 4.6, Grok 4.5, and Composer 2.5. Cursor describes this pool as having significantly more included usage.
• Other Models covers explicitly selected third-party models, with usage calculated at each model’s API price.

That means “my Ultra usage is at 80%” is not a precise diagnosis. You need to know whether Cursor Models is running low, Other Models is running low, or a feature-specific weekly allowance is triggering the warning.

A user-posted X screenshot, for example, showed 72% monthly Cursor Models usage alongside a 90% Grok Bot weekly allowance. Those are different counters. A Grok Bot weekly warning does not by itself prove that either of Ultra’s monthly model pools has been exhausted.

Identify the counter before changing your plan or spending settings

The fastest reliable check is to match the warning location with the selected model and the billing record, rather than guessing how many tokens remain.

Signal you see	What it usually means	What to do next
Cursor Models percentage is rising	Grok or Composer usage is drawing from the Cursor Models pool	Check whether Other Models still has room and whether a model switch fits the task
Other Models percentage is rising	A selected third-party model is drawing usage at its API rate	Look for expensive models, long context, or high-frequency Agent work
Grok Bot shows a weekly warning	A weekly allowance for that Bot feature is close to its reset	Wait for the weekly reset or reduce that feature’s use; do not treat it as monthly Ultra depletion
Included Usage and On-Demand Usage appear separately	Subscription usage and extra metered usage are being tracked as different billing items	Confirm whether on-demand is enabled and whether a spend limit is set

A three-minute diagnostic you can verify

1. Open Cursor’s editor settings or usage dashboard and record both the Cursor Models and Other Models percentages, plus the monthly reset date. Cursor says both pools are visible in those locations.
2. Return to the latest heavy task and confirm the model you actually selected. Different models consume included value at different rates, so request count alone is not a cost measure.
3. In Billing & Invoices, compare Included Usage with On-Demand Usage. If the latter already has a value, you are generating charges outside the subscription’s included usage.
4. Open Spending and check whether on-demand is enabled, what the current monthly limit is, and whether it is set to No Limit.
5. Run one small, bounded task—such as a single-file refactor—then check which pool or billing line moved. This turns “what is eating my allowance?” into an observable result.

When a pop-up is vague, rely on your dashboard’s two pools and billing lines. A screenshot, a chat answer, or one warning banner cannot replace the live data for your account.

When on-demand usage is a sensible choice

On-demand is worthwhile only when the value of avoiding an interruption is greater than the extra amount you are willing to pay. Cursor’s usage-based charges documentation says individuals must explicitly enable on-demand; requests beyond included usage are billed at API rates and shown separately from the subscription.

It is usually a reasonable option when all three conditions are true:

• You have a deadline-bound release, repair, or migration whose delay has a measurable cost.
• The remaining work is bounded—for example, two code reviews or one defined module—not an open-ended Agent loop.
• You will check usage after each heavy task and can stop when the budget is reached.

Keep it off for now when any of these are true:

• You have not identified which pool is being consumed.
• Several Agents, automations, or long-context jobs are running in parallel, making the spend difficult to predict.
• You have a hard personal budget or can defer the work until the next billing cycle.
• The other included pool still has room and contains a suitable model for the current task.

Enabling on-demand does not restore “unlimited” model use. It authorizes continued metered billing after included usage. It solves continuity; it does not solve cost control by itself.

How to choose a spend cap without guessing

The safest cap is not a supposed platform recommendation. It is the maximum extra amount you are willing to pay during the current billing cycle. In the dashboard’s Spending tab, you can set an individual monthly limit after enabling on-demand. Cursor’s spend-limit documentation states that selecting No Limit removes that cap.

Use this budgeting method for a first limit:

1. Count the heavy development sessions still expected in the billing cycle, rather than simply counting calendar days.
2. Decide the total extra amount you can accept.
3. Divide that amount by the remaining heavy sessions to create a review threshold.
4. Set the total monthly cap in Cursor, then compare actual usage with your review threshold after each session.

For example, suppose you can accept no more than $40 of extra usage and expect ten heavy Agent sessions before reset. Treat $4 per session as a manual review threshold. It is not a Cursor per-session limit or a cost guarantee; it is an early-warning rule for spotting a task whose consumption is unusually high.

Two spend-limit details matter

First, a limit change takes effect immediately, but enforcement is not instantaneous. Cursor says usage may briefly exceed the limit before the system recognizes it. The limited pre-enforcement overage is recorded as a temporary spend-limit credit, and billing remains capped at the current limit.

Second, if you raise the limit during the same billing cycle, Cursor may bill some or all of that previously credited amount, up to the new limit. To preserve the credit, leave the limit unchanged or turn off on-demand.

For a solo builder, a finite cap is therefore usually safer than No Limit. Remove the cap only when you consciously accept open-ended spending under this control for the rest of the cycle and will actively monitor the bill.

Continue paying or change the coding workflow?

The right choice depends on which pool is falling, whether the task is urgent, and whether the pattern is a one-off spike or repeats every month.

Current situation	Prefer this action	Why
Cursor Models is nearly empty; Other Models still has room	Move only suitable difficult tasks to a third-party model and keep routine work on Cursor Models	You can use the second pool, but third-party models draw value at their own API rates
Other Models is nearly empty; Cursor Models still has room	Move routine coding, rewrites, and exploration to Grok or Composer	Use the remaining included pool and reserve a costly third-party model for work that truly needs it
Both pools are near their limits, with one short deadline left	Enable on-demand with a finite monthly cap	The value of continuity is clear, and the downside has a boundary
Both pools run low early every month, with parallel Agents or automation	Reduce concurrency, shorten context, and batch tasks for one billing cycle before raising the cap again	A recurring workflow problem is unlikely to be fixed by a one-time limit increase
Most work is completion, mechanical editing, or local changes	Prefer Tab and smaller scoped tasks	Ultra includes unlimited Tab completions, so Agent usage can be reserved for harder decisions

Cursor’s broad guidance on the same page says daily Tab users typically stay within included usage, limited Agent users often do as well, daily Agent users typically generate $60–$100 per month in total usage, and power users running multiple Agents or automation often generate $200 or more. These are categories, not a prediction of your bill. Actual on-demand cost still depends on the selected models, token volume, context length, and workflow.

Decide by task value, not by the $200 already paid

The Ultra subscription is a sunk cost. It should not be the sole reason to keep adding metered charges. Ask three questions for each heavy task:

1. How much manual time or deadline cost will finishing now avoid?
2. Can a model in the other included pool do the job without an unacceptable quality loss?
3. If another paid attempt still does not finish the work, at what amount will I stop?

When all three answers are clear, capped on-demand usage can be more rational than an abrupt interruption. When the third answer is unclear, changing the workflow first is safer.

A practical order of operations for today

Follow this sequence so that spending does not precede diagnosis:

1. Identify the warning source: Cursor Models, Other Models, Grok Bot, or the billing page.
2. Record both monthly pools: save the current percentages and reset date instead of relying on one combined impression.
3. Match models to tasks: find the selected models, parallel Agents, and long-context jobs behind the largest recent work.
4. Check billing categories: confirm whether Included Usage and On-Demand Usage are already moving separately.
5. Set the budget before the switch: choose the maximum extra amount for this cycle, then enable on-demand with a finite cap.
6. Run a bounded test: complete one clearly scoped task and check the two pools and billing again.
7. Scale only after review: increase task size or the cap only when both the result and the consumption are acceptable.

Success is not merely making the warning disappear. Success means you can explain which pool is being consumed, why extra charges are growing, and the exact amount at which work must stop.

Common questions about Cursor Ultra limits

Does 90% Grok Bot usage mean Ultra is almost exhausted?

Not necessarily. A weekly Grok Bot allowance and the monthly Cursor Models and Other Models pools are different counters. Check both model pools in the usage dashboard before concluding that Ultra’s included usage is nearly gone.

Does No Limit make Cursor unlimited?

No. No Limit only removes the monthly cap on on-demand spending. Requests beyond included usage remain billable at the applicable rates. Ultra’s unlimited Tab completions also do not make every Agent or model request free and unbounded.

Can usage continue after I reach the spend cap?

Cursor says enforcement is not instantaneous, so usage can briefly exceed the cap. The limited overage before enforcement is treated as a temporary credit, and you are billed up to the current limit. Raising the limit in the same cycle can turn some or all of that credit into billable usage, up to the new limit.

Can I estimate remaining work from the used percentage alone?

Not reliably. Model API price, context length, output length, and concurrency all affect consumption. A small, bounded task followed by a dashboard check gives you a more useful estimate for the rest of the cycle.

The decision rule to remember

Check the pool before enabling metered use, and set the budget before increasing the limit. For a heavy solo developer, the most controllable default is usually a finite cap, high-value work assigned to the right pool, and a usage review after every expensive task—not an immediate switch to No Limit.