Bug/Help: Other Models % hits 100% while usage-export at published API rates only reconstructs ~65% — how to reconcile the meter?

What I’m seeing

On Cursor Ultra this cycle, the dashboard Other Models meter shows 100%.

I exported Usage CSV and reconstructed Included Gemini + Sonnet rows using Cursor’s published $/1M rates (input / cache write / cache read / output). The public-rate sum is about ~$260.

If Other Models included usage is the documented >= $400 API pool, ~$260 should be about ~65%, not 100%.

So I’m trying to understand whether the percentage meter is inaccurate / opaque, or whether there is another published rule that turns ~$260 of list-price Included usage into a full bar.

Why this looks like a usage-display problem

I am not asking the forum to process a refund, change a subscription, or access account billing tools.

I am asking how a user is supposed to verify that the Other Models % is correct when:

  1. Included rows in the export are labeled Included / Free rather than showing a clear per-line dollar valuation that sums to the % bar.

  2. Self-serve Usage/Spending UI has been moving away from transparent $ breakdowns for included usage.

  3. Recent forum reports already describe stuck / lagged / inconsistent usage percentages on Spending / summary meters (for example the Sep 2026 threads about usage hitting 100% with fewer tokens while $ cost is hidden, and Spending percentages stuck/incorrect).

What I already checked

  • Max Mode was No on the export rows I reconstructed (so this is not explained by a 1.2x Max Mode markup on those lines).
  • Effort labels like -high / thinking-high are present, but published docs/support wording has been that those labels do not change the published $/1M rates (they mainly increase token volume).
  • Kind flipping from Included to Free after the bar fills looks like post-cap labeling; it does not by itself explain why the bar reached 100% at ~$260 of public-rate Included spend.
  • Cycle start appears to be 7 Sep 2026 on my account.

Questions for staff / community

  1. Is the Other Models percentage supposed to equal (public-rate reconstruction of Included Other Models usage) / (documented >= $400 pool)?

  2. If not, what is the exact published formula for the % bar, and where is it documented?

  3. Until $ breakdowns are fully visible again for included usage, what is the recommended way to audit whether 100% is correct from the Usage export alone?

  4. If the bar can diverge from public-rate reconstruction, can the UI label that clearly (for example “internal cost units, not list-price $”) so users are not left guessing?

Attachments

  • Usage export CSV (for the public-rate reconstruction)
  • Screenshot of Other Models at 100%

Happy to add a short reconstruction method in a follow-up reply if useful. Looking for meter accuracy / reconciliation guidance, not a forum-side billing action.
01_cursor_usage_export.csv (26.5 KB)

Second Ultra account, same broken meter. Other Models is at 100% after about $127 of Opus at your published token rates. Included usage on that same account still shows about $127 used out of $400, with about $273 left. On-demand is off. Opus is locked anyway, and later Opus calls were dumped onto a Power user grant.

[email protected] ticket T-G12598 has replied four times. All four are from “Cursor’s AI Support Assistant”. It refuses to state the Other Models dollar limit, and it refuses to explain the $273 that is still sitting there. “Usage varies” does not reconcile a full bar with $273 left.

Your own staff have described Ultra as $400 of Other Models usage. $127 is not 100% of $400. If the bar is some other unit, write the formula in this thread. This post has had no staff answer since Sept 17.

@deanrie @condor email support is a loop. Answer the formula here.

I’m also noticing this issue as of this month using Opus 5.5 - it seems to be billing it at 3x the price.

Looks to be intended - they lowered API usage for those of us using Cursor thru SuperGrok subs - sucks no one told us about it cause I would not have renewed if I knew and would’ve just switched to a cursor direct sub. :woman_shrugging: feeling a bit scammed but whatever. not gonna renew supergrok thats for sure!

Jin_Zhang Thanks for confirming. Your numbers (~$127 of Opus at public rates, meter at 100%, Included still showing ~$127/$400) are the same pattern I’m seeing, so this doesn’t look like a one-account glitch.

