Max plan: usage exhausted abnormally fast, twice in one day (March 31)
Status Open
Maintainer reply None cached
Workaround ✓ Mentioned in thread ↓
Activity 10 comments · opened Mar 31, 2026
Description
I'm on Claude Code Max subscription. Today (March 31, 2026) my usage was exhausted abnormally fast — twice in one day. I barely did any work and the quota was already gone both times.
This is NOT normal behavior. Previously I could work extensively without hitting limits. Today the usage runs out almost immediately.
Environment
- Plan: Claude Code Max
- Model: Claude Opus 4.6 (1M context)
- Platform: macOS (Darwin 24.6.0)
- Claude Code: VS Code extension
Expected behavior
Usage should last for meaningful work sessions, as it did before.
Actual behavior
Usage exhausted within minutes of starting work. Happened twice today (March 31, 2026).
This started recently (late March 2026).
Request
Please review my account usage logs — the consumption pattern today is clearly abnormal compared to my previous usage history.
Related issues
#38335, #37394, #41424, #41212
10 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
Usage data — clear evidence of abnormal consumption
Here is my actual usage from the Anthropic dashboard:
| Date | Cost | Messages | Cache Creation | Cache Read |
|------|------|----------|---------------|------------|
| 31.03 (today) | $54.60 | 212 | 5,873,410 | 106,089,848 |
| 30.03 | $143.41 | 1,016 | 7,260,860 | 379,166,552 |
| 29.03 | $135.28 | 1,248 | 2,208,119 | 417,572,985 |
| 28.03 | $80.19 | 1,223 | 1,898,943 | 231,710,747 |
| 27.03 | $130.15 | 935 | 7,462,367 | 348,661,083 |
| 26.03 | $110.83 | 1,744 | 2,710,846 | 332,315,336 |
Today I hit the limit after only 212 messages — normally I send 900-1,700 messages per day.
The Cache Creation tokens today (5.8M) are disproportionately high relative to the number of messages (212), while Cache Read is very low (106M vs typical 200-400M). This strongly suggests the prompt cache is not being reused properly, causing full reprocessing on each turn.
This is 5-8x less capacity than my normal daily usage. Something is clearly broken with token accounting or cache handling today.
Please review my account logs.
@alexsapunov how did you gather this usage data? The usual analytics stuff doesn't seem to track my Max subscription's usage.
@flyte The usage data comes from the Anthropic Console (not claude.ai).
Go to: https://console.anthropic.com → Usage tab
There you can see daily breakdown with:
This is where I got the table from. It shows the internal cost Anthropic attributes to your Max subscription usage, even though you're not paying per-token.
The key metric to watch is Cache Creation tokens ÷ Messages — this gives you tokens-per-message. On a normal day mine is 1.6k-1.8k, but on the bug day (March 31) it spiked to 27.7k per message — a 17x increase.
When I log in there I get a different organisation, so I'm not able to see the stats from my Max sub org. Not sure how you've been able to link them up!
@flyte When you log into console.anthropic.com, check the organization selector in the top-left corner. You should see something like "your-email's Organization" — that's the one linked to your Max subscription.
If you see a different org (like a work/team org), switch to your personal one. The Max subscription usage should appear under your personal organization.
Also make sure you're logging in with the same email that your Max subscription is billed to.
Same experience here on Max 20 ($200/mo) with Opus — rate limit 100% exhausted in ~70 minutes.
I set up a monitoring proxy via the
ANTHROPIC_BASE_URLenv var and traced it to two client-side cache bugs:deferred_tools_deltaintroduced in v2.1.69The cache read ratio dropped to 4.3% (effectively ~20x token inflation). After workarounds it recovered to 89–99%.
Full analysis + workarounds: https://github.com/ArkNill/claude-code-cache-analysis
Important caveat: All my testing was done in the CLI environment (
claudein terminal, Linux). Since you're on VSCode (macOS), the cache behavior might differ. That said, @Codename-404 reported in #38335 that downgrading the VSCode extension to v2.1.68 also significantly reduced consumption — so the same root cause likely applies.You can try: VSCode extension → gear icon → "Download specific version VSIX" → select 2.1.68, and monitor if it helps.
Follow-up — precautions (April 2, 2026)
"Exhausted twice in one day" = consistent with the cache bug compounded by session behaviors.
Precautions that help:
--resume(replays full history),/dream&/insights(background drain), v2.1.89Ref: https://github.com/ArkNill/claude-code-cache-analysis
Update (April 2): v2.1.90 has significantly improved cache efficiency — benchmark shows 95-99% cache read in stable sessions (both npm and standalone installations).
If you're still affected:
claude update(ornpm install -g @anthropic-ai/claude-code)"DISABLE_AUTOUPDATER": "1"to~/.claude/settings.jsonenv section--resume(still broken)Note: server-side quota issues (org-level pool sharing, accounting mismatches) remain unresolved — the above fixes the client-side cache drain only.
Benchmark data: https://github.com/ArkNill/claude-code-cache-analysis
April 3 update: v2.1.91 fixes the cache regression that caused the worst drain. If you are still hitting limits after updating, there are additional unfixed mechanisms: a 200K tool result budget cap, a client-side false rate limiter, and silent context stripping — all confirmed via proxy testing. Anthropic acknowledged peak-hour tightening on X (Lydia Hallie) but stated "none were over-charging you." Measured data and analysis: claude-code-cache-analysis