Measuring a quota through a gauge that only shows tenths of a percent

Discussions
1

Cursor’s billing page reports Included Usage to one decimal place. Mine read 0.1% for nine days straight while my token count doubled underneath it.

That looks like a dead end. It isn’t. Four readings taken at different usage levels bound the answer more tightly than any single one of them can.

Here are the readings, all from the detailed Included Usage table under Billing & Invoices — not the summary card at the top of the page, which rounds to whole percents and cost me two published mistakes earlier.

Date Tokens consumed Displayed
Aug 22 314,959 0.1%
Aug 31 529,000 0.1%
Aug 31 658,500 0.1%
Aug 31 837,400 0.2%

What each reading tells you

A displayed 0.1% means the true value sits somewhere between 0.05% and 0.149%. That bounds the quota: if 314,959 tokens is at least 0.05% of the total, the quota is at most 630M. If it’s at most 0.149%, the quota is at least 211M.

Run that for every reading:

  • 314,959 at 0.1% → quota between 211M and 630M
    • 529,000 at 0.1% → between 355M and 1,058M
    • 658,500 at 0.1% → between 442M and 1,317M
    • 837,400 at 0.2% → between 336M and 558M
      All four have to be true of the same number at the same time. The only band that satisfies every constraint:

442M – 558M tokens per month, on a $20 plan.

The fourth reading is what made this useful. The first three only pushed the floor up. The moment the needle moved to 0.2%, it capped the ceiling — and cut the range from 188M wide to 116M.

I’d estimated ~315M earlier from a single reading and published it. That was wrong, and wrong in the direction I didn’t expect: the quota is larger than I thought, not smaller.

What it cost to move the needle

Two runs on the same small project, same model (cursor-grok-4.6-medium), same day.

Run 1 — build a CLI tool from scratch. A Python script that reads a Cursor usage export, aggregates per model, computes cache-read share, writes a summary CSV, and handles missing files and malformed columns.

Run 2 — extend it. Point it at a real export instead of the invented test data, add a fresh-input column, a totals row, and sorting.

Build from scratch Extend
Fresh input 52,691 (40.7%) 27,048 (15.1%)
Cache read 72,448 (55.9%) 147,072 (82.2%)
Output 4,429 4,697
Total 129,568 178,817

Extending cost 38% more than building.

I expected the opposite. Continuing a conversation should be cheaper — the context is already there, cache reads are cheap, less needs to be re-established.

The cache half of that was right. Cache share climbed from 56% to 82%. Fresh input nearly halved: 52,691 down to 27,048. By that measure the agent did roughly half as much new thinking the second time.

But cache read doubled in absolute terms, from 72,448 to 147,072. The re-reading grew faster than the new work shrank, and it dominated the total.

Half the thinking, twice the re-reading, 38% more tokens.

Caveat I should state plainly: the two tasks weren’t the same size. Run 2 bundled three separate features plus adapting to real-world data. This is one pair of runs, not a controlled experiment. What I’d claim is the shape, not the multiplier.

An asymmetry between two models in the same product

Same billing page, two models, six requests on one and two on the other:

cursor-grok-4.6-medium gpt-5.6-sol-medium
Cache write 0 in all six runs 22,485 and 321
Fresh input 25.2% of tokens 0.01% — six tokens out of 90,503
Cache read 72.9% 74.4%

The cache-read share is nearly identical. Everything else is inverted.

gpt-5.6-sol-medium writes cache and sends essentially no fresh input. cursor-grok-4.6-medium writes no cache at all and re-sends fresh input every time.

Neither behaviour is visible in the dashboard, which reports one aggregate token count per model. It only surfaces in the CSV export, where cache write, fresh input and cache read are separate columns.

I don’t know which approach is cheaper in dollars, because on Pro the Cost column reads Included for every row regardless of model.

The one dollar figure I could recover

The Other Models pool is documented as including at least $20 of usage. After two GPT-5.6 runs the detailed table reads 0.3% of it.

0.3% of $20 is $0.06 across two runs — roughly $0.03 per run. Rounding puts the honest range at $0.025 to $0.035.

That’s indirect, derived from a pool of known size rather than a printed price, and it’s the only dollar number I’ve been able to extract since upgrading.

What I’d still like to know

Whether 442M–558M matches anyone else’s numbers. The method needs nothing but two columns from your own billing page, taken a few days apart: tokens consumed and displayed percentage. Two readings at different tenths would narrow this further, and readings from an account with heavier usage would narrow it a lot.

If the band is wrong, I’d rather find out from your data than keep tightening around my own.

Eight requests. Small sample, stated up front. Raw CSV available.

4

Hey, great breakdown. The bounding method across multiple readings is really elegant. But there are a couple things that change the picture.

First and most important, Pro has two different pools, and they work differently.

  • Cursor Models pool includes Grok 4.6, Grok 4.5, and Composer 2.5. This is where your cursor-grok-4.6-medium came from.
  • Other Models pool is third party models at API rates, about $20 of included usage per month. This is where your GPT-5.6 runs land.