Key points from my side, for staff and anyone else hitting this:

  1. My reconstruction: Included Gemini + Sonnet rows from the Usage export, priced at the published $/1M rates (input / cache write / cache read / output), come to about ~$260. Against the documented >= $400 Other Models pool, that is ~65%. The meter shows 100%.
    1. Support (AI Support Assistant, by email) confirmed in writing that:
    • Ultra includes at least $400 of Other Models usage per cycle
    • my ~$260 public-rate reconstruction is the correct public arithmetic
    • ~$260 against a $400 floor should be about 65%, not 100%
    • they have no second published rate card, pool size, or multiplier that explains the gap
    1. What has been ruled out:
    • Max Mode was No on every row (so no 1.2x markup)
    • -high / thinking-high do not change the published $/1M rates
    • Included flipping to Free is only post-cap labeling
    1. Support could not recompute the meter, could not give an internal per-line valuation, and closed the thread without explaining how 100% is reached.
      So two different accounts show the Other Models meter filling well before the public-rate total reaches $400, and support can’t state the formula.

@deanrie @condor could someone from staff post the actual formula behind the Other Models %? Specifically: is it (list-price cost of Included Other Models usage) / $400? If not, what else goes into it? Either answer would let users audit their own usage.

Another Ultra data point, this one early in the cycle, so it is not the post-cap Included → Free relabel.

Model: claude-opus-5-5-medium
The usage row shows 7.1M tokens and 5.2% under Other Models (parent row 5.7%, plus 0.5% for claude-sonnet-5-thinking-high). Tooltip for that Opus row:

  • Cache Read 6,210,692
  • Cache Write 821,946
  • Input 204
  • Output 57,948
  • Total 7,090,790

Published Opus 5.5 rates (Models & Pricing | Cursor Docs): $4 / $5 / $0.20 / $20 per million (input / cache write / cache read / output).

  • Cache read 6.210692 × $0.20 = $1.24
  • Cache write 0.821946 × $5 = $4.11
  • Input negligible
  • Output 0.057948 × $20 = $1.16
  • List-price total = $6.51

$6.51 / $400 = 1.6%. The meter shows 5.2%. If that column is percent of the documented $400 Other Models pool, 5.2% is $20.80, which is 3.2× the list-price total ($20.80 / $6.51).

That lines up with two other Opus reports in this thread, and not with a single flat multiplier for every model:

  • Jin_Zhang: ~$127 of Opus at published rates, Included still shows ~$127 / $400, Other Models meter already at 100%. 400 / 127 ≈ 3.15×.
  • Josh3: Opus 5.5 “billing at 3×”.
  • Matom: Gemini + Sonnet reconstruct to ~$260, which is ~65% of $400, while the meter shows 100% (about 1.5×, not 3×).

So on this account the gap is visible on one Opus 5.5 aggregate, at ~5% of the bar, with Max Mode not involved and effort = medium. A flat “the pool is not $400” story does not fit both the ~3.2× Opus lines and the ~1.5× Gemini/Sonnet reconstruction. The per-model formula for the Other Models % is still unpublished.

They lowered the API usage to $100 for users who have cursor ultra through supergrok subscription, without telling any of us

I claimed Cursor Ultra through annual SuperGrok Heavy before the promotion ended. My dashboard still shows Ultra included.

Last cycle, my export shows about $427 of included Claude usage at Cursor’s published rates. This cycle, Other Models reached 100% when Opus 5.5 represented 97.7% of the meter and about $97.68 at those rates. Grok and Composer use a separate pool.

Cursor staff described Ultra as including $400 of Other Models before my purchase. For existing Heavy-linked Ultra accounts, is the apparent ~$100 limit intentional, or is the meter wrong? If intentional, when did it change and how were annual buyers notified?

Same issue here, I upgraded this morning and $24.55 of actual usage is showing as 26% of my Other Models usage. Feels like a complete waste of the money I just spent upgrading.

This can only be explained as a bug if Cursor literally says at least $400 of other model usage but the true usage is less than $25.

Would be great if someone from the team could shed some light on this @Colin or others.

Same Ultra account, same broken Other Models meter. SuperGrok-linked complimentary Ultra, dashboard still says Ultra, get-plan-info still returns includedAmountCents: 40000.

