I’ve been running a proxy on my Claude Code sessions for a few months now, and one of the things it does is save detailed token consumption data across several accounts. We all know most AI subscriptions are a black box: they promise “more” of an opaque quantity that is never disclosed. So nerf posts are common, because nobody can compare against an absolute number. I set out to put absolute numbers, to the best of my ability, on how each model is actually billed. That should also make it possible to tell, in the future, whether Anthropic is really nerfing usage or our workflows are just heavier and use more compute. To do it, I got a fresh Pro account. Pro is the baseline that the Max (formerly Max 5x) and Ultra (formerly Max 20x) multipliers are measured against. I also checked whether Anthropic uses the same billing ratios on subscriptions as on the API. It’s close, but not the same, and the differences matter. More below. TL;DR No recent nerf. The only cut in my data is the 2026-09-14 end of the +50% weekly promo, about −14% per percent of the week. It has been flat since the 09-28 resets. The quota meter is basically API pricing with three twists: Cache reads cost about half the API’s ratio. 1-hour cache writes cost the same as 5-minute ones. Smaller models are charged above their API price ratio. Plan sizes: 5h window: Ultra (formerly Max 20x) ≈ 20× Pro, Team premium seat ≈ 6.25× . Weekly: only ≈ 10× and ≈ 5× . Fable has its own weekly meter, sized at half the weekly allowance. Value: at API list prices, a fully used subscription is worth ~50–60× its monthly price. How I measured it Claude returns usage headers on every API call ( anthropic-ratelimit-unified-* ). I read the quota off those and ended up with this model: percent = Σ (weight × tokens) / budget The headers only report whole percents , so each reading is one equation whose true value lies within ±0.5. On the fresh Pro account, Claude Code-shaped requests with one token type at a time . Thousands of readings then pin each weight far below the 1% step. The fit’s error is exactly the rounding noise, so the weights come with hard bounds, not just estimates. I used the new Pro account plus one of my Ultra accounts to double-check the findings. The Ultra account also gave me the Fable numbers. I use Opus 5.5 as the baseline every other model is measured against, so Opus’s S is 1. Per request: quota = S(model) × ( input + 1.25 × cache_write + 0.025 × cache_read + 5 × output ) (thinking counts as output) Output = 5× input , the same ratio as API pricing. Cache writes = 1.25×, whether the TTL is 5 minutes or 1 hour. The API charges 1-hour writes at 2×. Cache reads = 0.025× , half the API’s 0.05×. They’re not free: Claude Code traffic is ~97% cache reads, so they’re ~40% of what you burn. Across all my tests, these are the scales: Model scale S (vs the price ratio to Opus 5.5): So per API dollar, Opus 5.5 is the cheapest model to run on a subscription. Haiku, Sonnet and Fable carry a markup over their API rate. Plan sizes (in Opus 5.5 input-token equivalents) What a plan is worth at API list prices (typical Claude Code mix, ~$5.6 per 1M quota units) Has it been nerfed? 2026-09-14, the promo end, is the only cut. The weekly budget per percent fell ~14% (announced: 150% → 125%, i.e. −1/6). It applied to all usage from ~07:00 UTC, including weekly windows already running . The meter didn’t jump; each percent just started costing fewer tokens. Flat since the 09-28 resets, within a few percent. No peak-hour surcharge on Ultra or Team in my data: peak ÷ off-peak = 1.00 and 0.99 for weekdays 05–11 PT. Anthropic’s March peak-hour 5h burn was reportedly lifted for Claude Code on Pro/Max in May. I didn’t test Pro at peak. Window mechanics The weekly window runs on a fixed per-account schedule: exactly 168 h apart, same weekday and hour, already running before you first use the account. The 5h window starts at your first request. A limit-reset claim zeroes the weekly meter but keeps the reset date. A plan upgrade also resets all usage, without moving the weekly schedule. /api/oauth/usage seems to round up; the response headers round to nearest. If you try this yourself: count only new highs of the percent reading. Concurrent requests make it jitter (21, 22, 21, 22…), and summing every rise inflated “percent used” by 12–32% for me. That’s enough to fake a nerf all by itself. submitted by /u/lambdita
Originally posted by u/lambdita on r/ClaudeCode
You must log in or # to comment.