[BUG] Weekly + Fable scoped meters deplete 1.7-5x faster since Aug 17 reset on Max 20x; OAuth token carried rateLimitTier default_claude_max_5x
Related: #79773, #65678, #69430, #52135, #54714 — but not upgrade-related. My account has been Max 20x for months with no plan change, so this is not limited to mid-cycle upgrades.
What's Wrong?
Since the weekly window reset on 2026-08-17 05:00 CDT, both of my weekly meters are depleting far faster per token than in the four preceding weeks, against a below-median workload.
Fable scoped meter (weekly_scoped) — all figures deduped by requestId from ~/.claude/projects/**/*.jsonl, with Fable filtered on the message.model field:
| week starting (CDT) | Fable requests | Fable cache_read | ever blocked from Fable? |
|---|---|---|---|
| 2026-07-20 | 2,192 | 633,534,178 | no |
| 2026-07-27 | 1,660 | 600,401,256 | no |
| 2026-08-03 | 1,799 | 647,047,147 | no |
| 2026-08-10 | 1,422 | 582,975,002 | no |
| 2026-08-17 | 77 | 19,128,570 | 16% consumed |
Four consecutive weeks at 583–647M cache-read tokens without ever being blocked, then 19.1M reads 16%. Applying the current rate to those prior weeks yields 490–840% depending on which measured rate is used — impossible under any of them.
General meter (weekly_all) is also affected:
last week: 2,851M cache_read = 100% of cap -> 28.5M per 1%
this week: 214M cache_read = 13% -> 16.5M per 1%
=> at least 1.7x faster per tokenControlled measurements the same day, at small context (rules out any long-context effect; the >200k surcharge was removed 2026-03-13 anyway):
78k-context subagent: 1,602,345 cache_read -> exactly 1 percentage point
154k-context session: 3,860,926 cache_read -> exactly 2 percentage pointsToday was a below-median workload: 214M cache_read versus a 303M median day over the preceding six weeks.
Possibly related: OAuth token carried the wrong rate-limit tier
My Claude Code credential (macOS keychain, service Claude Code-credentials) carried:
rateLimitTier: default_claude_max_5xwhile /api/oauth/profile returned:
organization.rate_limit_tier: default_claude_max_20x
organization.subscription_status: activeLogging out and back in reissued the token as default_claude_max_20x, so the two now agree. The token can carry a tier that disagrees with the organization's entitlement with no upgrade involved.
Important caveat: correcting the tier did not fix the metering. A 702,407-token Fable burn immediately after re-authenticating still moved the scoped meter a full percentage point (~0.70M/point), versus 1.20–1.60M/point before. So either the corrected tier does not propagate to the meter, or the tier claim is cosmetic and the depletion has a different cause. Reporting both because the mismatch is objectively real and reproducible, but I can't claim it as the cause.
What Should Happen?
Weekly and scoped meters should deplete at a rate consistent with the account's actual entitlement and with prior weeks' behaviour for the same workload. Four weeks at ~600M Fable cache-read tokens per week without being blocked, followed by 19.1M consuming 16%, is a ~5x change in metering with no corresponding change in usage.
The OAuth token's rateLimitTier should also match the organization's rate_limit_tier.
Error Messages/Logs
Raw /api/oauth/usage (2026-08-17):
{"kind":"session","group":"session","percent":5,"is_active":true}
{"kind":"weekly_all","group":"weekly","percent":14,"resets_at":"2026-08-24T10:00:00Z","is_active":false}
{"kind":"weekly_scoped","group":"weekly","percent":16,"resets_at":"2026-08-24T10:00:01Z",
"scope":{"model":{"id":null,"display_name":"Fable"}},"is_active":false}
Keychain credential BEFORE re-login: rateLimitTier: default_claude_max_5x
Keychain credential AFTER re-login: rateLimitTier: default_claude_max_20x
/api/oauth/profile (both times): organization.rate_limit_tier: default_claude_max_20xNo error messages are produced — the meters simply advance faster than the token counts justify.
Steps to Reproduce
- Read the current scoped meter:
``bash``
TOKEN=$(security find-generic-password -s "Claude Code-credentials" -w \
| python3 -c 'import sys,json; print(json.load(sys.stdin)["claudeAiOauth"]["accessToken"])')
curl -s https://api.anthropic.com/api/oauth/usage \
-H "Authorization: Bearer $TOKEN" -H "anthropic-beta: oauth-2025-04-20" | python3 -m json.tool
- Run a bounded Fable workload at small context (I used a subagent doing ~20–25 tool calls at ~78k context).
- Measure the exact tokens consumed from the session transcript, deduplicating by
requestId— streaming emits ~2.6 records per API call, so raw record counts overstate usage ~2.6x:
``python``
# per assistant record with message.usage, keyed by requestId
# sum cache_read_input_tokens / cache_creation_input_tokens / output_tokens
- Re-read the meter and divide tokens by the change in percentage points.
Observed: ~0.7–1.6M cache_read tokens per percentage point. Compare against prior weeks, where ~600M cache_read tokens per week never exhausted the same meter (which implies ≥5.8M per point).
To check the tier mismatch specifically:
security find-generic-password -s "Claude Code-credentials" -w \
| python3 -c 'import sys,json; print(json.load(sys.stdin)["claudeAiOauth"]["rateLimitTier"])'
# compare against organization.rate_limit_tier from /api/oauth/profileClaude Model
Fable 5 (claude-fable-5) for the scoped meter measurements; Opus 5 for the general meter. Both meters affected.
Is this a regression?
Yes — the four preceding weekly windows metered consistently; the change appeared at the 2026-08-17 reset.
Last Working Version
Not version-linked as far as I can tell — the change coincided with the weekly window reset rather than a Claude Code upgrade. Metering was normal through the window ending 2026-08-17 05:00 CDT.
Claude Code Version
2.1.233 (Claude Code)
Platform
Claude subscription (Claude Max 20x)
Operating System
macOS 26.5.1 (build 25F80)
Terminal/Shell
Ghostty / zsh
Additional Information
Ruled out locally before filing:
- Hidden or concurrent Fable sessions — verified machine-wide across all transcripts
requestIddouble-counting —iterationsarrays reconcile to 0.998x of top-level usage- Server-side tool use —
server_tool_use.web_search_requests/web_fetch_requestsall zero - Prompt-cache misses — 96.07% cache hit rate last week
- Extra-usage credits —
extra_usage.is_enabled: false - Long-context surcharge — removed 2026-03-13, and the small-context measurements above are well under any threshold
- Opus/Sonnet/Haiku counting against the scoped meter — 45M of Opus moved the Fable meter 0 points
The meter itself behaves correctly otherwise: it responds promptly, is not a rolling window, and held flat across 27 minutes of zero Fable traffic while the 5-hour meter advanced on Opus work.
Happy to provide per-week and per-day token counts, the raw /api/oauth/usage responses, or re-run any measurement.
Showing cached comments. Read the full discussion on GitHub ↗
3 Comments
Two additions: a likely precedent, and a measurement that partially supports it.
This closely resembles the March 2026 prompt-caching metering bug
The week of 2026-03-23 saw widespread reports of abnormal quota consumption (r/ClaudeAI "20x max usage gone in 19 minutes", 330+ comments in 24h; r/ClaudeCode on limits "silently reduced", 360+ comments). One Max 20x subscriber reported usage jumping 21% → 100% on a single prompt. That episode was attributed in part to a prompt-caching bug that drained limits ~10-20x faster than expected, and Anthropic reset Claude Code rate limits afterwards.
The shape matches what I'm seeing: a step change at a window boundary, no corresponding change in workload, and nothing client-side that accounts for it.
Why this would hit some accounts far harder than others: my usage is 96.07% cache reads (2,851M of 2,973M total tokens last week). If cache-read tokens are being mis-weighted in quota accounting, an account with a very high cache-read fraction absorbs almost the entire error, while a user with a lower fraction may not notice at all. That would explain why this shows up sharply for heavy long-session users and is otherwise quiet.
Cache-weight fit across four measured burns (inconclusive but suggestive)
Four Fable burns today, each with exact token counts and observed meter movement. If the meter weights cache reads at some W, then
(cr*W + cw*2 + out*5) / pointsshould be constant across all four. Solving for W:| W (cache-read weight) | spread (max/min rate) |
|---|---|
| 0.10 (documented API weighting) | 5.32x |
| 0.50 | 3.51x |
| 1.00 | 3.06x |
| 2.00 | 2.86x |
The fit improves monotonically as W increases and never converges near 1.0x, so no single read-weight explains all four burns. Three of the four moved the meter only 1-2 integer points, so each carries up to ±50% rounding error — I would not call this conclusive. But it does lean toward cache reads being weighted above the documented 0.10, which is the direction a caching-accounting fault would produce.
The four burns, for anyone wanting to check the arithmetic:
Note on Fable weighting
For completeness: Fable 5 is documented as drawing on the same weekly allowance (capped at 50% of it) and weighing roughly 2x an Opus session, effective 2026-07-20. That is expected behaviour and predates the change reported here — my four prior weekly windows (Jul 20, Jul 27, Aug 3, Aug 10) all metered normally under that policy. It does not account for the step change at the 2026-08-17 reset.
I'm experiencing exactly the same issue. I have been no where close to hitting any usage limit (session, weekly, per-model) in several weeks. Suddenly today, not only did I hit my 5 hour session limit, but 33% of this week's limit in just a few hours. I wasn't doing anything token-heavy or out of the ordinary.
I'm also on Claude max 20x plan, and used Fable 5 today.
Fable usage is sitting at 61% for the week and I haven't used fable at all this week..