This cycle (16 Sep 2026 – 16 Oct 2026) my third-party usage at Cursor’s published API rates:

  • Claude 4.5 Sonnet $6.17
  • Claude Opus 5.5 $0.76
  • Gemini 3.1 Pro $0.36
  • Gemini 3.8 Flash $0.01
  • Total $7.30

Cursor’s own totalCents matches those list prices 1.000x. No 3x token markup.

The UI says “You’ve used 7% of your included API usage.” apiPercentUsed is 7.3%.

$7.30 ÷ 7.3% = $100.

If the documented pool were still $400, that bar would be 1.8%.

So this account is storing $400 on the plan object and running the Other Models percentage against $100. Same product name. One-quarter the API allowance. No changelog, no email, no dated notice.

This matches the SuperGrok Ultra ~$100 reports already in this thread, and the user who upgraded this morning and already sees ~$24.55 as 26% (also ~$100). That is not “promo Ultra is a different product” unless staff will write that down.

@Colin @deanrie what is the exact Other Models denominator on Ultra this cycle? When did it change from $400? Are SuperGrok-linked Ultra and paid Ultra supposed to be different pools? If they are the same plan, restore the $400 pool or credit the difference. If they are not, put it on the Spending tab.

I already emailed hi(at)cursor.com from the account mailbox with the same reconstruction. Ticket-style AI replies that say “usage varies” do not reconcile 7.3% of $100.

Paid Ultra, bought from Cursor directly. Not SuperGrok Heavy, and not a SuperGrok-linked complimentary Ultra.

Same cycle, three Included rows. Token counts are from the usage-breakdown tooltips (screenshots attached). Priced at the published Claude API rates, which match Cursor’s rate card: input / cache write / cache read / output per 1M tokens.

Opus 5.5 ($4 / $5 / $0.20 / $20), 8,193,992 tokens, UI 5.9%
cache read 7,200,467 → $1.44
cache write 928,530 → $4.64
input 230 → $0.00
output 64,765 → $1.30
list = $7.38

Fable 5.1 ($10 / $12.50 / $0.25 / $50), 579,288 tokens, UI 3.3%
cache read 270,677 → $0.07
cache write 302,517 → $3.78
input 18 → $0.00
output 6,076 → $0.30
list = $4.15

Sonnet 5 ($2 / $2.50 / $0.20 / $10), 1,023,905 tokens, UI 0.5%
cache read 884,381 → $0.18
cache write 123,286 → $0.31
input 24 → $0.00
output 16,214 → $0.16
list = $0.65

List total = $12.18
UI: 5.9% + 3.3% + 0.5% = 9.7%

Formula:
list = cacheRead/1e6cr + cacheWrite/1e6cw + input/1e6in + output/1e6out
apiPercentUsed = list / 125 * 100

$12.18 / 9.744% = $125. Against the documented $400 pool this bar would be $12.18 / $400 = 3.0%, not 9.7%. $400 / $125 = 3.2. The meter spends the allowance at 3.2× the published rate.

get-plan-info still returns limit 40000. includedSpend is 3751 ($37.51), about 3.1× the $12.18 list total, not 1.000×. autoPercentUsed is 0.84%, so this is not Auto spillover. These three rows are the whole 9.7% API bar.

{
“planUsage”: {
“totalSpend”: 3751,
“includedSpend”: 3751,
“remaining”: 36249,
“limit”: 40000,
“remainingBonus”: false,
“autoPercentUsed”: 0.8443333333333334,
“apiPercentUsed”: 9.744,
“totalPercentUsed”: 1.20032
},
“displayMessage”: “You’ve used 9% of your included usage”,
“namedModelSelectedDisplayMessage”: “You’ve used 10% of your included API usage”
}

This is the opposite of the SuperGrok case in the post above, where totalCents matched list price 1.000× and the percent implied a $100 pool. On this paid Ultra account the plan object still says $400, and both the percentage and includedSpend are about 3× the published Claude rates. @Colin @deanrie what denominator is apiPercentUsed using this cycle?



I have the same issue, I didn’t even buy with SuperGrokm just regular Ultra.

Hey all. Thanks for the reports and the details here.

We no longer publish specific dollar amounts for included usage, since it can vary by plan and change over time. You can always check your current usage percentage for both Cursor Models and Other Models under Plan & Usage (in the desktop app) or in the Spending tab at cursor.com/dashboard.

