{
  "video_id": "reddit_1vx0k69",
  "channel_slug": "ClaudeAI",
  "channel_handle": "r/ClaudeAI",
  "title": "Lifting the Curtain: The Max x5 and Max x20 Usage Limits that Anthropic Refuses to Share",
  "url": "https://www.reddit.com/r/ClaudeAI/comments/1vx0k69/lifting_the_curtain_the_max_x5_and_max_x20_usage/",
  "external_url": null,
  "upload_date": "20260824",
  "published_at": "2026-08-24T11:49:04+00:00",
  "transcript": "# TLDR\n\nWith high confidence, this is how the Max x5 and Max x20 subscriptions compute usage.\n\nAll 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.\n\n|subscription|pool (M TV)|Fable weight (× Opus)|Fable cap (M fable-TV)|\n|:-|:-|:-|:-|\n|**Max x20**|**1,412** \\[1,406–1,422\\]|**6.50** \\[6.47–6.52\\]|**108.6** \\[108.2–108.7\\]|\n|**Max x5** \\*|**628** \\[600–637\\]|**4.25** \\[4.11–4.35\\]|**73.85** \\[73.1–74.6\\]|\n|ratio|**2.25**|**1.53**|**1.4706** \\[1.45–1.49\\]|\n\n\\* x5 values from typed meter readings (softer); x20 from caught display flips (hard). Sonnet weight: **0.60** on both plans (= its list-price ratio).\n\n# What that buys, in API list dollars\n\n|per week|zero Fable|max Fable|monthly value ÷ sub price \\*\\*|\n|:-|:-|:-|:-|\n|**x20** ($200/mo)|**$7,059**|**$4,615** ($3,529 Opus + $1,086 Fable)|**152.9× → 100×**|\n|**x5** ($100/mo)|**$3,138**|**$2,308** ($1,569 Opus + $738 Fable)|**136.0× → 100×**|\n\nMaxing Fable forfeits \\~35% of either pool's API value — and at full Fable both plans land on **exactly 100×**. \\*\\* weekly × 52/12; boost included.\n\n# Background\n\nThe 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.\n\n# The model\n\n    TV        = 1·input + 5·output + 1.25·cache_write_5m + 2.0·cache_write_1h + 0.1·cache_read\n    overall % = (opus_TV + 0.6·sonnet_TV + x·fable_TV) / pool\n    fable %   = x·fable_TV / (0.5 · pool)        \n    design:   5 · cap · (2 + x) = 100 × price / (52/12)    \n              zero-Fable multiple = 200·x / (2 + x)        \n\nGrounding 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.\n\n# The interesting findings\n\n1. **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.\n2. **Upgrading x5→x20 approx. doubles the pool but the Fable cap grows only 1.5×**.\n3. **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.\n4. 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).\n\n# Method\n\nI 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.\n\nI 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:\n\n1. **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.\n2. **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.\n\n# Threats to validity\n\n* **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.\n* **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.\n* **Transcript completeness.** I assume the local transcripts capture all metered usage after dedup. A \\~2% systematic (missed side-sessions, double-counting) would shift the caps by the same amount — enough to matter for the \"exactly 1.47 vs 1.5\" cap-ratio question, not for the headline structure.\n* **Assumed constants.** Sonnet's weight is measured only indirectly on x20 (via flip timing) and assumed at list price on x5; cache-write TTL pricing is taken from the docs, not independently verified against the meter.\n* **The 100× fit could be numerology.** Two free constants reproducing six parameters is suggestive, not proof — the uncertainty bands are wide enough to admit nearby schemes, and I found the principle *after* seeing the numbers. It does make testable predictions though (any other tier should obey it; the boost lapsing should scale pools/caps by exactly 1/1.5).\n\n\n\n--- Top Comments ---\n\n\n[30 upvotes] what i really care about is not the ratio to API pricing but the ration between the three sub tiers.   \nMost places i look say that the max variants only boost the 5 hour window but have little effect on the weekly cap. \n\nDo you have numbers on that?\n\n[18 upvotes] [removed]\n\n[13 upvotes] How can they call it 20x? Seems like nowhere close.\n\n[11 upvotes] this is insightful. the thing that seems crazy to me is that 20x doesn't equal 20x... or am I seeing that wrong?",
  "transcript_chars": 6889,
  "ingested_at": "2026-08-24T13:30:05.093067+00:00",
  "source": "reddit",
  "yt_meta": {
    "score": 126,
    "upvote_ratio": 0.95,
    "num_comments": 33,
    "author": "Ohtince",
    "is_self": true
  }
}