A $20/month Claude Pro subscription is not worth a fixed number of tokens. At the index’s default assumptions — 25,000 tokens per interaction, 40 active hours a week — it is worth 39.0 million tokens a month. Drop to 20 active hours and it is worth 19.5 million — exactly half, same sticker price. Cursor Pro, also $20/month, is worth roughly 3.32 million tokens a month whether you code one hour a week or sixty. One of these plans prices you by your calendar. The other doesn’t know you have one.
That asymmetry produces a crossover, and it sits far lower than most buyers would guess: about 3.4 active hours per week. Above that line — roughly 41 minutes of coding per weekday — the window plan always delivers more raw tokens. Which means fixed pools never compete on tokens for a working developer. They compete on model choice and the IDE.
One mechanic reads your calendar. The other ignores it.
A rolling window refills every time you show up; a monthly pool refills on your billing anniversary no matter what you do. Claude Pro meters usage in a five-hour session window shared across Claude Code and claude.ai — each window you actually work through is a fresh allotment. Priced at $20/month, the plan’s monthly token value is therefore a function of how many windows you burn: a throughput meter.
Cursor Pro is the opposite structure. Its included usage is a fixed $20 monthly API-usage grant that “resets monthly” on the billing date, and unused usage does not roll over — a point the community has confirmed and repeatedly asked Cursor to change. Work more hours and the grant does not grow. Work fewer and it quietly expires.
The index encodes this directly: window plans scale with the active hours per week slider, while calendar-refilled pools compute a constant, unaffected by it. That single branch in the methodology is what a static pricing page cannot express — the value of one plan type is a curve over your behavior; the other is a horizontal line.
What $20 buys, hour by hour
At the index’s defaults, Claude Pro yields 975,000 tokens per month for every weekly active hour you put in; Cursor Pro yields ~3.32M flat. The effective price per million tokens moves accordingly:
| Active hours/week | Claude Pro tokens/mo | Claude Pro eff. $/M | Cursor Pro tokens/mo | Cursor Pro eff. $/M |
|---|---|---|---|---|
| 2 | 1.95M | $10.26 | ~3.32M | $6.02 |
| 3.4 (crossover) | ~3.32M | $6.02 | ~3.32M | $6.02 |
| 10 | 9.75M | $2.05 | ~3.32M | $6.02 |
| 20 | 19.5M | $1.03 | ~3.32M | $6.02 |
| 40 | 39.0M | $0.51 | ~3.32M | $6.02 |
The arithmetic is visible on the live index: 45 messages per 5-hour window × your active windows per week × 25,000 tokens per interaction × 52/12 weeks per month. At 40 hours a week that is eight windows and 39.0M tokens — an effective $0.51 per million. At 20 hours it is $1.03. Cursor Pro stays at $6.02 per million at every row, because nothing in its mechanic responds to hours.
The crossover is 3.4 hours a week — not 15, not 20
Solving for where the two lines meet gives 3.4 active hours per week; anyone above it gets more raw tokens from the window plan. The intuition that a monthly pool is the “heavy user” option — a big grant you draw down at your own pace — has it backwards. The pool is the *light* user’s structure. It wins only when you code so little that Claude Pro’s per-window refills, multiplied by your handful of windows, sum to less than 3.32M tokens.
The failure mode at the other end is well documented. One Cursor Pro user burned the entire $20 monthly pool in a single day of heavy Agent use with a frontier model — and guidance cited in that thread puts typical daily Agent users at $60–100 per month in usage, three to five times the included grant. A fixed pool doesn’t stretch with your hours; it just runs out sooner. A rolling window would have handed that user a fresh allotment by the afternoon.
So what is Cursor Pro actually selling? Not tokens — model choice across vendors and the editor itself. That can be a perfectly good $20. It is just a different product than the one the pricing page’s dollar figure implies, and the token math makes the difference legible.
The caveat: most window plans aren’t pure meters
Claude Pro is the cleanest throughput meter in the index; most other window plans are hybrids with a hard weekly ceiling. OpenAI’s Codex plans share a five-hour window but state plainly that “additional weekly limits may apply”, and the index models published weekly caps for Codex, Z.ai’s GLM plans, and Qwen. For those, tokens-per-month scales with your hours only until the weekly cap binds — the curve climbs, then goes flat.
- Claude Pro/Max — 5-hour windows; Anthropic tracks a weekly limit as a separate metric but publishes no number, so the index models Claude’s scaling as unclipped.
- Codex Plus/Pro — 5-hour windows with published weekly ceilings; throughput-scaled up to the cap, flat after it.
- Cursor Pro/Pro+/Ultra — fixed monthly dollar grants; flat everywhere.
The honest generalization: every plan’s token value is some function of your calendar, and the shape of that function — linear, clipped-linear, or constant — matters more than the sticker. Two $20 plans can differ by 12× in effective cost per token for a full-time coder ($0.51 vs $6.02 per million) and invert entirely for a weekend one. No static pricing page will compute that for you. The index will, at your hours.
Move the active-hours slider and find your own crossover →
Sources
- Anthropic — Use Claude Code with your Pro or Max plan
- Anthropic — Claude pricing
- Anthropic — Usage limit best practices
- OpenAI — Codex pricing
- Cursor — Usage limits
- Cursor forum — Do credits roll over?
- Cursor forum — Monthly credits gone in one day
- Cursor forum — Proposal: let unused monthly quota roll over