@nhugh the “at least $400 of Other Models usage” line in your screenshot comes from an older version of the Cursor app. This text was removed in 3.18.

1 Like

@Colin what does that mean? It means you get random 3rd party usage for the plans?

Shouldn’t the user know how much credits they have for a plan they buy?

Thanks for the response @Colin, that’s on me for not updating.

@Colin, thanks for replying. Adding a paid data point, because “amounts can vary” doesn’t answer when this changed or how paying subscribers were told.

Paid Ultra, billed by Cursor directly. Not SuperGrok.

  • Prior cycle (Aug 21 to Sep 21): $393 of Opus 5, Fable 5.1 and GPT-5.6 Sol usage at Cursor’s published rates. Every row Included, no on-demand, never capped.
  • Current cycle (from my Sep 21 renewal): Opus 5.5 + Fable 5.1 = $28.25 at published rates. Meter shows 22.6%. $28.25 / 0.226 = $125, the same 3.2x ratio @scottming found on his paid Ultra.

On no longer publishing dollar amounts: the Models & Pricing docs listed Ultra at $400 through at least Aug 24 (snapshot), then dropped the figure by Aug 29 (snapshot) with no changelog entry or email. Per your reply, the app itself said “at least $400” until 3.18. My account then renewed and received about a third of the prior cycle’s included value.

Three direct questions:

  1. What is the Ultra Other Models allowance for paid accounts this cycle, in dollars at published rates?
  2. On what date did it change from $400?
  3. How were existing paid subscribers notified before renewing?

Tickets T-G17338 and T-G21597 have received the same “usage varies” answer from both support and legal@.

I’ve been on all three individual tiers over the past month and exported the usage events from each. I’d like to understand how the numbers are supposed to reconcile, because I can’t make them do so.

What I exported

I pulled the per-request usage export for each plan. Columns are Input (w/o Cache Write), Cache Read, Output Tokens, Total Tokens. All three plans ran the same primary model (cursor-grok-4.6-high), Max Mode off throughout.

Plan Window Active days Requests Total tokens Output tokens
Pro ($20) Aug 30 – Sep 5 7 975 1,621,213,746 8,620,621
Pro+ ($60) Sep 7 – Sep 19 13 7,921 2,967,238,402 16,398,198
Ultra ($200) Sep 21 – Sep 26 6 5,811 4,098,987,387 12,736,320

Finding 1 — The token ratio is nowhere near 20x.

Normalizing to per-active-day, since the windows aren’t the same length:

Metric (per active day) Pro Pro+ Ultra Pro+/Pro Ultra/Pro Ultra/Pro+
Total tokens 231.6M 228.2M 683.2M 0.99x 2.95x 2.99x
Output tokens 1.23M 1.26M 2.12M 1.02x 1.72x 1.68x
Requests 139 609 969 4.37x 6.95x 1.59x
Tokens per request 1,662,783 374,604 705,384 0.23x 0.42x 1.88x

Total tokens: Ultra is 2.95x Pro over the same period. Output tokens — the part that’s actually new work rather than re-sent context — is only 1.72x. I understand the “20x” figure refers to the included dollar allowance ($400 vs $20), not tokens, but that’s exactly the confusion: the number quoted on the pricing page compares an allowance to a price, and users read it as capacity.

Finding 2 — Converting to a common rate doesn’t close the gap.

I repriced the same raw token counts under two rate cards. First Cursor’s own published rates (Grok 4.6: $2 input / $0.50 cache read / $6 output per 1M), then xAI’s public Grok 4.6 API rates on the same three token columns, per day:

Rate card Pro Pro+ Ultra Pro+/Pro Ultra/Pro Ultra/Pro+
Cursor published rates $131.9 $113.2 $336.5 0.86x 2.55x 2.97x
xAI public Grok 4.6 rates $138.8 $141.6 $383.3 1.02x 2.76x 2.71x
Implied ratio 0.95 0.80 0.88

Ultra comes out at 2.55x–2.76x Pro under both rate cards. Three different lenses — raw tokens, Cursor’s rates, xAI’s rates — land in the same 2.5x–3.0x band and nowhere near 20x.

