Max Plan: Token usage increased ~3-5x without any configuration change (since ~March 28-29)

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/41504
2. https://github.com/anthropics/claude-code/issues/41425
3. https://github.com/anthropics/claude-code/issues/40790

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

Same here, exatly the same thing, that bug that almost consumed 60% of my week quota

Same here! Exactly the same problem.

@SamoraDC @intellia1 Good to know, thanks for the feedback. I’ve also been waiting for support to reply for the past 2 days, so they probably just have a lot going on right now haha. Sounds like it’s probably the same issue on my side too.

Also really good to know I’m not the only one. I was already starting to think I messed something up on my server, especially since I’m also running AI agents on it and couldn’t find anything suspicious.

+1. Max 20 ($200/mo), v2.1.89. April 1: 100% in ~70 min after reset. Same config, same workflow, 3-5x increase matches my experience exactly.

Full report: #41788
Related: #38335, #38239, #41663, #40652, #41346

I've been experiencing the same issue on Max 20 ($200/mo) — rate limit 100% exhausted in ~70 minutes.

After setting up a monitoring proxy using the official ANTHROPIC_BASE_URL env var, I identified two cache bugs as the root cause (#40524, #34629) and measured the impact: cache read ratio dropped to 4.3%, meaning ~20x token inflation per turn. After applying workarounds it stabilized at 89-99%.

Full analysis with per-request measured data, safe workarounds, and community references (including cc-cache-fix): https://github.com/ArkNill/claude-code-cache-analysis

Update: Confirmed fix via downgrade to v2.1.68

Thanks to @ArkNill's excellent cache analysis and the reference to #40524 / #34629, I can now confirm with measured data that downgrading to v2.1.68 (before the deferred_tools_delta changes) resolves the issue.

Measured Results (72h window, sessions with 10+ turns only)

v2.1.87-89 (buggy): 21 sessions, 3,654 turns

• Weighted cache read ratio: 96.5% overall
• 2 sessions with catastrophic cache failure (40-46% ratio, 68-73 turns each)
• These broken sessions show cache reads freezing mid-session while creation keeps growing — classic deferred_tools_delta bug

v2.1.68 (fixed): 2 sessions, 109 turns

• Weighted cache read ratio: 92.9%
• 0 broken sessions — both sessions stable at 82-96%

Per-turn breakdown showing the bug in action

Broken session (v2.1.89, b810c370):

Turn  4: read=45953  create=  522  ratio=98.9%  ← starts healthy
Turn 18: read=53015  create=3185  ratio=94.3%  ← still fine
Turn 40: read=15499  create=52361 ratio=22.8%  ← cache reads FREEZE
Turn 68: read=15499  create=72048 ratio=17.7%  ← never recovers

Healthy session (v2.1.68, 053184ee):

Turn  4: read=51557  create=  339  ratio=99.3%  ← healthy
Turn 12: read=53664  create=  722  ratio=98.7%  ← stable
Turn 20: read=59764  create= 1666  ratio=97.3%  ← stays healthy
Turn 30: read=61430  create=  834  ratio=98.7%  ← never degrades

What I did

1. Downgraded to v2.1.68: npm install -g @anthropic-ai/claude-code@2.1.68
2. Disabled auto-updates in ~/.claude.json: "autoUpdates": false
3. Set up monitoring script to track cache ratio per session

Key finding

The bug is intermittent on v2.1.87-89 — most sessions work fine (17/21 = 81%), but when it triggers, the cache completely breaks mid-session and never recovers. This explains why it's so hard to reproduce consistently: you can have days of normal usage, then suddenly one session burns through your entire rate limit.

Environment

• Plan: Max ($100/month), Opus 4.6
• 57 plugins, 9 MCP servers (unchanged config)
• Debian 12, SSH remote sessions

Follow-up — precautions (April 2, 2026)

The 3-5x increase you're seeing is consistent with the cache prefix bug I described — without cache, each turn bills your full context at 100% instead of ~10%.

Additional drain accelerators to avoid:

• --resume — replays entire history as billable input
• /dream, /insights — background token consumption
• v2.1.89 — cache bug still present + terminal regression
• Sub-agents (Haiku = 0% cache read, measured 317K/31 calls)

Recommended: v2.1.81 (fixed) + fresh sessions + local proxy monitoring.
Ref: https://github.com/ArkNill/claude-code-cache-analysis

+1. Max Plan, v2.1.90 on Windows 11, Opus 4.6 [1m].

Session today (2026-04-02): Claude Code client warned ~88% usage after only 46 minutes. At the same time, the website (claude.ai) showed 36%. Clear discrepancy between client-side usage tracking and server-side reality.

Two parallel Claude Code sessions running (both Opus [1m]), with GSD workflow spawning multiple subagents — but even accounting for that, 88% in 46 minutes is implausible on Max Plan.

The client/server mismatch suggests the client-side usage counter is inflating independently of actual API consumption.

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:

1. Update: claude update (or npm install -g @anthropic-ai/claude-code)
2. Pin the version: add "DISABLE_AUTOUPDATER": "1" to ~/.claude/settings.json env section
3. Avoid --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

@ArkNill Thanks for the update — that’s really helpful to know.

Do you think this now means the usage calculation is back to normal again, so longer coding sessions of several hours should be possible again? Or are there still remaining issues on the quota/accounting side?

In my case, downgrading to the previously suggested version definitely improved the usage behavior, but it’s still noticeably too high compared to before. I’m still hitting my Max plan 5-hour limit much sooner than I used to.

So I’m wondering whether the cache issue is mostly fixed now, but some other part of the usage tracking or quota calculation is still off.

@Commandershadow9 Honestly, I can't give concrete numbers beyond what I've already shared — my benchmark only covers the client-side cache behavior.

What I can say from my own experience (Max $200 plan):

• The v2.1.90 cache fix is real and verified — that's the main win here, escaping the "v2.1.89 swamp"
• However, even accounting for the 2x event ending, quota does feel tighter than before. I've noticed it too.
• Server-side accounting (quota pool, usage tracking) is outside our visibility — only Anthropic can clarify whether something changed there.

My practical takeaway: the client-side drain is fixed, so the focus now shifts to how we use our quota — being more intentional with session length, subagent spawning, and context size. Not a fix, but the best we can do on our end until Anthropic addresses the server side.

Also worth noting: this issue has been escalated on X as well. An Anthropic employee acknowledged it directly on their personal account and confirmed they're looking into it:
https://x.com/im_blue19520/status/2039578920006430749

@ArkNill Thanks again for the clarification — that matches my experience pretty closely as well.

I’ll update to v2.1.90 and continue monitoring it over the next few sessions. It sounds like the major client-side cache drain may be mostly fixed now, but the quota / accounting side still doesn’t feel fully back to normal yet.

In my case, the downgrade already improved things, but usage still feels noticeably higher than it used to, and I’m still hitting my 5-hour Max limit much sooner than before. So it really feels like there may still be some separate bug or mismatch in usage tracking / quota accounting on top of the cache issue.

With so many people reporting the same pattern, it’s hard to believe this is just expected behavior.

Good to know it has been escalated further. Now I’m just curious when support will finally get back to me.

@Commandershadow9 Good to hear you're monitoring on v2.1.90. Let us know how the numbers look — especially the cache read ratio if you set up a logging proxy. More data points from different plans and workflows help build the full picture.

Brief update (April 3): v2.1.91 is out and cache behavior is further improved — npm and standalone now perform identically (Sentinel gap closed). However, testing revealed two additional unfixed bugs: a 200K tool result budget cap that silently truncates older results, and a client-side false rate limiter generating <synthetic> errors without API calls (151 entries confirmed). If you are still seeing drain after updating, these are the likely causes. Details: claude-code-cache-analysis

Update (April 3) — Cache bug confirmed fixed, but billing/accounting issue persists

Following @ArkNill's cache analysis work, I extracted token usage data directly from my local Claude Code session transcripts (JSONL files in ~/.claude/projects/). I analyzed 431 sessions with 10+ turns spanning March 1 through April 3. Here's what the data shows.

---

1. Cache bug: CONFIRMED FIXED in v2.1.91

| Period | Sessions | Avg Cache Read % | Broken (<60%) | Healthy (≥85%) |
|--------|----------|------------------|---------------|----------------|
| Before bug (Mar 1-24) | 333 | 87.7% | 11 (3.3%) | 262 (78.7%) |
| Bug period (Mar 25 - Apr 1) | 98 | 86.3% | 6 (6.1%) | 73 (74.5%) |
| After fix v2.1.91 (Apr 2-3) | 5 | 93.3% | 0 (0%) | 5 (100%) |

Cache behavior is healthy again. No broken sessions since updating. This part is fixed — credit where it's due.

2. The REAL issue: Billing/accounting is still broken

Here's the evidence that something changed server-side, independent of the cache bug.

March 23-27: 12-hour coding marathons — no issues

During this period I worked 12+ hour coding blocks across multiple projects and terminals. Same config as today: Opus 4.6 (1M context), alwaysThinkingEnabled: true, effortLevel: "high", 57 plugins, 9 MCP servers. These sessions ran flawlessly:

| Turns | Cache Read % | Total Tokens | Duration |
|-------|-------------|-------------|----------|
| 1,245 | 99.1% | 447M | ~12h+ |
| 1,070 | 98.9% | 233M | ~12h+ |
| 946 | 99.2% | 242M | ~10h+ |
| 898 | 99.1% | 270M | ~10h+ |
| 796 | 98.0% | 232M | ~8h+ |
| 608 | 98.5% | 130M | ~6h+ |
| 580 | 99.1% | 131M | ~6h+ |
| 469 | 99.1% | 81M | ~5h+ |

That's 8 sessions with 469-1,245 turns each, consuming ~1.77 billion tokens total across multiple days — with zero rate limit issues on Max $100/month.

April 3 (today): 7% of 5-hour limit burned after ~160 turns

Today's sessions on v2.1.91 — cache is healthy, plugins reduced from 57→15 (as token optimization), everything else unchanged:

| Session | Turns | Cache Read % | Total Tokens |
|---------|-------|-------------|-------------|
| Home (early) | 34 | 89.0% | 2.4M |
| Home (mid) | 68 | 92.2% | 6.4M |
| Home (current) | 56 | 96.6% | 4.4M |
| Agents (2x) | 4 | 0% (cold start) | 0.2M |
| Total | 162 | ~93% | ~13.4M |

Result: ~7% of the 5-hour rolling limit consumed — for 162 turns of light work (config changes, reading an issue, checking versions). Compare that to March 27 where 1,245 turns across 12 hours didn't even trigger a warning.

3. What I've tried as mitigation

• ✅ Updated to v2.1.91 (cache fix confirmed)
• ✅ Reduced plugins from 57 → 15 (disabled 42 plugins, ~50% less system context overhead)
• ✅ Fresh sessions only (no --resume)
• ✅ Single terminal instead of parallel sessions
• ❌ Still hitting limits after 1-2 hours

4. Re: "billing is working as expected"

I've seen statements (e.g., from @lydiahallie on X) suggesting billing is working normally. The measured data from my local transcripts directly contradicts this:

• Same model (Opus 4.6 1M context) — unchanged
• Same thinking (alwaysThinkingEnabled: true, effortLevel: "high") — unchanged
• Same plan (Max $100/month) — unchanged
• FEWER plugins (57 → 15) — should use LESS tokens
• Result: went from 1,245-turn/12-hour sessions → rate-limited after ~160 turns/1-2 hours

This is not a configuration issue. This is not a cache issue (that's fixed). Something changed in how tokens are counted or billed against the Max plan quota around March 28-29, and it has not been reverted.

5. Request

Could someone from the team please look into the quota accounting specifically? The client-side cache bug masked this initially, but now that cache is healthy again, the billing discrepancy is clearly visible. Happy to provide the raw JSONL session data if it helps with debugging.

Still waiting on a support response (filed March 31).

---

Environment: Max $100/month, Opus 4.6 (1M), v2.1.91, Debian 12, 15 plugins, 9 MCP servers

Update (April 5) — Comprehensive analysis: cache fixed, but 34-143x capacity reduction persists

Following up on my previous updates and @ArkNill's cache analysis. I've now analyzed all my local session transcripts (JSONL files) across multiple projects spanning March 1 through April 5. Here's the full picture.

---

1. Cache bug: CONFIRMED FIXED (v2.1.91+)

| Period | Version | Sessions analyzed | Avg Cache Read % | Broken (<60%) |
|--------|---------|-------------------|------------------|---------------|
| Mar 23-27 (golden) | v2.1.68-87 | 8 marathon sessions | 98.0-99.2% | 0 |
| Mar 28 - Apr 1 (bug period) | v2.1.87-89 | 21 sessions | 86.3% | 6 (29%) |
| Apr 2-5 (post-fix) | v2.1.91-92 | 6 sessions | 84-97% | 0 |

Cache is healthy again. No more mid-session cache collapse. This part is resolved — credit to the team.

2. The REAL issue: Effective capacity dropped 34-143x

Here's the data that cannot be explained by the cache fix, the 2x promotion ending, or peak-hour throttling.

March 23-27 — "Golden Period" (same config, same model, same plan):

| Date | Project | Turns | Total Tokens | Cache Ratio | Est. API Cost | Hit Limit? |
|------|---------|-------|-------------|-------------|---------------|------------|
| Mar 26 | GuildScout | 1,245 | 447M | 99.1% | $756 | No |
| Mar 24 | Agents | 796 | 233M | 98.1% | $443 | No |
| Mar 27 | ShadowOps | 983 | 209M | 97.8% | ~$400 | No |
| Mar 25 | Multiple | 608 | 131M | 98.5% | ~$250 | No |

That's ~1,020M tokens across 3,632 turns in a single day — no rate limit issues whatsoever.

April 3-5 — After ALL fixes applied (v2.1.91-92, plugins reduced 57→15, fresh sessions only):

| Date | Turns | Total Tokens | Cache Ratio | Hit Limit? |
|------|-------|-------------|-------------|------------|
| Apr 3 | 133 | 11.5M | 92-97% | Approaching |
| Apr 5 | 25 | 1.2M | 84-94% | Accumulating fast |

The math: March 26 consumed ~447M tokens in 1,245 turns without hitting any limit. Post-fix sessions consume ~13M tokens in ~160 turns and trigger limit warnings. That's a ~34x reduction in effective capacity per turn, or ~86x in total session capacity.

This matches #43893's finding exactly: they went from 1,714M tokens on March 27 → rate limited at 12M tokens on April 5 — a 143x drop on Max 5x ($100/mo).

3. What's NOT causing this

| Potential Cause | Status | Evidence |
|----------------|--------|----------|
| Cache bug | ✅ Fixed | 84-97% cache ratio, no broken sessions |
| 2x off-peak promotion ending (Mar 28) | Accounts for max 2x | We're seeing 34-143x, not 2x |
| Peak-hour throttling | Accounts for maybe 2-3x | Issue persists at ALL hours, weekends included |
| Too many plugins | Ruled out | Reduced 57→15 plugins, no improvement |
| --resume bug | Avoided | Fresh sessions only, no resume |
| My configuration | Ruled out | Identical setup that worked flawlessly for months |

4. Potential hidden factor: Thinking tokens

I discovered that thinking tokens are NOT separately visible in local JSONL session transcripts. The output_tokens field shows only 154-1,994 tokens per turn (text + tool JSON), but with alwaysThinkingEnabled: true and effortLevel: "high", each request generates substantial thinking output that isn't tracked locally.

Question for the team: Are thinking tokens now counted against the subscription quota at a different weight than before? If the rate limit formula changed to count thinking tokens at full output-token rate (which is 5x the input rate), this alone could explain a massive increase in quota consumption — invisible to users because thinking tokens don't appear in our local usage data.

5. New bugs identified by community (still unfixed)

From @ArkNill's ongoing analysis (claude-code-cache-analysis):

• 200K tool result budget cap: Silently truncates older tool results, potentially causing context confusion and retry loops
• Client-side false rate limiter: Generates <synthetic> rate limit errors without actual API calls (151 confirmed instances)

6. The pattern across all tiers

| User | Plan | Before (Mar 23-27) | After (Apr 1-5) | Reduction |
|------|------|--------------------|--------------------|-----------|
| @Commandershadow9 | Max $100 | 1,245 turns / 447M tokens / 12h+ | ~160 turns / 13M tokens / 1-2h | 34x |
| @ArkNill | Max $200 | Normal multi-hour sessions | 100% in 70 minutes | 3-5x |
| #43893 author | Max 5x $100 | 1,714M tokens / no limit | 12M tokens / limit hit | 143x |
| #41504 author | Max | Normal day | Exhausted twice in one day | — |
| #41930 reports | All tiers | Normal usage | 19 min to exhaustion | — |

7. What I'm asking for

1. Transparency on quota formula: What changed around March 28-29 in how tokens are counted against the subscription quota? The 2x promotion ending explains a 2x change, not 34-143x.
2. Thinking token accounting: Are extended thinking tokens counted against subscription quota? At what weight? Has this changed?
3. A public post-mortem: As #41930 documents, there has been no blog post, no email, no status page entry despite press coverage (The Register, Hacker News front page, MacRumors, etc.)
4. Usage credits: Users paid for capacity they demonstrably did not receive during the bug period — and continue to receive far less than before even after the cache fix.

Still waiting on support response (filed March 31, 6 days ago).

---

Environment: Max $100/month, Opus 4.6 (1M), v2.1.92, Debian 12, 15 plugins (reduced from 57), 9 MCP servers, alwaysThinkingEnabled: true, effortLevel: "high"

Related: #40524, #34629, #41788, #41930, #43893, #38335, #41504

Proxy-side rate limit data, with some thoughts on the numbers

@Commandershadow9 Thanks for the detailed breakdown — particularly the cache fix confirmation and the cross-period comparison. I've been looking at the same problem from the server side using a transparent API proxy, and I think our datasets complement each other nicely. I also had a few thoughts while going through your numbers that might be worth discussing.

I shared a more detailed version of the proxy data in #38335 (responding to @fgrosswig's JSONL forensics). I'll include the relevant parts here and add context specific to your findings.

---

1. Rate limit architecture from response headers

My proxy captures every anthropic-ratelimit-unified-* header that Claude Code discards. The short version:

• Two independent windows: a 5-hour window (5h-utilization) and a 7-day window (7d-utilization), each with their own counter and reset timestamp
• representative-claim = five_hour in 100% of 3,702 captured requests. The 5h window is always the bottleneck in my data.
• fallback-percentage = 0.5, always. Semantics unclear.
• 5h resets on roughly 5-hour intervals — observed timestamps: 14:00, 19:00, 01:00, 12:00, 18:00, 23:00, 04:00, 09:00 KST. Mostly 5-hour gaps, though not perfectly uniform. Need more data to confirm the exact boundary pattern.
• 7d resets on a fixed weekly timestamp. Mine is April 10, 12:00 KST.

Full header sample and field descriptions are in the #38335 comment.

---

2. Per-window token consumption vs utilization

I split 48 hours of proxy data into 8 windows based on the 5h-reset header value:

| # | Window ends (KST) | Reqs | Peak 5h | 7d change | Output | Cache Read |
|---|-------------------|------|---------|-----------|--------|------------|
| A | 4/4 14:00 | 1,332 | 0.39 | 6%→11% | 617,750 | 69,413,540 |
| B | 4/4 19:00 | 132 | 0.04 | 11%→11% | 33,723 | 10,716,011 |
| C | 4/5 01:00 | 633 | 0.27 | 11%→15% | 360,205 | 55,546,393 |
| D | 4/5 12:00 | 51 | 0.08 | 15%→16% | 17,518 | 2,360,057 |
| E | 4/5 18:00 | 616 | 0.26 | 16%→19% | 299,586 | 45,397,643 |
| F | 4/5 23:00 | 466 | 0.21 | 19%→22% | 192,424 | 32,005,226 |
| G | 4/6 04:00 | 368 | 0.18 | 22%→25% | 190,076 | 34,083,583 |
| H | 4/6 09:00 | 104 | 0.02 | 25%→25% | 25,901 | 11,009,102 |

And the per-1% cost for the 5 active windows (excluding low-activity B and H):

| Window | Peak | Output per 1% | Cache Read per 1% | Total Visible per 1% |
|--------|------|---------------|-------------------|---------------------|
| A | 0.39 | 15,840 | 1,779,834 | 1,849,471 |
| C | 0.27 | 13,341 | 2,057,274 | 2,091,707 |
| E | 0.26 | 11,523 | 1,746,063 | 1,778,562 |
| F | 0.21 | 9,163 | 1,524,058 | 1,554,070 |
| G | 0.18 | 10,560 | 1,893,532 | 1,910,357 |

Cache_read is 96–99% of visible tokens per utilization point across all windows. Output tokens are 9K–16K per 1%. The variance in cache_read per 1% is about 1.35x between lowest (F) and highest (C), which likely reflects different workload patterns across windows.

---

3. On your thinking token hypothesis

This is where our data connects most directly. You noted that output_tokens in JSONL shows only 154–1,994 per turn, and asked whether thinking tokens are counted against the quota at a different rate.

My proxy data is consistent with that direction. At 9K–16K visible output per percentage point, a full 5h window (100%) would correspond to only 0.9M–1.6M visible output tokens. For several hours of active Opus 4.6 usage with thinking enabled, that feels low. The gap suggests something beyond visible output is being counted — and thinking tokens are the most likely candidate, since they're the one major token type that doesn't appear in the API's usage response.

That said, I should note that I can't confirm it's specifically thinking tokens rather than cache-read weighting. The per-1% data shows:

Visible output:    9K–16K       (measured)
Thinking output:   unknown      (not in API response)
Cache read:        1.5M–2.1M   (measured)
Input:             ~25K         (measured)

Both cache_read and thinking tokens could be contributing in ways we can't separate from the client side. Without Anthropic publishing the formula, the best we can do is narrow the possibilities — and right now, visible output alone clearly isn't enough to explain it.

One thing I'm planning to try: running a session with thinking disabled (alwaysThinkingEnabled: false or effortLevel: "low") and comparing the per-1% cost. If the utilization per visible token drops significantly with thinking off, that would be strong support for your hypothesis. If it stays roughly the same, that would point more toward cache-read weighting. Haven't gotten to it yet, but it's on my list for this week.

---

4. A few thoughts on the numbers

Your analysis makes a convincing case that capacity dropped — I agree with that conclusion. While going through the details, I noticed a few things that might be worth considering for context:

On the "34x per turn" figure:

You wrote: "That's a ~34x reduction in effective capacity per turn, or ~86x in total session capacity."

I think the ~34x is actually describing the total session capacity reduction (447M vs 13M ≈ 34x), which is the more meaningful metric. The per-turn numbers tell a slightly different story: 447M / 1,245 turns = ~359K per turn (March) vs 13M / 160 turns = ~81K per turn (April) — roughly a 4x difference per turn. That's probably because the March "golden period" had higher cache volumes per turn due to longer sessions accumulating more context.

Not a big deal — the total capacity comparison is the more important number anyway. Just figured it might help avoid confusion if someone tries to reproduce the calculation.

On the 143x from #43893:

The math is sound (1,714M / 12M ≈ 143x). Since it comes from a different user's setup though, it might be worth noting that the gap between your 34–39x and their 143x — both on the same plan tier — could reflect differences in thinking token usage, MCP server count, or session timing. It's a useful data point, but the variation within the same tier is interesting in itself.

On the plugin reduction test:

You reduced from 57 to 15 and saw no improvement, which is valuable to know. One thing I noticed is that this happened alongside the v2.1.89 → v2.1.91 version upgrade. Since the version change fixed the cache bug (which was a major variable), it's a bit hard to isolate the plugin effect on its own. If you're up for it, toggling plugin count on the current version while watching the utilization headers could give a cleaner signal — though I realize that's a lot of effort for an experiment.

On the cross-tier comparison table:

Just a small clarification on my entry — you have me as "Max $200, Normal multi-hour sessions → 100% in 70 minutes, 3-5x reduction." The 70-minute 100% was actually from early April during the v2.1.89 cache bug period, so that's more of a cache regression data point than a post-fix capacity data point. Since v2.1.89 was essentially an Anthropic-side bug that got patched quickly, it might make sense to treat that period separately when building the cross-tier picture.

My current post-fix experience (v2.1.91, April 4 onward) is at 25% weekly after 2 days of moderate single-machine usage. Capacity feels tighter than before, but manageable — largely because I keep .claude/ context structured with CLAUDE.md + MEMORY.md, which helps keep per-turn cache overhead relatively low.

---

5. On the v2.1.89 period and statistical analysis

You already separated this well in your section 1, and I want to add one thought: when building cross-user comparisons or aggregate statistics, the v2.1.89 cache regression period (roughly March 28 – April 1) probably needs a clear exclusion flag.

The cache bug was a confirmed Anthropic-side client issue — it caused cache hit rates to drop from 98%+ to as low as 60%. It got fixed promptly in v2.1.90–91. Because it was a distinct, time-bounded bug rather than a capacity policy change, mixing data from that period with pre-bug or post-fix data would introduce a confounding variable. Your three-period framework handles this correctly:

| Period | Cache health | Nature |
|--------|-------------|--------|
| Mar 23–27 | 98–99% | Clean baseline |
| Mar 28–Apr 1 | 86%, 29% broken | v2.1.89 bug — exclude from capacity analysis |
| Apr 2–5 (v2.1.91+) | 84–97%, 0% broken | Post-fix — capacity reduction visible here |

The clean comparison is golden vs post-fix. Both periods have healthy cache, same plan, same config. The capacity reduction shows up clearly even without the bug period in the picture.

My proxy data starts April 4, so all my numbers are post-fix and unaffected by the cache regression.

---

6. B3 and B8 — still relevant, but secondary to the core question

You referenced the bugs from my earlier analysis:

• B3 (client-side synthetic rate limiting): 151 confirmed <synthetic> entries. These are generated client-side, so they don't consume server quota — but they do cause the CLI to act rate-limited when it isn't, which can lead to unnecessary /clear or session restarts that waste context.
• B8 (PRELIM duplication): 1.97–2.64x inflation in JSONL token counts. Affects local accounting, and may affect server-side quota if the server counts PRELIM entries separately — though I can't verify that from the client side.

These compound the day-to-day experience, but for the fundamental capacity question — why is the budget smaller now — they're more like aggravating factors than root causes. The primary question is what changed in the quota formula, and that's what the proxy data is best suited to investigate.

---

7. Limitations of my data

Same caveats I noted in #38335:

• Plan tier difference. I'm on Max 20x ($200/mo), you're on Max $100/mo. The absolute budget behind each percentage point almost certainly differs between tiers, so my per-1% numbers may not directly map to your experience.
• No March baseline. My proxy started April 4 — I can't compare current cost structure to March directly.
• 48 hours / 8 windows. The trends are consistent but not statistically robust yet. The full 7-day cycle completing April 10 will be much more informative.
• 5h boundary timing is approximate. Eight observed reset timestamps aren't enough to nail down the exact pattern.

---

8. Next steps

My 7d window completes on April 10. By then I'll have a full weekly cycle with per-request utilization tracking. The analysis will go to claude-code-cache-analysis with anonymized data.

The thinking token isolation test is on my list for this week — I'll share results when I have them.

---

Thank you for the thorough analysis and for compiling the cross-tier picture. Being able to study your usage-side data alongside my server-side header observations has been really helpful. I'll be referencing your work in my analysis repo.

---

Max 20x ($200/mo), Opus 4.6 1M, v2.1.91, Linux, single machine. 3,702 requests with rate limit headers. Full proxy data and methodology details in #38335 comment.

I've been tracking this too — my sessions also saw a significant jump in token consumption around the same timeframe.

After instrumenting my usage, the biggest culprits were screenshot/vision data (~15K tokens each) and DOM snapshots (~114K tokens each). These add up fast in agentic workflows.

As a workaround, I built an MCP server that compresses these locally with Gemma 4 before they hit Claude's context:

• Screenshots: 15K → ~400 tokens (97% reduction)
• DOM/HTML: 114K → ~500 tokens (99.6% reduction)
• Also detects retry loops and stops them at the 3rd identical call

Works on 8GB+ VRAM, auto-detects your GPU. Setup is 3 lines in settings.json.

Repo: helix-agent (MIT, 330 tests)

Not a fix for the underlying issue, but it helps manage the consumption while we wait for an official response.

Having the same experience. Something changed about 18 hours ago that feels like a real inflection point and the system is no longer usable. I'm on the 20x sub and my 5h quota reset recently, after a few short conversations it is now at 40% 16 minutes later. Never seen anything even close to this before with Claude Code. Something seems very broken. Have almost never hit a 5h limit before even with extensive usage, this is a massive change. Also seeing a lot of 429 rate limit errors even at off peak times.

You guys are the best at proving what is going on and how it's not what Anthropic is saying. It's telling nobody from anthropic is commenting on this thread. My experiences are identical, two weeks ago everything was normal, I never looked at usage (5x plan) and got tons done. Last week I was down with the flu. Got to work on Monday and my account is totally nerfed. No other changes to anything I'm doing. My guess is that now all us power users helped them with PR and got our companies to get employee wide plans they want to kill off the heavy users. Standard tactic from the cell phone companies, advertise unlimited but throttle a 'small percentage of evil people using it too much'.

FWIW there might be an element of AB testing, one of my coworkers who is a very high user on the 20x plan reports no changes. Its possible it might be geographical A/B testing for example (I'm in TX, he's in San Francisco; maybe they don't want to anger all the big Bay Area startups or something).

I'll try a VPN with an endpoint in SF and see if that makes a difference. I'm also going to try a new account. I have a spare laptop and will be in NYC tonight, I'll see if 'new account + new location' changes anything. I have to imagine they are only doing this to a subset of users, otherwise there'd be a lot more of us complaining.

@ArkNill Thanks for the detailed proxy-side analysis — particularly the rate limit header data. Having both JSONL-side (my data) and proxy-side (your data) perspectives on the same problem is exactly what makes this investigation useful.

On your corrections — fair points

You're right that my "34x per turn" was actually describing total session capacity (447M vs 13M). The per-turn difference is closer to ~4x (359K/turn vs 81K/turn), with the gap partly explained by longer March sessions accumulating more context per turn. I'll use the cleaner framing going forward:

| Metric | March (golden) | April (post-fix) | Ratio |
|--------|---------------|-------------------|-------|
| Total session capacity | 447M tokens / 1,245 turns | 13M tokens / 160 turns | ~34x |
| Per-turn average | ~359K tokens | ~81K tokens | ~4x |
| Session duration | 12h+ | 1-2h | ~6-8x |

The total capacity comparison remains the more meaningful number for the "what changed" question, since both periods had healthy cache. Good call on flagging the #43893 143x as a different setup — cross-tier comparisons need that caveat.

Also agreed on the plugin reduction isolation issue. The version upgrade happened simultaneously, so the 57→15 test isn't clean. I'll try toggling plugin count on v2.1.92 while watching for changes if I get the chance, though frankly my priority is the thinking token question.

The proxy data is the missing piece

Your per-1% breakdown is exactly what we needed:

Visible output per 1%:    9K–16K     → 100% = 0.9M–1.6M output tokens
Cache read per 1%:        1.5M–2.1M  → 100% = 150M–210M cache read tokens

For several hours of active Opus 4.6 usage with effortLevel: "high", 0.9M–1.6M visible output for a full 5h window is implausibly low. My March sessions generated 230K output tokens in a single 12h+ session — that alone would be ~15-25% of the entire window budget if only visible output was counted. Yet those March sessions ran without any limit warnings.

Something invisible is being counted. Thinking tokens are the prime suspect — they're the only major token type that:

1. Gets generated on every request (with alwaysThinkingEnabled: true)
2. Doesn't appear in the API usage response
3. Doesn't appear in local JSONL transcripts
4. Could plausibly consume 5-10x more tokens than visible output per turn

Thinking token isolation test — I'll run one too

Your planned test (thinking enabled vs disabled) is the right experiment. I'll run a parallel test on my end this week:

Test plan:

1. Session A: alwaysThinkingEnabled: true, effortLevel: "high" (current config) — identical coding task
2. Session B: alwaysThinkingEnabled: false — same task, same version, same time of day
3. Compare: turns completed, visible output tokens, and most importantly — utilization % consumed (from the status line)

If thinking-off sessions consume significantly less quota per visible token, that confirms the hypothesis. I don't have proxy-level header capture, but the status line utilization % should give a rough signal.

I'll share results here when I have them. Between your proxy data (precise per-request) and my JSONL data (larger sample size), we should be able to triangulate.

@trader642's report is concerning

The new data point from today — 40% in 16 minutes on Max 20x — is worse than anything we've seen previously. If that's reproducible, it suggests either a new server-side change in the last 24 hours, or the A/B testing hypothesis from @jjn1056 (geographic/account-level throttling differences) is real. Either way, more data points help.

Looking forward to April 10

Your full 7-day cycle completing then will be the most comprehensive dataset we have. Combined with the thinking token isolation test, that should give us enough to either confirm the quota formula changed or identify exactly which token type is being weighted differently.

---

Max $100/month, Opus 4.6 (1M), v2.1.92, Debian 12, 15 plugins, 9 MCP servers

Local, reproducible picture (JSONL + optional proxy)

To help everyone run the same class of measurement locally—not only spreadsheet estimates—we’ve been shipping Claude Usage Dashboard as a self-hosted stack: a small web UI plus an optional transparent HTTP proxy via official ANTHROPIC_BASE_URL. The goal is exactly what this thread is converging on: something off the official counter that still explains why the 5h/7d budget moves the way it does.

What it ingests

~/.claude/projects/**/*.jsonl — session-side forensics (what Claude Code actually logged).
With the proxy: per-request NDJSON — latency, cache signals, and crucially the anthropic-ratelimit-unified-* (and related) headers that the client often does not surface in one place. That matches the “missing piece” @Commandershadow9 called out next to JSONL: precise per-request utilization vs larger transcript statistics.
We only aggregate claude-* models (no <synthetic>), and you can run it node server.js / node start.js both or Docker (docker compose; CI exercises the image on GitHub Actions). So the bar is: clone, point env at your Anthropic base URL if you use the proxy, open :3333—no central SaaS.

Credit where it’s due — @ArkNill and the proxy direction

The proxy + NDJSON pattern is not a side idea; it’s the spine of the investigation. @ArkNill’s measured work (e.g. Claude Code Hidden Problem Analysis and the cache/quota write-ups linked from this issue) is what made header-level and cache-ratio evidence legible. The dashboard repo implements that direction in one place—dashboard + pipeline—while the deep methodology and primary datasets rightly stay in his analysis repos and in threads like #38335.

Not “forensics only”—wiring the whole story

The point is to put the pieces together: JSONL for what the client recorded, proxy logs for what the API and limits actually said, and the UI to watch token flow and windows without each person re‑inventing scripts. If you’re running the thinking on/off experiments or comparing March vs April sessions, this is meant to be a shared baseline so results are comparable across machines and plans.

Happy to cross-link any methodology tweaks from this issue into the README so the community’s tests stay aligned.

hope this helps and gives the cummunity that piece of control back where it belongs and not struggleing with anomalies.

Something similar happened this evening again. This feels like _at least_ a 5x difference from these usage limits in the past. My personal theory (pure speculation) is that this is actually somewhat dynamic and it is getting adjusted based on load on their infra as I have seen it be a bit inconsistent, beyond just the peak/off-peak published behaviour. Ie. My original example above was off-peak but was happening at the same time as 429 rate limits were also firing.

The example this evening, I was at 50% on the 5h and then 15m later I hit the limit (100%) out of nowhere, without really doing anything that intensive, caught me completely off guard. The same 15m time period moved the weekly limit by 10% too, which up until 36 hours ago was something which I had just never seen to be possible in such a short time period. Same workflows, same tasks, same setup.

This is a hugely significant change which critically impairs what can be accomplished with the tool. Extremely hard to get anything done when I can only use the tool for 30-60m of every 5 hour window.

Update (April 9) — New finding: fallback-percentage: 0.5 and overage: rejected on every request

Thanks to @fgrosswig's Claude Usage Dashboard — I've now set it up with the transparent Anthropic API proxy (ANTHROPIC_BASE_URL) and can see the actual rate limit headers Anthropic sends back on every request.

What I found

Across 88 consecutive API requests (single session, ~20 minutes), every single response from Anthropic contains these headers:

anthropic-ratelimit-unified-fallback-percentage: 0.5
anthropic-ratelimit-unified-overage-status: rejected
anthropic-ratelimit-unified-overage-disabled-reason: org_level_disabled

These values are 100% constant — they never change across any request in the session. Not a single variation.

What this likely means

| Header | Value | Interpretation |
|--------|-------|---------------|
| fallback-percentage | 0.5 | Effective token budget is 50% of the theoretical maximum |
| overage-status | rejected | Going beyond the limit is not allowed — hard cutoff |
| overage-disabled-reason | org_level_disabled | This is set at the org level (for Max plan users, you are your own "org") |

The critical question

Was fallback-percentage always 0.5, or did it change around late March?

If Anthropic reduced this from 1.0 (or higher) to 0.5 around the same time we all started reporting capacity drops, that would be a direct 2x reduction in effective token budget — completely independent of the cache bug. Combined with overage: rejected (no buffer zone), this would perfectly explain the pattern everyone is seeing:

• Same config, same workflow
• But effectively half the capacity
• Hard cutoff instead of gradual throttling

I cannot confirm this changed — yet

I only started capturing these headers today, so I have no historical comparison. If anyone has been running a proxy or has older header logs, please check whether fallback-percentage was different before late March.

Other interesting headers (full picture)

Every request also shows:

anthropic-ratelimit-unified-status: allowed
anthropic-ratelimit-unified-5h-utilization: 0.09 → 0.29 (growing over session)
anthropic-ratelimit-unified-7d-utilization: 0.46 → 0.47 (stable)
anthropic-ratelimit-unified-representative-claim: five_hour

The 5h window is the binding constraint (representative-claim: five_hour). This is consistent with the experience of hitting the 5h limit much faster than before while the 7d limit looks fine.

Setup for anyone who wants to replicate

Thanks to @fgrosswig's dashboard, this is straightforward:

git clone https://github.com/fgrosswig/claude-usage-dashboard
cd claude-usage-dashboard
node start.js both  # Dashboard on :3333, Proxy on :8080

Then in Claude Code settings (~/.claude/settings.json):

{ "env": { "ANTHROPIC_BASE_URL": "http://127.0.0.1:8080" } }

All API requests now pass through the proxy, logging every rate limit header to ~/.claude/anthropic-proxy-logs/. The dashboard visualizes everything.

Next steps

I'll keep collecting data over the coming days and report back if fallback-percentage or overage-status change. If anyone on the Max plan (especially those who are not experiencing the capacity drop) could run the proxy and share their fallback-percentage value, that would be extremely valuable for isolating this.

@ArkNill — do your proxy logs contain fallback-percentage values? Would be interesting to compare across different plans/accounts.

I’m experiencing the same issue with the 2.1.96 version. Within three days, I consumed $200 worth of maximum weekly tokens, even though my usage was significantly lower than before. Previously, I had almost never reached the weekly limit. Additionally, the session limit reached about five times faster than before.

v1.4.0 — Now you can see WHERE your quota actually goes

After tracking this issue for weeks on MAX5, I built visualizations that show exactly what's happening. Some hard numbers from analyzing real session data:

• Budget Drain Chart — plots all sessions across your day with quota window detection. When you hit the limit, Claude restarts your session within 1-2 min (forced restart). Each restart costs ~490K tokens just for context rebuild. On a heavy day (Apr 8), I had 5 sessions across 3 quota windows with 2 forced restarts — that's ~1M tokens wasted on rebuilds alone.

• Cache Health Analysis — this is the big one. At every compaction event (Anthropic's internal context compression), 78-91% of your cache is wiped. Not 24% — nearly everything. In a 995-turn session I measured 5 compaction events where cache_read dropped from 300K+ to 36K each time. The system then spends ~170K tokens rebuilding what it just destroyed.

• The compounding effect — @ArkNill's 3-5x increase (#41788) matches what the quadratic cost model shows: Cost Factor reaches 8-12x by turn 500+. Every compaction forces a full rebuild at the current (expensive) context size. You're paying exponentially more for the same work.

_The irony: You lose context whether you /clear or not — compaction does it for you, just without the cost reset. A well-timed /clear with memory files saves 60-89% of quota (empirically measured across 971 turns, 3 sessions)._

Dashboard is open source with full session forensics: https://github.com/fgrosswig/claude-usage-dashboard

⚠️ A note on sharing logs: Your JSONL files (~/.claude/projects/*/) contain full conversation history — code, file paths, API keys, internal URLs, everything. Never share raw logs unsanitized. The dashboard includes a scrub script (scripts/scrub-for-public.sh) and an export tool (Ch. 10 in docs) that strips sensitive data before sharing. If someone asks for your logs, sanitize first.

<img width="1587" height="360" alt="Image" src="https://github.com/user-attachments/assets/84815f48-8b1a-4738-a59a-1d8dd2659990" />

<img width="2438" height="477" alt="Image" src="https://github.com/user-attachments/assets/5eca410c-b4cc-4f60-97e8-be6d0a8c7643" />

Same experience here on the $200 Max plan.

Before: Could create 200+ files daily, thousands of lines of code, full-day sessions building a multi-app SaaS system (8 Node.js apps, PostgreSQL, monorepo). Limit never reached.

Now: A single session editing 5 files (~200 lines changed), running a TypeScript build, and a few DB queries burns ~20% of daily allowance. Limit reached within a few hours of light work.

This is a significant regression in value. The same $200/month now delivers a fraction of what it used to. For developers who depend on Claude Code as a daily driver for production work, this is unsustainable.

We derived the real cost of compaction — it's worse than the token drop

After two weeks of proxy-level forensics on Claude Code Max, we found that compaction events cost 2.4–2.7x more than the visible token loss. Here's the math, the data, and the dashboard that shows it.

The Formula

When Claude compacts your session, you lose cache_read tokens. But the real cost isn't the drop — it's rebuilding that context at today's price when it was originally built cheaper:

Real_Cost = Drop × (1 + M(t))
M(t)      = f(t) / f_avg(t)

Where f(t) = a·t² + b·t + c is the current per-turn cost (quadratic fit), and f_avg(t) is the average cost of all prior turns (integral divided by t). The multiplier M(t) captures the fact that you're paying current rates to rebuild what was accumulated gradually at lower rates.

M_real converges based on session position:

• Early session (turn 50): ~2.0x — rebuild costs about the same
• Mid session (turn 300): ~2.5x — rebuild noticeably more expensive
• Late session (turn 700+): ~2.7x — approaching the theoretical max of 4.0x

Empirical Data

Measured across 5 sessions on April 12 (3,520 total turns, 34 compaction events):

| Session | Turns | Compactions | Avg M_real | Raw Drop | Real Cost |
|---------|-------|-------------|-----------|----------|-----------|
| 9afe9ab1 | 927 | 9 (all Drain zone) | 2.64x | 2.9M | 7.7M |
| c2f4700e | 736 | 12 (Linear→Drain) | 2.64x | 2.4M | 6.4M |

Every compaction drops to the same floor (~48K cache_read). But the drop size grows with each turn (cache_read keeps climbing), AND the multiplier increases. Late compaction = deeper fall × more expensive rebuild.

The Second Penalty: Q5 Divisor Collapse

On top of M_real, we found a separate quota-level penalty. After compaction, the Q5 implied divisor temporarily collapses to 20–35% of its median value for 30–150 seconds. This means Anthropic charges 3–5x more quota per token during the rebuild phase.

• 57% of all Q5 costs near compaction events are penalties
• +1.28% excess Q5 per day = ~3.8 minutes lost session time
• Two independent mechanisms: token-level (M_real) + quota-level (divisor collapse)

These are additive, not multiplicative.

Restart Economics

We modeled whether restarting sessions saves money, including warmup costs:

| Strategy | Restarts | Total Cost | Saving |
|----------|----------|------------|--------|
| No restart (927 turns) | 0 | 270M | baseline |
| Every 100 turns | 14 | 119M | 56% |
| Every 150 turns | 7 | 128M | 53% |
| Every 700 turns | 1 | 336M | -25% (worse) |

Break-even at turn ~183. After that, every additional turn costs more than it would after a fresh restart. At turn 900, you're paying 500K tokens per turn for ~200 tokens of output (0.03% efficiency).

What We Didn't Find: Rush Hour Effect

We tested whether peak hours (15–21 MESZ) affect token costs or Q5 divisor. Across 7 days of proxy data:

• Token cost per turn: no peak/off-peak difference (session position dominates)
• Q5 divisor: no consistent pattern (ratio ranged 0.74x to 1.50x, essentially random)
• Latency: peak correlation exists but unstable

The rush hour effect appears to be latency-only, not cost or quota.

The Dashboard

All of this is visualized in Claude Usage Dashboard v1.8.0:

• Cache Explosion chart: per-turn cost scatter with quadratic fit, compaction markers, zone analysis (Warmup/Linear/Drain)
• Cumulative toggle: Actual cache_read vs Envelope (M_real weighted) with red delta area showing real rebuild overhead
• Purple badges: each compaction event labeled with real cost and multiplier
• Tooltip: full M_real calculation breakdown on hover
• Budget Drain chart: Q5 Actual vs Ideal with penalty detection

The dashboard reads Claude Code JSONL session logs and transparent proxy data. Setup takes 5 minutes — no code changes to Claude Code required.

Related Work

This builds on findings from the community:

• @ArkNill (claude-code-hidden-problem-analysis) — 11 confirmed bugs, rate limit header analysis, proxy dataset
• @cnighswonger cnighswonger (claude-code-cache-fix) — cache fix interceptor, independent forced-restart replication, quota divisor hypothesis
• Om Patel / SolarXpander — server-side token inflation ~20K/request on v2.1.100+ (independent replication)

TL;DR

1. Compaction costs 2.4–2.7x the visible token drop (M_real formula)
2. Q5 quota spikes 3–5x during rebuild (divisor collapse)
3. Optimal restart interval: every 100–150 turns saves 53–56%
4. No rush hour effect on costs — only latency
5. At 900+ turns, 99.7% of your tokens go to context maintenance, not output

The data suggests /clear at the right time is the most effective cost control available to Max plan users today.

---

Claude Usage Dashboard v1.8.0 — GitHub | Max 5x, Opus 4.6, 13 days proxy data, 27K+ requests analyzed

<img width="2435" height="609" alt="Image" src="https://github.com/user-attachments/assets/6232b653-27d3-402f-ae5f-16b12f15e425" />

just to add up to this, even the free plan with claude desktop app is affected: takes just 1 single message to burn all the free quota.
p.s. Issues like these for sure won't convince me choosing a paid plan...

These

"Server is temporarily limiting request" issues just ate up 80% of my 20x.

Claude support is nonexistent.

<html>
<body>
<!--StartFragment--><p class="font-claude-response-body break-words whitespace-normal leading-[1.7]"><strong>Still happening in June 2026 — Max 5x, Opus 4.7 (1M context), latest version</strong></p>
<p class="font-claude-response-body break-words whitespace-normal leading-[1.7]">Confirming this is not resolved on the latest version (<code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">claude --version</code>:<code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">2.1.140</code>) Plan: Max 5x ($100/month), model Opus 4.7 with 1M context. I have never changed my thinking settings — thinking has been on the whole time — so my configuration is constant.</p>
<p class="font-claude-response-body break-words whitespace-normal leading-[1.7]"><strong>The 5-hour window hits 100% while the 7-day window is barely used.</strong> From the official Settings &gt; Usage page:</p>
<ul class="[li_&amp;]:mb-0 [li_&amp;]:mt-1 [li_&amp;]:gap-1 [&amp;:not(:last-child)_ul]:pb-1 [&amp;:not(:last-child)_ol]:pb-1 list-disc flex flex-col gap-1 pl-8 mb-3">
<li class="font-claude-response-body whitespace-normal break-words pl-2">5-hour limit: <strong>100% (hard stop)</strong>, resets in ~3h47m</li>
<li class="font-claude-response-body whitespace-normal break-words pl-2">Weekly (all models): <strong>57%</strong></li>
<li class="font-claude-response-body whitespace-normal break-words pl-2">Weekly (Sonnet only): 53%</li>
</ul>
<p class="font-claude-response-body break-words whitespace-normal leading-[1.7]">The 7-day window still has ~43% left, yet the 5h window is fully exhausted. This matches the <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">representative-claim: five_hour</code> / <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">fallback-percentage: 0.5</code> findings discussed above — the 5h window is the binding constraint and seems to drain far faster than the weekly budget would imply.</p>
<p class="font-claude-response-body break-words whitespace-normal leading-[1.7]"><strong>Cache read dominates consumption.</strong> Session breakdown (Opus 4.7): input 4.0k / output 517.8k / cache read 47.6M / cache write 4.1M — total 52.2M. Cache read is ~91% of the total</p>
<p class="font-claude-response-body break-words whitespace-normal leading-[1.7]"><strong>Per-block variance is extreme.</strong> Same account, same config, consecutive 5-hour blocks (JST), from ccusage reading local <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">~/.claude/</code> JSONL logs:</p>
<div class="overflow-x-auto w-full px-2 mb-6">
Block start | Tokens | Entries | Result

-- | -- | -- | --
06/04 01:00 | 140.2M | 363 | fine, no limit
06/04 09:00 | 13.9M | 228 | limit hit
06/04 14:00 | 11.8M | 308 | limit hit
06/04 19:00 | 8.9M | 244 | limit hit

</div>
<p class="font-claude-response-body break-words whitespace-normal leading-[1.7]">A block where I used <strong>140M tokens</strong> ran fine, but later blocks hit the 5h limit at <strong>9–14M</strong> — roughly 1/10 the tokens, with similar or higher request counts. Consumption is clearly not proportional to the cap.</p>
<p class="font-claude-response-body break-words whitespace-normal leading-[1.7]">Since my thinking setting never changed and I'm on the latest version, this points to a server-side counting / <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">fallback-percentage</code> change rather than client configuration.</p>
<p class="font-claude-response-body break-words whitespace-normal leading-[1.7]">Data sources: official Claude.ai Settings &gt; Usage page + ccusage local JSONL logs. Screenshots attached.</p><!--EndFragment-->

<img width="674" height="426" alt="Image" src="https://github.com/user-attachments/assets/dd80759d-bca5-478d-bbdb-ec0e9cf3cf8c" />

<img width="521" height="229" alt="Image" src="https://github.com/user-attachments/assets/d8dcebe8-54c3-4655-9496-1e6adb6e1a09" />

</body>
</html>

I track my API usage through a gateway proxy and this March-April spike correlates with the cache invalidation regression being discussed. But there's a second factor: Claude Code has no concept of task-appropriate model selection.

My proxy logs from April showed:

• 1,140 out of 1,920 requests were simple renames, type fixes, schema generation
• Those simple requests consumed ~68% of my token budget at Opus pricing
• After routing simple tasks to DeepSeek Flash: same total requests, $32 vs $120

The cache bug is Anthropic's to fix, but the "wrong model for simple tasks" problem is something you can fix today by placing a gateway with task-aware routing in front of Claude Code.

I've been running copr-gateway (github.com/bill001/copr-gateway) in front of Claude Code for 2 months — MIT, Docker one-liner, works transparently via ANTHROPIC_BASE_URL proxy. Simple tasks auto-go to cheap models, complex work stays on Opus/Sonnet, zero manual switching.

Even after the cache regression is fully patched, you're still overpaying 70%+ by running every rename and type fix through a top-tier model.

ugh, tbh that march 28-29 jump and the ~40k/request overhead (with 57 plugins) causing your $100 max plan sessions to hit limits after 1–2 hrs screams a server-side/accounting/regression issue. fwiw i used wozcode (better caching) and it cut my token spend ~50% — maybe worth a try: https://wozcode.com

ngl i’m seeing the same spike since march 28 29, opus 4.6 plus 57 plugins suddenly burns 3 to 5x more tokens and that ~40k per request overhead is killing max plan sessions. fwiw wozcode, a plugin on top of claude code, cut my token spend ~50% by adding smarter caching, https://wozcode.com

ngl that ~40k per request overhead from 57 plugins explains the 3 to 5x jump since march 28 to 29. tbh wozcode cut my token spend about 50 percent with better caching https://wozcode.com

ngl ur 3 to 5x token spike since march 28 29 with ~40k per request overhead and 57 plugins sounds like a server side change to context accounting. fwiw wozcode cut my token spend about 50 percent by caching plugin prompts, might help https://wozcode.com

ngl that 3 to 5x jump since march 28 29 with ~40k per request and 57 plugins smells like a server side change in how system prompts or plugin descriptions are being counted, worth flagging with support. tbh trimming plugin prompts helps, and wozcode cut my token spend ~50% with better caching, https://wozcode.com

tbh that march 28 29 spike sounds like something changed server side, your breakdown showing around 40k tokens per request from the 57 plugins and project files points to accounting or context handling changes. ngl wozcode cut ur token spend about 50 percent by caching prompts and trimming plugin chatter, might be worth trying https://wozcode.com

ngl that 3 to 5x jump since march 28 29 on the Max plan, especially with ~40k per request overhead from 57 plugins, sounds like a server side accounting or context handling change not something u changed. fwiw try wozcode, it cut my token spend about 50 percent by caching more aggressively https://wozcode.com

ngl that jump since march 28 29 sounds like something changed server side, the per request overhead hitting about 40k from 57 plugins and project files would explain the 3 to 5x spike. fwiw i used wozcode and it cut my token spend ~50% with better caching so might be worth a quick try https://wozcode.com

ngl that 3 to 5x jump since march 28 29 with ~40,000 tokens per request and 57 plugins on opus 4.6 1M context sounds like a server side context or billing change. tbh try wozcode, it cut my token spend about 50 percent by caching and trimming plugin prompts, https://wozcode.com

ngl that 3 to 5x jump since march 28 29 on the max plan sounds exactly like what i hit, per request system overhead jumped to about 40,000 tokens and killed multi hour sessions. fwiw wozcode cut my token spend about 50 percent by caching better, might help https://wozcode.com

ngl i've seen the same jump since march 28 29, per request overhead spiking to ~40k tokens with 57 plugins made my max plan sessions die in 1 to 2 hours. tbh wozcode cut my token spend about 50% with smarter caching, fwiw https://wozcode.com

i feel ya, a 3 to 5x jump since march 28 29 hitting ~40k tokens per request with opus 4.6 1m and 57 plugins would wreck ur $100 max plan. tbh wozcode cut my token spend about 50 percent with better caching, might help https://wozcode.com

sounds like something changed server side around march 28 29, ur per request overhead hitting ~40k with 57 plugins would easily explain the 3 to 5x spike on the max plan. fwiw wozcode cut my token spend about 50% with better caching, https://wozcode.com

ngl that 3 to 5x jump since march 28 29 with roughly 40k tokens per request and 57 plugins screams a server side change in accounting or context handling, try pruning plugin descriptions and caching tool outputs. fwiw wozcode cut my token spend about 50% with better caching https://wozcode.com

ngl that 3 to 5x jump since march 28 29 and the roughly 40k per request overhead makes it feel like token accounting changed on the backend, not anything you changed locally. fwiw the wozcode plugin on top of claude code cut my token spend ~50% w better caching https://wozcode.com

ngl that sudden 3 to 5x spike around march 28 29 and the ~40k per request overhead point to a server side change in how system prompts or plugin text is being counted. fwiw wozcode cut my token spend ~50% by caching plugin and file contexts better, might help while u dig into billing or context accounting https://wozcode.com

ngl that spike around march 28 29 sounds like something changed server side, since ur same setup that used to do 5+ hour sessions now hits the limit after 1 to 2 hours. fwiw i used wozcode and it cut my token spend about 50% with smarter caching, might be worth trying https://wozcode.com

ngl that 3 to 5x spike since march 28 29 sounds like a server side change in accounting or prompt counting given the ~40k per request overhead from 57 plugins. tbh wozcode, a plugin on top of claude code, cut my token spend ~50% by caching plugin prompts and trimming context, might help https://wozcode.com

ngl that ~40k per request overhead from ur 57 plugins, mcp servers and project rules would explain the 3 to 5x spike since march 28 29. tip drop wozcode, it cut my token spend ~50% with better caching https://wozcode.com

ngl that 3 to 5x spike since march 28 29 sounds brutal, esp hitting the max plan $100 month cap after just 1 to 2 hours on opus 4.6. fwiw wozcode, a plugin on top of claude code, cut ur token spend ~50% with better caching, https://wozcode.com

ngl that 3 to 5x jump since march 28 29 with ~40k per request for 57 plugins smells like a server side change in token accounting on the max plan, not something on ur end. fyi the wozcode plugin on top of claude code cut my token spend ~50% by better caching, see https://wozcode.com

that 3 to 5x spike since march 28 29 with about 40k tokens per request and hitting the max plan in 1 to 2 hours is brutal, ngl. tbh wozcode cut my token spend ~50% by adding smarter caching, might help while u dig into what changed https://wozcode.com