This breaks the main thesis. You derived your 442M to 558M from grok readings, meaning from the Cursor Models pool, but you labeled them as on the $20 plan. But the $20 is the Other Models pool, which is where your GPT-5.6 runs live, not grok. The included budget for the Cursor Models pool in dollars is not published. In the docs it is described as higher included limits, without a fixed dollar number. So the $20 figure just does not apply to grok readings. Your separate estimate of $0.03 per run for GPT-5.6 against $20 is correctly attributed.

Second, even within a single pool there is no single fixed token number per month. Both pools are dollar based. Pricing is per token and split by token type input, cache write, cache read, output all cost different amounts. For Cursor Models in the docs Models & Pricing | Cursor Docs it is input $0.50 to $4, cache read $0.20 to $1, output $2.50 to $15. So a token quota floats depending on the model and cache profile. Your 442M to 558M is a token equivalent of the spent share of the Cursor Models pool for your specific grok mix, not a universal number.

This also explains two observations.

  • +38% on extend makes sense if cache read is cheaper per token than fresh input. The absolute cache read increase hits the budget less than it hits the token count, but it still pulls total cost up.
  • The grok vs gpt asymmetry on cache write is interesting, but I will not go into internal model behavior to avoid guessing.

On cost column reads Included for each row, that is not Pro specific. On July 31, 2026 they intentionally removed dollar values from the Usage page for all self serve plans, including Teams. The Cost column and Spend metric were removed, CSV export no longer includes cost, and it also affected historical data. So you cannot pull per request and per model dollar breakdown from the Usage page by design. Context is in this thread Usage Page $$ to Token Amount? WHAT?.

What is actually available on Pro.

  • Dashboard > Spending shows only on demand costs, meaning usage above the included pools. If on demand is off and you stay inside included, it will show $0. There is no dollar remaining pool in the UI, only a percentage.
  • Cost fields via the Admin API exist, but they are Teams only, so not available for a solo Pro account.

And if you want to compare with other Pro users, here is a related thread on why different Pro accounts burn percentage at different speeds Why is my Cursor Pro usage limit much lower than other Pro users?.

5

This is the correction I needed — thank you. I conflated pools: the $20 I anchored to is Other Models, and my four readings were all Cursor Models (grok). So 442M–558M is a token-equivalent for my specific grok/cache mix against an unpublished budget, not a plan-wide quota. Editing the post to flag that.

Good catch on the July 31 change too. I’ll read through “Usage Page $$ to Token Amount? WHAT?” and see if my readings add anything there.

One thing I’d still like to pin down: is there any public number, even a range, for what the Cursor Models pool includes in dollar terms — or is “higher included limits” the full extent of what’s documented?

Also, the Request ID you asked for in the other thread: a6a45265-b6e2-4c12-8edb-0ea62a0911de — from a run-tracker session on Aug 31.

On the picker point: I checked the expanded view today and Grok is selected, so the “Fast” label I’d been reading was probably the speed level as you said. What I can’t explain with that is the free-plan runs — Aug 17-19 all logged as composer-2.5-fast, and everything from Aug 21 onward as cursor-grok-4.6-medium, with no change from me in between. If the default model shifts at the plan upgrade, that would account for it.

6

Glad the correction helped. On your request, the short answer is no. There’s no public dollar amount for the Cursor Models pool on Pro, not even a range. In the docs it’s described in a qualitative way like higher included limits, with no specific number.

One important detail so we don’t create confusion. The Cursor Models pool is also dollar-based, just like Other Models. Cursor just doesn’t publish the exact size anywhere, neither in the docs nor on the pricing page. In the dashboard you can see it as a percentage, but what exact dollar amount that percent maps to isn’t officially disclosed.

Why this can’t be reduced to one token number. Both pools are per-token with different rates by token type like input, cache write, cache read, and output. The only published dollar anchor is the Other Models pool which is about $20 on Pro. So your 442M to 558M is a token equivalent of the part of the pool you used with your specific grok and cache mix, not a fixed plan number.

So higher included limits is really the full public info today. If the docs ever include something more specific, I’ll reply here.

7

Two corrections to the original post, both from the discussion above.

First: the 442M-558M band conflates two pools. The $20 anchor belongs to Other Models; all four of my readings came from Cursor Models, whose dollar budget isn’t published. Thanks to Dean Rie for catching it.

Second, and this one I found while reading the “Usage Page $$ to Token Amount” thread: someone on Ultra posted a direct figure — 491.3M included tokens for a month. My band for Pro sits at 442M-558M. Those overlap almost entirely, which they shouldn’t, because Ultra costs considerably more than Pro.

So my range is probably too high. Two independent reasons to distrust it now, from two different directions.

I’m leaving the original text intact rather than editing it — the method is still worth reading, and the way it failed is part of what’s useful about it.