Worth noting: repricing under Cursor’s own number is actually cheaper than xAI’s public rate (ratio 0.80–0.95). So I’m not claiming Cursor inflates unit prices. My question is about the ladder, not the price.

Finding 3 — The included allowance isn’t a ceiling.

Every plan burned well past its stated allowance over the period measured:

  • Pro: $923 of usage against a $20 allowance
  • Pro+ : $1,472 against $70
  • Ultra: $2,019 against $400

So the “included” figure isn’t a hard cap — fine. But then what does it represent, if a $20 plan can consume 46x its allowance? And if sustained consumption well above allowance is normal, on what basis is “20x” a meaningful comparison?

Finding 4 — Plan tier doesn’t govern task weight, only total.

Filtering to the one model all three plans used heavily (cursor-grok-4.6-high):

Plan Requests Total tokens Tokens/request Tokens per output token
Pro 839 1,477,978,937 1,761,596 188.7x
Pro+ 780 2,188,407,381 2,805,650 203.1x
Ultra 683 690,931,884 1,011,613 261.8x

Nearly identical request counts, but Usage 3.3x apart. Pro+ averaged 2.8M tokens per request — heavier sessions than Ultra on the same model. The tier isn’t limiting how much context a request may carry; it’s limiting something else that I can’t identify from the export.

Finding 5 — Request count is a poor proxy for usage.

My own numbers: Ultra ran 969 requests/day vs Pro’s 139 (6.95x), yet consumed only 2.95x the tokens. A “request” here ranges from ~375K to ~1.7M tokens. If there’s a fair-use policy or a rate limiter operating on requests, it’s measuring a unit that varies 4.5x in cost.

What I’m asking

  1. How is a request billed? Is there a defined unit — a request, a token, a “usage unit” — and is it documented anywhere? The export gives me four token columns and a Cost field that only ever says Included, so I can’t reconstruct the accounting.
  2. What is the actual capacity ratio between Pro, Pro+, and Ultra? Not the allowance ratio — the capacity ratio. If I run identical workloads on all three, what multiplier should I expect before hitting a wall?
  3. Why does the “20x” figure compare Ultra’s allowance to Pro’s price? $400/$20 = 20x, but $60 buys $70 and $200 buys $400, so the allowance-to-price ladder isn’t linear. Quoting 20x invites the reading that Ultra is 20x the product.
  4. What are the pool boundaries? I can see Grok Bot usage appearing in my exports with no cost attributed. Which pools are separate, which are shared, and does on-demand billing begin at the allowance figure or at some other threshold?
  5. Is the export itself complete? Should the Cost column show rates for included usage, so users can verify their own accounting?

I’m not accusing anyone of anything — I like the product and I’m paying for the top tier. But a $200 plan where I genuinely cannot determine what I’m buying relative to the $20 plan is a problem, and I don’t think I’m the only one who’s confused. If I’ve misread the docs or made an error in the analysis, I’d genuinely like to be corrected, and I’ll say so publicly.

Happy to share the raw exports or the analysis if that’s useful. Would a Cursor team member be able to clarify the intended accounting?

By the way, I cannot use the credit balance of $100 with any models, including Groks and others.

One of my accounts signed up through the “Come back for Grok Bot – Your first month is 50% off” offer and has the same situation: only a $125 Other allowance. What’s the point of running a promotion like that? Isn’t “50% off” misleading? You get a discount, but the allowance is also cut way down. It’s the same Ultra plan — another one of my accounts used the same promo and got a $250 Other allowance, and the two were only a day apart.

Thanks for the response, Colin.

There are two likely explanations here, and both require remediation for affected customers:

  1. There is a billing bug
  2. Cursor cut included usage by ~3x without communicating it, while continuing to charge the same price

Whether Cursor currently publishes a specific dollar amount for included usage is irrelevant. My $200/mo Ultra plan consistently provided approximately $400/mo of Other Models usage.

This is mathematically verified below. For June, July, and August, dividing total model cost by the usage percentage produces $400 every month. In September, Cursor exhausted my included usage after only ~$125, or 31% of the historical allowance.

Please escalate this to the billing and engineering teams. If this is not corrected and affected customers refunded, the next escalation could be legal, including potential class-action claims.