Lifting the Curtain: The Max x5 and Max x20 Usage Limits that Anthropic Refuses to Share

TLDR

With high confidence, this is how the Max x5 and Max x20 subscriptions compute usage.

All point values are the unique set that makes the "100×" principle below exact; measured uncertainty bands in brackets. Values include the current +50% weekly boost.

subscription pool (M TV) Fable weight (× Opus) Fable cap (M fable-TV) Max x20 1,412 [1,406–1,422] 6.50 [6.47–6.52] 108.6 [108.2–108.7] Max x5 * 628 [600–637] 4.25 [4.11–4.35] 73.85 [73.1–74.6] ratio 2.25 1.53 1.4706 [1.45–1.49] * x5 values from typed meter readings (softer); x20 from caught display flips (hard). Sonnet weight: 0.60 on both plans (= its list-price ratio).

What that buys, in API list dollars

per week zero Fable max Fable monthly value ÷ sub price x20 ($200/mo) $7,059 $4,615 ($3,529 Opus + $1,086 Fable) 152.9× → 100× x5 ($100/mo) $3,138 $2,308 ($1,569 Opus + $738 Fable) 136.0× → 100× Maxing Fable forfeits ~35% of either pool's API value — and at full Fable both plans land on exactly 100×. weekly × 52/12; boost included.

Background

The last few weeks I've been extremely annoyed by Anthropic not sharing these numbers with us. Consumers cannot make a measured decision when picking a subscription tier without knowledge of what they will actually receive. I did ask and support escalated to their product and legal teams (after I reminded their AI agents several times that they are in fact very likely breaking several laws in my jurisdiction). The answer was that they don't share these numbers. I considered pushing this through our local consumer protection agency, but that's boring and tedious, so instead I tried to see if I could deduce their model empirically. Details below partially written down by Fable, apologies for any remaining Claudisms.

The model

TV = 1·input + 5·output + 1.25·cache_write_5m + 2.0·cache_write_1h + 0.1·cache_read overall % = (opus_TV + 0.6·sonnet_TV + x·fable_TV) / pool fable % = x·fable_TV / (0.5 · pool) design: 5 · cap · (2 + x) = 100 × price / (52/12) zero-Fable multiple = 200·x / (2 + x)

Grounding constants: API list prices per MTok in/out — Opus $5/$25, Fable $10/$50 (2× Opus), Sonnet $3/$15 (0.6× Opus); cache read 0.1×, cache writes 1.25× (5-min TTL) / 2× (1-hour TTL), with the TTL split read per-request from local transcripts.

The interesting findings

- Fable is metered well above its API price. It lists at 2× Opus but consumes allowance at 4.25× (x5) / 6.5× (x20) Opus per token — i.e. ~2.1× and ~3.25× its own list price.

- Upgrading x5→x20 approx. doubles the pool but the Fable cap grows only 1.5×.

- The apparent design principle: worst-case (max-Fable) API value = 100× the subscription price, on both plans. Run backwards, this forces the odd-looking 1.47 cap ratio I measured. It's holding Anthropic's worst-case exposure, assuming full Fable usage, proportional to price. Using less Fable gets you more than 100×. Possibly because Fable inference has significantly stricter bounds on available supply than Opus or Sonnet.

- Two free design constants (the 100×, plus the two Fable weights) reproduce all six measured parameters within error. Caveats: n=1 account, partial week of x20 data, sonnet weight assumed at list on x5, and everything includes the +50% boost (divide pools/caps by 1.5 for post-boost predictions: the x20 Fable cap lands on a suspiciously clean 72.5, the x5 cap on ≈50).

Method

I don't want to post the exact evidence (privacy), but you should be able to reproduce this yourself. My methods developed as I went on, and my x5 readings were less precise than my x20 readings, but looking at the outcome, I'm quite confident they hold up.

I had Claude (Fable, fittingly) build and run the whole experiment: it reads the local session transcripts (~/.claude/projects/**/*.jsonl), which record per-request token counts split by type, model, and even cache-write TTL — that yields the exact price-weighted usage (TV) at any instant. Two kinds of readings against that:

- Meter snapshots. Note the in-app usage percentages and compare against transcript TV at that same instant. Each integer display is a ±0.5% band, so one reading is coarse — but readings where one term is frozen isolate parameters (e.g. an interval with zero Fable measures the pool with the Fable weight cancelled). Take them in quiet moments; live sessions make the meter lead the transcripts.

- Watched flips. If you catch the display ticking over (24% -> 25%), the underlying value at that instant is exactly 24.5% — the rounding vanishes. One flip caught during an idle moment measured the Fable cap to ±0.25%, tighter than all my ordinary readings combined. Catching a Fable flip and an overall flip minutes apart during a pure-Fable stretch is what pinned the rest.

Threats to validity

- n=1, short baseline. One account, partial x20 cycle, a handful of x5 cycles. If Anthropic varies pool sizes week-to-week or per-account, my "constants" are one account's snapshot.

- The x5 side is softer. Those readings were typed from the panel, some while sessions were running — the meter counts in-flight requests before they reach the transcripts, so reading and transcript state can be minutes apart. The x20 numbers come from watched flips and don't have this problem.