[BUG] Critical: Widespread abnormal usage limit drain across all paid tiers since March 23, 2026 — multiple root causes identified, no formal communication issued

yeah this is insane.

I can confirm usage has spiked drastically recently.
I set it to low and asked it to commit a couple of files and it used 20% of my Session Usage.
I submitted a Plan and it jumped from 0% to 40% immediatelty.
I don't think I'm using any MCP's, tools or skills that would explain this recent jump or spikes in usage.
I can't even do a 30 minute session without it eating up all my Usage and I'm already 31% into my weekly usage from 3 Sessions.

Confirmed — same issue here on Max $200 tier, limit drained in ~70 minutes.

Root cause appears to be two client-side cache bugs:

• Sentinel bug: standalone binary replaces cch=00000 placeholder → breaks cache prefix (#40524)
• Resume bug: deferred_tools_delta since v2.1.69 → cache miss on session resume (#34629)

I've documented the analysis and a temporary client-side workaround here, but this is a stopgap at best — it shouldn't be on users to patch the client. Anthropic needs to ship an official fix and communicate clearly with paying customers about what happened and when it will be resolved.

Same issue.

+1, same here - currently on a 5x Max Plan. The usage now feels even worse than the Pro subscription when I tried it a few months ago.

Follow-up — practical precautions (April 2, 2026)

Since my earlier comment, further testing revealed several behaviors that accelerate token drain on top of the cache bugs:

Avoid

• --resume — replays entire conversation history as billable input. One resume on a long session = 500K+ tokens burned instantly. Start fresh sessions instead.
• /dream, /insights — hidden background API calls that consume tokens silently
• v2.1.89 — cache bug still present + terminal content rendering regression (Linux/IntelliJ)

Be careful with

• Sub-agents (Agent tool) — Haiku calls get 0% cache read (317K tokens across 31 calls measured)
• Multiple terminals — each is independent, drains quota in parallel
• Large context files (CLAUDE.md, etc.) — resent as input every turn

What helps

• Fixed older version (v2.1.81) + cache patch
• Fresh sessions + structured CLAUDE.md for context (not --resume)
• Local proxy monitoring via ANTHROPIC_BASE_URL
• One terminal, minimal sub-agents

Note: even with cache working at 91-99%, several users (including myself) still see faster consumption than 2 weeks ago — suggesting a server-side change in limit calculation that we can't fix client-side. These precautions help stretch whatever budget remains.

Ref: 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:

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

I can confirm the issue is still present.
v2.1.88-89 consumes the Max 20 7-days limit in about 2 MD with two active sessions.
v2.1.90 consumes the Pro 5-hour limit in about 25 minutes with one active session.
This occurs during simple coding and PR reviews.

As someone who is currently looking at a $47,030 bill increase -- not amused.

Been dealing with this since late February/Early March when the fast variant of 4.6 was released. I noticed the normal variant of 4.6 became much slower and less powerful, whilst 4.6 fast produced mediocre results at the same speeds 4.6 used to be. While that's happening, the limits became unbearable. I used to feel like the $200 plan would never run out. Even during 2x, I'd often have 70-80% left, but I can't even get a fraction of that same work done without running out of usage.

Update — v2.1.91 tested, root causes fully mapped

This issue's title ("multiple root causes identified") turned out to be more accurate than expected. After systematic proxy-based testing on April 3, the full picture is now documented:

6 layers, 11 bugs. Cache layer is fixed (v2.1.90-91). Five bugs remain:

1. Tool result budget enforcement (200K cap, new discovery — #42542 comment)
2. Silent microcompact (158+ events, context quality issue)
3. Client-side false rate limiter (151 <synthetic> entries — #40584)
4. JSONL log duplication (2.87x inflation — #41346)
5. Server-side factors (peak-hour limits, 1M billing)

@kryvel @KikiranLLC Regarding the reports in this thread: if you're on v2.1.91 and still seeing rapid drain, the 200K tool result cap (Bug 5) is the most likely culprit for heavy coding sessions. The $47K bill report is concerning and likely warrants a direct support ticket referencing the server-side accounting issues documented in #42616.

Analysis repo with per-request data: claude-code-cache-analysis

My experience as a Max subscriber — usage limits are now unusable for professional work

I'm a Max plan subscriber who purchased Claude Code specifically for work. Before the March changes, I could comfortably run 25+ complex tasks within a single 5-hour session window — the limits were perfectly fine for my workflow.

Now, a single complex task drains my entire 5-hour session limit.

This is not a minor inconvenience — this fundamentally breaks the tool for professional use. I'm paying for a Max subscription to use Claude Code during working hours, and that's exactly when I can't use it. The whole point of paying a premium was to have reliable, uninterrupted access for work.

What changed for me:

• Before (pre-March 23): 25+ complex tasks per 5-hour session — no issues
• After: 1 complex task = entire session limit gone
• Version: Claude Code v2.1.90
• Plan: Max subscription

The core problem:

1. No transparency: Anthropic reduced session limits during peak hours without directly notifying subscribers. No email, no in-app notification, no blog post — just a personal tweet from an engineer.
2. No predictability: There are no published token limits, so I cannot plan my workday around them. I have no way to estimate how many tasks I can run before getting locked out.
3. Paying customers can't use the product during work hours: If I'm paying $100-200/month for a professional tool that I can only reliably use at 2 AM, then it's not a professional tool — it's a hobby tool with premium pricing.

What I expect:

• Published, concrete usage limits — not vague multipliers like "5x Pro." Tell us the actual token budget so we can plan.
• Transparent communication — if limits change, email your paying subscribers before the change, not after the community discovers it.
• Refunds or credits for the period where the service was effectively unusable during business hours.
• A real fix — not just "shift your work to off-peak hours." That's not a solution for professionals.

I chose Claude Code over competitors because the quality was genuinely better. But quality means nothing if I can't actually use the tool when I need it. If this isn't resolved soon, I'll be forced to switch to an alternative and request a refund.

@Nobody9512 Completely agree. Especially on the transparency point — there are no published token limits, no way to estimate how many tasks fit in a session, and the only official communication was a personal X post. That's not how you run a paid professional service.

I've been spending the last 3 days building a monitoring proxy and running benchmarks just to understand what's happening under the hood. No paying customer should have to do that. The fact that the community had to reverse-engineer the rate limit behavior, discover hidden GrowthBook flags, and document 7 separate bugs across 91 issues — all without a single official GitHub response — says a lot about where communication stands right now.

The engineering team is clearly capable. But published limits, proper changelogs for quota changes, and a real support channel would go a long way.

<img width="539" height="75" alt="Image" src="https://github.com/user-attachments/assets/1edbcb2a-fa94-46a7-afaa-ffa564b67a35" />

I only said “hello” Come on, this has to be fixed soon! (Max 5x)

Update — v2.1.91 tested, root causes fully mapped This issue's title ("multiple root causes identified") turned out to be more accurate than expected. After systematic proxy-based testing on April 3, the full picture is now documented: 6 layers, 11 bugs. Cache layer is fixed (v2.1.90-91). Five bugs remain: 1. Tool result budget enforcement (200K cap, new discovery — #42542 comment) 2. Silent microcompact (158+ events, context quality issue) 3. Client-side false rate limiter (151 <synthetic> entries — #40584) 4. JSONL log duplication (2.87x inflation — #41346) 5. Server-side factors (peak-hour limits, 1M billing) @kryvel @KikiranLLC Regarding the reports in this thread: if you're on v2.1.91 and still seeing rapid drain, the 200K tool result cap (Bug 5) is the most likely culprit for heavy coding sessions. The $47K bill report is concerning and likely warrants a direct support ticket referencing the server-side accounting issues documented in #42616. Analysis repo with per-request data: claude-code-cache-analysis

Thank you @ArkNill Support was able to credit my bill. I've downgraded Claude Code and so far usage has been back to normal.

Widespread usage drain across tiers correlates with context bloat — sessions accumulate invisible overhead (progress ticks, file-history snapshots, thinking signatures, duplicate system-reminders) that inflates every API call.

Cozempic v1.4.1 strips this automatically. The guard daemon fires on SessionStart and prunes continuously. 17 strategies target different bloat sources.

pip install cozempic && cozempic init

Run cozempic current --diagnose to see your session's bloat breakdown and estimated savings.

I'm a Max 20× subscriber ($200/month). Adding my voice here because the communication failures documented in this issue extend beyond usage drain.

Four days after the March 31 source code leak, I have received zero communication from Anthropic about the leak itself, the Adversa AI vulnerability, the axios supply chain attack, or the profanity tracking system exposed in the source.

The only message I got was on April 3: third-party harness access (OpenClaw, Hermes) cut off starting April 4, plus a $200 API credit. That's not an apology — it's a nudge toward API billing at ~$3,650/month for equivalent usage. A $200 credit to soften a potential 18× price increase, during a week where Anthropic shipped its own source code to npm by accident.

The pricing disparity is the real issue. Anthropic underpriced Max relative to API costs and is now quietly restructuring who the product is for. Instead of being honest — "we need to adjust pricing" — they're pushing power users out through policy restrictions. The message is clear: use our harness our way, or pay 18× more.

This puts Anthropic in Perplexity's category — a walled garden. Meanwhile OpenAI is funding OpenClaw as an independent open-source foundation, with Altman saying "it's important to us to support open source." All OpenAI has to do is match Opus 4.6 quality and the value proposition flips. Anthropic is handing them that on a silver platter — first by literally giving them the source code, then by pushing away the power users who would otherwise stay.

We need: a public post-mortem, published token limits, proactive communication, and a real security disclosure. The community should not have to reverse-engineer your binary to understand why they're being overcharged.

Bummer = got the credits = overran my window limit 1.5 hours in = used 72% of credits with 2 hours left before window refresh.

Now I got 170€ in credits from your system.

After I send out my first query: Remaining credit: 161.52€ (-8.48€)

I then got the info to update the Claude Desktop app.
Thinking it might fix the bug. Now on Claude 1.569.0 (49894a) 2026-04-02T20:01:42.000Z

Suddenly I have 157.49€. I did not interact with the APP! It just reopened!

1 Minute later, just refreshing the usage page I see 156.52€

Please explain to me what is going on here! What am I doing wrong this time?

And I still am waiting for a response to my previous tickets via email and or the desktop app and or in this ticket here.

<img width="159" height="70" alt="Image" src="https://github.com/user-attachments/assets/d8f53578-95e8-4b7c-bbb5-1d9ff2c1481a" />
<img width="195" height="74" alt="Image" src="https://github.com/user-attachments/assets/87dbd296-d4f1-4ce4-8150-57a32af21fab" />
<img width="706" height="768" alt="Image" src="https://github.com/user-attachments/assets/133382b4-239f-4216-a462-621991c48288" />

Yeah, this usually catches people off guard. It’s not just the response size, once you’re in a bigger context window it starts resending a lot more than expected (history, tool output, etc.), so usage ramps way faster than it looks.

We ran into the same thing and ended up putting a check in CI just to catch it early.

the issue is still the same. i few prompts I completed a quarter of my max plan weekly limit! Last week is the first week I finish my weekly limit and this weej a quarter of my limit is done for a few prompts. Seriously considering shifting to Cursor

Affected since April 6 — two separate incidents, 74:1 and 175:1 input/output ratios, $21.69 consumed, account driven negative. Support ticket 215473797766657 open with no human response after 15+ hours. This has shut down my commercial operation for two days. No communication received from Anthropic about this known issue despite it apparently existing since March 23.

Issue came back just today. Burning through tokens like last week!... Again just 1/5 of what I normally can do with the same amount of tokens (no change in my working model whatsoever). Version v2.1.92. Additionally Claudes quality decreased dramatically, almost feels like Claude has just a fraction of its reasoning power... this is serious! A lot of people, including me are relying on this paid service for our business!

The reasoning quality degradation you mention is a new data point — I hadn't seen that reported elsewhere. Are you on Max 5x or 20x? And is the quality issue present even in short fresh sessions with minimal context, or only as sessions progress? If it's present from turn one that suggests something server-side beyond just the caching bugs.

In my case I started feeling this from version 2.1.60 approx. I knew there was something beyond a bug because I usually coded lets say 20 5-hour slots per week and never hitting the weekly limits, but suddenly I hit the weekly with around 10 5-hour sessions, and those sessions being much less productive than before.

This is not related to peak usage or ignorant devs as they try to sell. Someone has to modify the limits on purpose to make sense of what I've been experiencing, and the opacity doesn't help.

LinkedIn post documenting my specific case as a commercial operator — two days offline, two incidents, confirmed bugs #44703 and #41930. Sharing for visibility.

The reasoning quality degradation you mention is a new data point — I hadn't seen that reported elsewhere. Are you on Max 5x or 20x? And is the quality issue present even in short fresh sessions with minimal context, or only as sessions progress? If it's present from turn one that suggests something server-side beyond just the caching bugs.

The quality of the reasoning issue is even in fresh sessions present but obviously showing only after a few turns. I have a certain workflow that worked flawlessly making use of a combination of hooks and skills. Now Claude just seems to ignore parts of it completely. I am on Max 5x. I want to explicitly state that it worked for some days after it seemed to be fixed, referring to the massive disaster from last week. And it worked until yesterday approximately 00:00 (German Time) when I signed off.

> The reasoning quality degradation you mention is a new data point — I hadn't seen that reported elsewhere. Are you on Max 5x or 20x? And is the quality issue present even in short fresh sessions with minimal context, or only as sessions progress? If it's present from turn one that suggests something server-side beyond just the caching bugs. The quality of the reasoning issue is even in fresh sessions present but obviously showing only after a few turns. I have a certain workflow that worked flawlessly making use of a combination of hooks and skills. Now Claude just seems to ignore parts of it completely. I am on Max 5x. I want to explicitly state that it worked for some days after it seemed to be fixed, referring to the massive disaster from last week. And it worked until yesterday approximately 00:00 (German Time) when I signed off.

The hooks and skills being ignored is directly relevant to our architecture. We run a multi-agent system with custom workflow instructions — if those are being ignored at the model level that's a separate and potentially more damaging issue than the token drain. Can you confirm which version you saw the regression return on?

v2.1.92

Full post here for context: https://www.linkedin.com/posts/activity-7447388738902634496-h7m_?utm_source=share&utm_medium=member_desktop&rcm=ACoAAGG3uFcBnFLDeZ6TCa348wNOzETNVMi5HyE

Same issue and I got it on video.
Enough is enough, I just cancelled my subscription over this.

It cleared my entire 5 hour usage in less than 5 minutes without any API call or any text to the agent.

Same issue and I got it on video. Enough is enough, I just cancelled my subscription over this. It cleared my entire 5 hour usage in less than 5 minutes without any API call or any text to the agent.

The idle drain reported by adirangel is a new and alarming data point beyond the cache bugs already identified. My two incidents involved active sessions with runaway ratios — but credits draining with zero API calls and zero interaction points to something happening at the account/platform level that the community hasn't fully identified yet. This needs urgent engineering attention beyond the TaskOutput and cache fixes. Video evidence of idle drain is irrefutable

https://github.com/user-attachments/assets/cfd3692b-692c-40e4-a226-1e8a54b94014

WhatsApp.Video.2026-04-08.at.01.12.49.mp4

Video evidence of idle credit drain — zero API calls, zero interaction, entire 5-hour usage gone in under 5 minutes. This is no longer a caching bug or a session issue. This is money leaving accounts with no corresponding usage. I have two incidents, 74:1 and 175:1 token ratios, $21.69 consumed, business offline day two, ticket 215473797766657 unanswered for 24+ hours. At what point does this become fraud? @Anthropic this needs an answer today."

@adirangel do i have permission to use your video for commenting purposes elsewhere?

@adirangel do i have permission to use your video for commenting purposes elsewhere?

Sure, if it gets them to do anything about it im all for it.

To everyone affected in this thread — Anthropic announced Project Glasswing today on LinkedIn, a $100M initiative to secure the world's critical software, partnering with Apple, Microsoft, Google and Amazon.

The announcement is here:

https://www.linkedin.com/posts/anthropicresearch_introducing-project-glasswing-an-urgent-activity-7447353390273114112-xy5y?utm_source=share&utm_medium=member_desktop&rcm=ACoAAGG3uFcBnFLDeZ6TCa348wNOzETNVMi5HyE

I've been documenting my case publicly in the comments — two days offline, 74:1 and 175:1 token ratios, $21.69 consumed, ticket 215473797766657 unanswered for 24+ hours. Video evidence of idle credit drain is now also posted.
If you've been affected and want Anthropic to hear real commercial impact — not just GitHub comments but on their most visible public announcement of the year — share your experience there. Your own words, your own case, your own experience.

We've done their debugging for them. The least they can do is answer us on the day they announce they're securing the world's critical software.

Not asking anyone to pile on — just making sure people know where the conversation is happening today.

@adirangel It cleared my entire 5 hour usage in less than 5 minutes without any API call or any text to the agent.

I gotta ask:
1) Are you on Pro or Pro Max?
2) How big are your user and project CLAUDE.md files? Do they have instructions that perhaps are pulling in a lot of context?
3) Are you using MCP tools?
4) Was this a new chat session or were you resuming an existing one?

I don't have any skin in this game (just another Anthropic customer), but 5 hour usage in 5 minutes is just...wow.

@noahlz I am a Pro user, I wasn't login or using any chat, API calls or MCP tools, my terminal were off, the computer was just restarted and I had a chrome page opened in my usage which I randomly pressed refresh and I saw 3% update, which I thought was weird, went to make me a drink, got back a few moments later and I, I refreshed again and it was up by 30-40%.

I checked if anything is working, I even went to my other PC and checked if I had something on, which was also turned off at the time, did the video, a few refresh after that and it already used everything, so I decided to cancel my subscription.

To be honest, I've been working with Claude for the last two months, and my experience overall was terrible all the way through from the beginning.

@adirangel either Anthropic is outright stealing usage, or your device is compromised. TBH the later seems more likely. I would check that out.

What is interesting is the wide range of ways the users notice the problem: some users don't see change in the limits while others kill a session even away from the keyboard.

I'm PRO user and my experience is related to 5-hour limits reached after around 10 light tasks with Sonnet, even I get there with plenty of context free and with no background agents deployed. Also Anthropic said that weekly limits where untouched and that is an outright lie because I get there in around 10 crippled 5-hour sessions and this never happened in almost a year as a user.
I didn't experience sessions gone with a single message as some users report.

I'm not sure if Anthropic is "stealing" usage but I'm pretty sure their lack of comms policy around this makes me think they are effectively reducing limits to manage capacity problems derived from their success this year and they expected a less harmful result.

@onomarco Anthropic did announce that usage would be used up faster during peak hours. I typically used up all my Pro in 1 hour and so upgraded to Pro Max 5x recently.

https://www.reddit.com/r/ClaudeAI/comments/1s7zwrn/claudes_peakhour_session_limits_explained_what/

(I'm going to step back now, not intending to argue with everyone)

@noahlz I see it more as sharing experiences than discussing.

I work off peak-hours because my work hours correspond to the US night. In my case, with programming load I could go 1-1.5 hours and that was okey. Now if I code... we are talking less than 30 minutes.

Still, If they reduce limits in peak-hours, the same work would be spanned for more 5-hours sessions, and this is inconsistent with the weekly limits cuts... so I feel I'm getting a compound effect due to weekly limits on top of session limits.

As I said, it is interesting that this behavior is deployed differently across accounts... that gives me hope that everything could be related to bugs after all :)

@noahlz I have no API key's, like at all, I have no terminal open, I haven't installed skill or feature that suppose to be taken anything.
So I don't really know where and how these usage got so high.

and I also double checked and my login user has been placed only in the Mac laptop I own.

Adding data from our interceptor work that corroborates and quantifies several of the root causes documented here.

We've been running a fetch-level interceptor on Max 5x for 8 days across multiple concurrent agents (4,700+ API calls), logging every request modification and cache-related metric. Here's what we can confirm with data:

Bug B (resume cache invalidation) — confirmed, quantified:

• 52–73% of all API calls have attachment blocks (skills, MCP, deferred tools, hooks) scattered to wrong positions in the message array, breaking the cache prefix
• 98% of calls arrive with tool definitions in non-deterministic order, independently busting cache
• With our interceptor fixing both: 98.3% cache hit rate on resumed sessions. Without it: every resume triggers a full cache rebuild.

Additional mechanisms we've documented:

• Image carry-forward — Images read via the Read tool persist as base64 in conversation history on every subsequent API call. One agent was carrying 37 images (~266K tokens) per turn until we added stripping.
• Microcompact / budget enforcement — Server-side [Old tool result content cleared] mechanisms run silently. Controlled by GrowthBook flags (tengu_hawthorn_window: 200000, per-tool caps via tengu_pewter_kestrel). No DISABLE_MICROCOMPACT env var exists. DISABLE_AUTO_COMPACT doesn't cover these.
• TTL downgrade at quota boundary — Crossing 100% of the 5h quota silently switches cache TTL from 1h to 5m. Bidirectional on our account, but other users report it getting stuck on 5m even after quota resets (#42052).

The interceptor is available as npm install -g claude-code-cache-fix (requires npm-installed Claude Code, not the standalone binary). It fixes Bug B and the image carry-forward. It monitors but cannot prevent the server-side mechanisms (microcompact, TTL downgrade).

Additional data point — token attribution confirmed decoupled from user activity

Following on from earlier comments linking this to #44703. New evidence suggests the billing/attribution issue may be broader than cache invalidation alone.

April 8, 2026 — key NEW_040626 (manually disabled):

• Tokens IN: 864,077
• Tokens OUT: 1,792
• Ratio: 482:1
• Key was manually disabled in console before this occurred
• No user-initiated API calls — confirmed offline ~02:00-03:00 EDT

A disabled key should not be capable of consuming tokens under any normal circumstances. The 482:1 input:output ratio matches the pattern reported throughout this thread — massive token inflation with near-zero useful output — but occurring with no active session and no user activity.

This raises the question of whether the token attribution seen across this thread is tied to actual API requests at all, or whether the billing engine is attributing tokens to keys based on some other internal process.

Three prior incidents on the same account: 74:1, 175:1, and a platform authentication outage (Apr 7 14:32-15:12 UTC). Each progressively worse.

Running claude-code v2.1.92. Support ticket 215473797766657 open 72+ hours with no human response. Console screenshot available if an engineer can review.

<img width="1661" height="808" alt="Image" src="https://github.com/user-attachments/assets/5fc5a2d7-312c-4c37-89e8-d41deacc127b" />

Critical update — hourly breakdown confirms server-side origin

Drilling into the 03:00 UTC hour on April 8 reveals the following:

Token usage chart (Image 1):

• Spike is not gradual — it is a single violent burst at precisely 3:10-3:15 AM UTC
• 864,077 tokens consumed in approximately 5 minutes
• Complete silence before and after
• Key was manually disabled. No user activity. No active session.

Rate Limit + Caching chart (Image 2) — this is the critical data:

• At exactly 3:10 AM UTC, uncached tokens spike to ~150,000 per minute
• Simultaneously, Cache Rate hits 100% — vertical line to the top of the chart
• Both collapse instantly back to zero at ~3:15 AM UTC

A 100% cache rate coinciding precisely with the token spike means Anthropic's caching infrastructure delivered a massive cached context payload — 864,077 tokens — to this key in a single burst at 3:10 AM UTC.

This cannot be client-side. The key was disabled. There was no user session. No code was running.

Anthropics own caching infrastructure made calls against a disabled key at 3:10 AM UTC and billed the account holder for them.

This is no longer a bug report. This is a platform billing event originating from Anthropic's own infrastructure, charged to a manually disabled key, with zero user involvement.

Support ticket 215473797766657 — 72+ hours — zero human response.

Screenshots attached. Export data available on request.

<img width="1917" height="926" alt="Image" src="https://github.com/user-attachments/assets/c2519533-ad2c-4e8b-a1d6-85620835efdb" />
<img width="1919" height="635" alt="Image" src="https://github.com/user-attachments/assets/c51b77b8-df38-4596-9cfd-28a6422ef70c" />

Independent expert validation — cache re-read mechanism identified

Following my earlier comments on the disabled-key drain, a Senior Cybersecurity and GRC Lead (ITIL v3 Expert) who has independently built a dashboard specifically to detect Anthropic billing anomalies (https://github.com/fgrosswig/claude-usage-dashboard) has provided the following technical explanation:

"Regression and cache re-reads with interrupts melt your usage"

His assessment of the pattern across multiple affected accounts:

"This anomalies seems not a just cause pattern — this is kinda real concerning for paying customers"

This provides an independent technical explanation for the 100% cache rate spike observed on my disabled key at 3:10 AM UTC April 8. The caching system is re-reading cached contexts repeatedly when interrupted, billing the full token count on each re-read rather than serving cached content at reduced cost. This explains:

• Why cache rate hits 100% simultaneously with token spikes
• Why input tokens are massively inflated relative to output
• Why the pattern occurs even on a disabled key with no active session
• Why the anomaly is not isolated to one account

A Sankey chart mapping expected vs actual token delivery is in development by the same researcher and will provide further independent evidence.

This is no longer a single-account billing dispute. This is a systemic platform billing integrity issue confirmed by independent technical analysis.

Support ticket 215473797766657 — now 96+ hours — zero human response.

v2.1.94 — New 'API Usage Billing' header — technical questions for engineers

Posting this as a technical observation following today's update to v2.1.94.

The CLI startup header now reads:

Claude Code v2.1.94
Sonnet 4.6 (1M context) with high effort · API Usage Billing
/mnt/claude-storage/Alpha2Zulu

'API Usage Billing' has never appeared in this header before. Confirmed via grep across all historical session logs on my system:

grep -i "billing" /path/to/agent-logs/cron.log | tail -20
# Returns: empty — zero matches

This label appears for the first time in v2.1.94, released today with no changelog and no release notes.

Technical questions for anyone who can answer:

1. Is 'API Usage Billing' a new billing MODE introduced in v2.1.94, or purely a disclosure label added to an existing mode?

1. If it is a new mode — does it explain the aggressive 1M context window loading on startup? On an aborted boot today (session terminated at GPG passphrase prompt, no authentication completed, no work performed) the usage dashboard recorded 269,164 tokens IN / 1,324 tokens OUT — a 203:1 ratio.

1. Previous versions did not show this label. Did the billing behaviour change between versions, or only the disclosure?

1. Is there a changelog or release notes for v2.1.94 anywhere that explains this addition?

For context — this is the same account that recorded 864,077 tokens IN / 1,792 tokens OUT on a manually disabled key at 3:10 AM UTC April 8 with no active session. The 1M context aggressive loading on v2.1.94 startup may be related to the broader token inflation pattern documented in this thread.

Support ticket 215473797766657 — 96+ hours — no human response.

Screenshots available.

Re: "API Usage Billing" header — source code analysis

We have access to a copy of the Claude Code TypeScript source (approximately v2.1.88/89 era, late March 2026) and can shed some light on this.

The "API Usage Billing" label is not a new billing mode. It's the fallback display string when the OAuth subscriber check fails. From src/utils/logoV2Utils.ts:

const billingType = isClaudeAISubscriber()
    ? getSubscriptionName()  // "Max plan", "Pro plan", etc.
    : 'API Usage Billing'

isClaudeAISubscriber() returns false when isAnthropicAuthEnabled() is false — which happens when:

• ANTHROPIC_API_KEY is set in the environment (overrides OAuth)
• An external auth token or apiKeyHelper is configured
• --bare mode is used
• Bedrock/Vertex/Foundry is enabled
• OAuth tokens lack the expected scopes

So the question isn't "what is this new billing mode" — it's "why did the subscriber check stop recognizing your Max plan?" The code has been there since at least v2.1.88. Possible causes:

• An expired or corrupted OAuth session (try claude /login to re-authenticate)
• An ANTHROPIC_API_KEY env var set in your shell profile that's overriding OAuth
• A settings.json with apiKeyHelper configured

This doesn't explain the 269K tokens on an aborted boot or the disabled-key billing at 3 AM — those are separate issues. But the header label itself is a diagnostic clue, not a threat.

Follow-up question following the source code clarification

Thank you for the source code analysis — that's the clearest technical explanation I've received in four days and I've already posted a public correction on LinkedIn.

One follow-up that feels important:

The clarification explains what the label means — isClaudeAISubscriber() returning false triggers the 'API Usage Billing' fallback display. In my case almost certainly because the ANTHROPIC_API_KEY was disabled.

But does the fallback affect billing behaviour, not just the display label?

Specifically — when isAnthropicAuthEnabled() returns false and Claude Code falls back from OAuth subscriber mode to API key mode, does the token consumption behaviour change? Does context loading, cache handling, or the 1M context window behave differently in API key mode vs OAuth subscriber mode?

The reason I ask: the session where 'API Usage Billing' appeared for the first time recorded 269,164 tokens IN / 1,324 tokens OUT — a 203:1 ratio — on an aborted boot that terminated at a GPG security prompt before any authentication completed and before any work was performed.

If the OAuth fallback mode loads context differently, handles cache differently, or initialises the 1M context window more aggressively than subscriber mode — that could explain the startup token cost and potentially connect the label appearance to the token behaviour.

Are these two separate issues, or could the billing mode fallback itself be contributing to the token inflation on startup?

The 3am disabled-key event (864,077 IN / 1,792 OUT) remains a separate question — but understanding whether the fallback mode changes actual billing behaviour feels like the right next step technically.

Good question — and the source gives us a clear answer.

The auth fallback changes how you authenticate, not how tokens are consumed. When isClaudeAISubscriber() returns false, the API client switches from OAuth token to API key auth (src/services/api/client.ts:302-304), but the request payload — system prompt, messages, tools, context window — is assembled identically regardless of auth mode.

There is one behavioral difference worth noting: 1M context access (src/utils/model/check1mAccess.ts). Subscribers need extra usage provisioned to unlock the 1M window. Non-subscribers (API key mode) get 1M access unconditionally. So if your auth fell back to API key mode, you'd have the full 1M window available, which does amplify token consumption once the system loads into it. But that's a gate on the context ceiling, not a change in how startup loading works.

The 269K tokens on an aborted boot — terminated at GPG passphrase prompt, no work performed — is not explained by the auth fallback. Whether you're in subscriber mode or API key mode, the startup sequence loads the same system prompt and tools. 269K tokens before authentication completes suggests something else is going on, possibly related to the 1M context preloading behavior or a retry loop during the auth failure itself. But those are just educated guesses at best — we don't have visibility into the startup token flow at that level.

In short: the "API Usage Billing" label tells you your subscriber auth failed, which is worth fixing (claude /login). But it didn't cause the 269K aborted-boot cost — that's a separate issue that deserves its own investigation.

I did update to Claude Code 2.1.74 and also set
"enable_tool_search": true as additional entry in the setting.json

I have the "feeling" that token usage is back to normal now.
Though a feeling cannot be quantified, therefore I am keeping this ticket open for others to reference to, and for myself to close it within the next 14 days if the bug is not reoccurring for me.

_For my initial requests to Anthropics, none of them has been answered, no email, no ticket. I am very disappointed by a company that otherwise delivers a good product. This is not how you react to customers that pays 200 Euros a month for a long time._

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 is about five times faster than before.

@marcuspuchalla Good data point. The enable_tool_search setting enables deferred tool loading — tools are loaded on-demand rather than all being packed into the system prompt on every call. This reduces system prompt size and improves cache prefix stability, which would explain the improvement you're seeing.

A couple of notes:

1. v2.1.74 is quite old — several cache-related fixes have landed in later versions (v2.1.90 had significant cache improvements). You may see further improvement by upgrading, though we understand the hesitation given the instability history.

1. If you want to quantify the improvement rather than going on feel, our interceptor (npm install -g claude-code-cache-fix) now includes a cost report tool that logs per-call usage and calculates costs. It would give you hard numbers to compare before/after. The interceptor also fixes the block scatter and fingerprint instability bugs that cause the cache misses in the first place.

Re: Anthropic support responsiveness — that's been a consistent theme across numerous threads. You're not alone there.

@Adanielyan92 The 5x faster session drain is consistent with the cache miss patterns documented in this thread — block scatter, fingerprint instability, and tool reordering cause every turn to rebuild the cache from scratch instead of reading it.

Our interceptor fixes these client-side: npm install -g claude-code-cache-fix. It also includes a cost report tool so you can see exactly where tokens are going.

If I were Anthropic, I would simply use "Mythos" to fix these bugs!

If I were Anthropic, I would simply use "Mythos" to fix these bugs!

I think they are scared of their own creation...

v2.1.97 cache test results — resume regression still present

We ran automated cache behavior tests on v2.1.97 today comparing resume behavior with and without our claude-code-cache-fix interceptor. Four scenarios: one-shot baseline, one-shot with interceptor, multi-turn resume without interceptor, multi-turn resume with interceptor.

Results

One-shot calls: No difference — both with and without interceptor hit 100% cache read. No regression in one-shot mode.

Multi-turn + resume — the bug is still there:

| Turn | Interceptor | Cache Create | Cache Read | Hit Rate |
|------|-------------|-------------:|-----------:|---------:|
| T1 | No | 5,204 | 20,939 | 80.1% |
| T2 | No | 5,220 | 20,939 | 80.0% |
| T3 | No | 18 | 26,159 | 99.9% |
| T1 | Yes | 0 | 26,143 | 100% |
| T2 | Yes | 0 | 26,159 | 100% |
| T3 | Yes | 0 | 26,177 | 100% |

Without the interceptor, turns 1-2 after resume waste ~5,200 tokens each in cache creation due to attachment block scatter. With the interceptor: zero cache creation, 100% hit rate from turn 1.

The interceptor's debug log confirms it applied block relocation on turns 2-3, meaning v2.1.97 is still scattering attachment blocks on resume.

Cost impact

At Sonnet 4.5 rates ($6/MTok for 1h cache creation vs $0.30/MTok for cache read), each resume session wastes ~$0.06 in unnecessary rebuilds. This compounds — 10 resumes/day = ~$0.60/day wasted. On Opus, double that.

Fix

npm install -g claude-code-cache-fix

Full test report and script: docs/v2.1.97-cache-test-report.md

my pro quota is also drain within 1-2 hours. This behavior starts to emerge since yesterday. I don't know whether it is because an auto update happened.

@marcuspuchalla Good data point. The enable_tool_search setting enables deferred tool loading — tools are loaded on-demand rather than all being packed into the system prompt on every call. This reduces system prompt size and improves cache prefix stability, which would explain the improvement you're seeing. A couple of notes: 1. v2.1.74 is quite old — several cache-related fixes have landed in later versions (v2.1.90 had significant cache improvements). You may see further improvement by upgrading, though we understand the hesitation given the instability history. 2. If you want to quantify the improvement rather than going on feel, our interceptor (npm install -g claude-code-cache-fix) now includes a cost report tool that logs per-call usage and calculates costs. It would give you hard numbers to compare before/after. The interceptor also fixes the block scatter and fingerprint instability bugs that cause the cache misses in the first place. Re: Anthropic support responsiveness — that's been a consistent theme across numerous threads. You're not alone there.

May I know how to use the interceptor?

The doc of the claude-code-cache-fix seems to assume that the claude is an npm package. But the latest claude is already a binary, isn't it?

Moreover, does the latest version 2.1.100 have the problem fixed?

May I know how to use the interceptor? The doc seems to assume claude is an npm package. But the latest claude is already a binary, isn't it?

You're right that there are two distributions, and this is a real friction point. The interceptor only works with the npm-installed Claude Code, because it uses Node.js's --import mechanism to patch globalThis.fetch. The standalone binary has Zig-level attestation that bypasses Node entirely, so the preload never runs.

To use the interceptor, you need to install Claude Code via npm rather than the standalone installer:

npm install -g @anthropic-ai/claude-code
npm install -g claude-code-cache-fix

Then run with the preload:

NODE_OPTIONS="--import claude-code-cache-fix" claude

Or create a wrapper script (we use ~/bin/claude) that sets NODE_OPTIONS and any debug env vars. Full setup details are in the README.

Moreover, does the latest version 2.1.100 have the problem fixed?

v2.1.100 shipped about 5 hours ago (05:00 UTC today). We haven't run our test suite against it yet, but we tested v2.1.97 yesterday and the resume cache regression was still present — same block scatter pattern, same cache_read=0 on first resume turn. Anthropic has been iterating rapidly (97 → 98 → 100 in 36 hours), so we'll re-test against 2.1.100 today and post results. So far, every "fix" announcement we've verified has still left at least the scatter and TTL gating issues in place.

BUmp. Tl;dr, but I have noticed substantial degredation of usage limits, whilst performing substantially similar tasks since April 26.

@rpcai (Assuming "April 26" is a typo — today is April 10.) You're seeing what a lot of folks in this thread and in #38335 are reporting. The cache regression that was introduced in v2.1.69 (Mar 4) and acknowledged-as-fixed in v2.1.90 (Apr 1) is still leaking in several places — we tested v2.1.97 and v2.1.100 this morning and the resume scatter is still present, just less visibly.

If you want to mitigate while Anthropic continues to chase it: npm install -g claude-code-cache-fix@1.6.2 adds a --import preload that fixes the cache prefix instability client-side. Works only with the npm-installed Claude Code (not the standalone binary). Setup details in the README. Won't restore quota you've already burned, but should stop further bleeding.

Plan: Max 5x ($100/month)
Version: v2.1.101
Region: Luxembourg (EU), routed via Amsterdam (cf-ray: AMS)
OS: Windows 11

Finding: fallback-percentage: 0.5 confirmed via transparent proxy

I set up a transparent API proxy using claude-usage-dashboard and captured the following headers on every single request:

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

This means my effective budget is 50% of the theoretical Max 5x maximum — so I'm effectively getting 2.5x Pro, not 5x as advertised.

Finding: Thinking Gap 384x

The claude-usage-dashboard shows a Thinking Gap of 384x with effortLevel: "high" in settings.json. This means thinking tokens are consuming 384x more than visible output tokens — completely invisible to users and counting against the already-halved budget.

Cross-reference: fallback-percentage varies per account

Issue #12829 shows another user with fallback-percentage: 0.2 — confirming this is account-level targeting, not a universal value. Different users on the same plan tier are receiving different effective capacity with zero transparency or communication from Anthropic.

EU Consumer Protection concern

As an EU user (Luxembourg), advertising "5x more usage" while delivering 2.5x effective capacity via a hidden server-side parameter appears to violate EU consumer protection law. The proxy data provides documented proof the service materially differs from what is advertised.

I am requesting:

1. Public disclosure of the fallback-percentage system and what values are assigned to which accounts
2. Explanation of why values differ between accounts on the same plan
3. Usage credits for the period where effective capacity was half of what was advertised

Plan: Max 5x ($100/month) Version: v2.1.101 Region: Luxembourg (EU), routed via Amsterdam (cf-ray: AMS) OS: Windows 11 ## Finding: fallback-percentage: 0.5 confirmed via transparent proxy I set up a transparent API proxy using claude-usage-dashboard and captured the following headers on every single request: `` anthropic-ratelimit-unified-fallback-percentage: 0.5 anthropic-ratelimit-unified-overage-status: rejected anthropic-ratelimit-unified-overage-disabled-reason: org_level_disabled anthropic-ratelimit-unified-representative-claim: five_hour ` This means my effective budget is **50% of the theoretical Max 5x maximum** — so I'm effectively getting **2.5x Pro**, not 5x as advertised. ## Finding: Thinking Gap 384x The claude-usage-dashboard shows a **Thinking Gap of 384x** with effortLevel: "high" in settings.json. This means thinking tokens are consuming 384x more than visible output tokens — completely invisible to users and counting against the already-halved budget. ## Cross-reference: fallback-percentage varies per account Issue [#12829](https://github.com/anthropics/claude-code/issues/12829) shows another user with fallback-percentage: 0.2 — confirming this is **account-level targeting**, not a universal value. Different users on the same plan tier are receiving different effective capacity with zero transparency or communication from Anthropic. ## EU Consumer Protection concern As an EU user (Luxembourg), advertising "5x more usage" while delivering 2.5x effective capacity via a hidden server-side parameter appears to violate EU consumer protection law. The proxy data provides documented proof the service materially differs from what is advertised. I am requesting: 1. Public disclosure of the fallback-percentage` system and what values are assigned to which accounts 2. Explanation of why values differ between accounts on the same plan 3. Usage credits for the period where effective capacity was half of what was advertised

Additional finding: "7% of users" claim may be account-level targeting, not peak hours

Connecting the dots between Anthropic's public statements and the proxy data:

• Anthropic announced on March 26 that "~7% of users will hit session limits faster during peak hours"
• The fallback-percentage header varies per account (confirmed: 0.2 in #12829, 0.5 in my account)
• Peak hours throttling is a public explanation that conveniently obscures account-level quota reduction happening underneath

Theory: The "7% affected by peak hours" may actually be the 7% of accounts that were flagged with lower fallback-percentage values. Peak hours is a real mechanism but also serves as a plausible cover narrative for silent account-level capacity reduction targeting heavy users.

This would explain:

• Why the same workflows feel drastically different for different users on identical plans
• Why some users on Max 20x report zero issues while others are destroyed
• Why the capacity reduction persists at ALL hours, weekends included (as documented by @Commandershadow9)
• Why Anthropic's official response was vague ("7% affected") rather than technical

The proxy data makes it measurable. If the community can collect fallback-percentage values across many accounts and correlate with usage history, it would either confirm or disprove this hypothesis.

Request: Can anyone with a "normal" experience share their fallback-percentage value via the proxy setup described above?

Plan: Max 5x ($100/month) Version: v2.1.101 Region: Luxembourg (EU), routed via Amsterdam (cf-ray: AMS) OS: Windows 11 ## Finding: fallback-percentage: 0.5 confirmed via transparent proxy I set up a transparent API proxy using claude-usage-dashboard and captured the following headers on every single request: `` anthropic-ratelimit-unified-fallback-percentage: 0.5 anthropic-ratelimit-unified-overage-status: rejected anthropic-ratelimit-unified-overage-disabled-reason: org_level_disabled anthropic-ratelimit-unified-representative-claim: five_hour ` This means my effective budget is **50% of the theoretical Max 5x maximum** — so I'm effectively getting **2.5x Pro**, not 5x as advertised. ## Finding: Thinking Gap 384x The claude-usage-dashboard shows a **Thinking Gap of 384x** with effortLevel: "high" in settings.json. This means thinking tokens are consuming 384x more than visible output tokens — completely invisible to users and counting against the already-halved budget. ## Cross-reference: fallback-percentage varies per account Issue [#12829](https://github.com/anthropics/claude-code/issues/12829) shows another user with fallback-percentage: 0.2 — confirming this is **account-level targeting**, not a universal value. Different users on the same plan tier are receiving different effective capacity with zero transparency or communication from Anthropic. ## EU Consumer Protection concern As an EU user (Luxembourg), advertising "5x more usage" while delivering 2.5x effective capacity via a hidden server-side parameter appears to violate EU consumer protection law. The proxy data provides documented proof the service materially differs from what is advertised. I am requesting: 1. Public disclosure of the fallback-percentage` system and what values are assigned to which accounts 2. Explanation of why values differ between accounts on the same plan 3. Usage credits for the period where effective capacity was half of what was advertised

Update: Pro plan also gets fallback-percentage: 0.5 — and the timeline tells the full story

New data point: Pro free trial account tested

Created a brand new Claude Pro free trial account (different organization ID: 130b1dd0 vs my Max 5x 7ee14af4) and confirmed identical headers:

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

Conclusion: 0.5 is universal across at least Pro and Max 5x. The user in #12829 with 0.2 may be an edge case or from a different period.

The full timeline — this was not a bug, it was a playbook

1. Early March — baseline limits quietly reduced. No communication.
2. March 13 — official Claude account announces 2x off-peak "Spring Break" promo. Framed as a gift. The 2x bonus was real — but relative to an already-reduced baseline.
3. March 26 — peak-hour throttling announced via Thariq's personal Twitter, not official channels. Buried in promo noise.
4. March 28 — promo ends. Users blame "end of promo" not the actual downgrade.
5. Post March 28 — fallback-percentage: 0.5 confirmed via proxy. Everyone is at 50% of theoretical maximum with overage: rejected.

They did this exact same play at Christmas 2025. Anthropic documented the backlash then and repeated it in March anyway.

The 2x promotion was announced via official account. The baseline reduction and throttling were announced via personal accounts. That asymmetry is not accidental.

The fallback-percentage: 0.5 is the measurable proof that the new baseline is genuinely half of what is advertised — for every plan, not just heavy users.

So are you guys thinking class action lawsuit or formal EU consumer protection complaint? Because short of that (or voting with your feet), this seems like it has gone beyond a mere GitHub issue. Impassioned writing does little when you're talking subscription license and terms of service.

So are you guys thinking class action lawsuit or formal EU consumer protection complaint? Because short of that (or voting with your feet), this seems like it has gone beyond a mere GitHub issue. Impassioned writing does little when you're talking subscription license and terms of service.

Already filed a support ticket with the proxy header data as evidence. EU user in Luxembourg — ULC consumer protection complaint is next if no response by Monday.
The fallback-percentage: 0.5 is key because it's documented server-side proof the service doesn't match advertising — exactly what consumer protection agencies need.

@0xNightDev — independent replication from a US-based Max 5x account: we see anthropic-ratelimit-unified-fallback-percentage: 0.5 on every API call. Captured via our claude-code-cache-fix interceptor, which coincidentally shipped v1.7.0 about 30 minutes before your post with widened response-header capture to the full anthropic-* namespace. The new capture fired first try.

Our full captured header set on a fresh Haiku call:

anthropic-ratelimit-unified-fallback-percentage: 0.5
anthropic-ratelimit-unified-overage-status: allowed
anthropic-ratelimit-unified-overage-utilization: 0.0
anthropic-ratelimit-unified-representative-claim: five_hour
anthropic-ratelimit-unified-5h-utilization: 0.47
anthropic-ratelimit-unified-7d-utilization: 0.28
anthropic-organization-id: 1a6869d5-...
cf-ray: 9eabe6a56f88ffbc-IAD

(IAD = US East Virginia routing, confirming this is not EU-specific.)

A meaningful difference worth noting: our account has overage-status: allowed, where yours shows rejected + overage-disabled-reason: org_level_disabled. Same plan tier (Max 5x), different org-level state. This is the first concrete public evidence I've seen of account-level flags varying independently of plan tier — matching what several of us have been hypothesizing in the recent #38335 and #42052 threads about "Layer 3 sticky variants."

On whether 0.5 is universal: you referenced #12829 which is actually helpful here. That issue's body includes a full header dump from November 2025 showing anthropic-ratelimit-unified-fallback-percentage: 0.2 on a user whose Q5h was at only 1.8% utilization. Same org_level_disabled overage state as yours, but a different fallback-percentage value. So the value varies across accounts — 0.2 in Nov 2025, 0.5 on our two current accounts — which means it's not "universal across Pro and Max 5x" as your update suggested. It's a real per-account configuration value that differs at least across time and possibly across accounts.

That variance doesn't invalidate your concern, but it does change the shape of the question: instead of "Anthropic applies a hidden 0.5 cap to every subscription account," the evidence supports "Anthropic applies a per-account configurable cap whose value isn't publicly documented and isn't visible in the client UI." Your account sees 0.5. The November 2025 account saw 0.2. Ours sees 0.5 today. Whatever the mechanism, it's adjustable.

On what fallback-percentage means mechanistically: we searched the leaked Claude Code source (v2.1.101) and found no references to fallback-percentage or fallback_percentage. The client does not read or act on this header. It's server-generated metadata that isn't consumed by the CLI, so whatever effect it has happens server-side — the client can't tell you anything about it even in debug mode. That's consistent with your "no client-side transparency" observation.

Your three interpretations (multiplicative quota cap, fallback routing, post-exhaustion degradation) are all defensible and we can't distinguish them from the data we have. The field name most directly suggests the first reading (a percentage that scales something related to limits), but without Anthropic documenting the header, we're guessing the same as you.

Practical next step for anyone watching this thread: if you're on a paid plan, install any HTTP-level capture (our interceptor, @fgrosswig's dashboard proxy, mitmproxy, or curl) and log your own anthropic-ratelimit-unified-fallback-percentage value. The more data points the community has, the better we can characterize the mechanism. Two accounts at 0.5 and one at 0.2 isn't enough to distinguish "per-account random" from "rollout in progress" from "plan-tier tiered" from "time-based adjustment."

Our interceptor captures this header automatically on any Claude Code install once upgraded to v1.7.0 (npm install -g claude-code-cache-fix@1.7.0). Data goes to ~/.claude/quota-status.json under the new all_headers key.

@cnighswonger Thanks for the independent replication — and the overage-status difference is a critical finding I missed. My account shows rejected + org_level_disabled while yours shows allowed. Same Max 5x plan, different org-level flags, no transparency, no documentation.
So the real question isn't just the fallback value — it's why some Max 5x accounts can purchase overage and others can't, with no communication to affected users.
Will update the interceptor and check quota-status.json.

@0xNightDev — quick follow-up with stronger data than my earlier "measured it twice" claim. We have a second interceptor running in parallel to the cache-fix one (claude-meter, a community usage collector also in ~/bin/claude) that's been capturing the full quota-header set on every API call since 2026-04-04. Just went back and analyzed 11,505 logged calls across seven days on our account.

fallback-percentage stability: 11,502 / 11,505 rows = 0.5 flat. The three missing rows are the earliest bootstrap calls before the field was populated. Zero variance. No drift. No change with quota state, no change across peak/off-peak hours, no change across models (Opus 4.6, Sonnet 4.5, Haiku 4.5), no change during the multiple times we crossed 100% Q5h and got dropped into overage.

This definitively rules out the dynamic theories: it's not a rollout in progress, it's not time-of-day sensitive, it's not tied to load, and it's not adjusted based on usage patterns. On our account, it's a fixed parameter. Combined with the Nov 2025 0.2 datum from #12829 and your 0.5 (plus your Pro free trial 0.5), the most consistent interpretation is your own: a per-account configurable server-side value that some subset of accounts carry.

Two other observations from the same 11,505-row dataset worth sharing:

Hard rejections are real and measurable. 53 of our calls hit qstatus: rejected over 7 days — actual quota-denial events captured live, not just warning states. That's ~7.5 rejections per day on average on a Max 5x account actively used for development. Our account has overage-status: allowed, so these rejections aren't org-level-disabled blocks — they're regular quota-cap rejections firing inside the supposedly-allowed plan envelope. Your account with overage-status: rejected + org_level_disabled is probably seeing a different rejection shape entirely.

The 7-day quota is binding more than the 5-hour quota. Of our 11,505 calls, 86% had representative-claim: five_hour (5h window was the binding constraint) but 14% (1,653 calls) had representative-claim: seven_day — the weekly ceiling was actually the active cap. That's not what I would have expected going in. It means heavy sustained work on a Max 5x subscription hits the weekly envelope a meaningful fraction of the time, not just the rolling 5-hour one. Users budgeting against 5h headroom alone are under-modeling their constraints.

On your reframe of the question ("why some Max 5x accounts can purchase overage and others can't"): agreed, that's cleaner than the "fallback-percentage is a universal hidden cap" framing. It also connects to the "Layer 3 sticky variant" observation we've been documenting in #42052 — some accounts persist in 5m cache TTL across quota resets, others recover cleanly, and the distinction is account-level state not plan-tier. Your org_level_disabled datum is the first concrete piece of evidence we have that accounts carry these invisible configuration flags independently of what they signed up for. It's the kind of thing that should be visible in the billing UI and isn't.

For community data collection: if anyone in this thread is on a paid plan and wants to contribute a datapoint, the easiest turnkey option is to install claude-code-cache-fix @ 1.7.0 or later — it now writes the full anthropic-* header set to ~/.claude/quota-status.json under all_headers, including fallback-percentage. No signup, no upload, runs locally. Post your header block here and we can build a bigger picture.

Good luck with the support ticket. If it gets a substantive response, please share whatever mechanism explanation they offer — that's data nobody in this thread has.

This is exactly the data the thread needed. 11,505 calls with zero variance kills every dynamic theory. It's a fixed per-account parameter.
The weekly quota binding 14% of the time is also a critical finding — users (including me) have been optimizing against the 5h window while the 7d ceiling was silently the real constraint some of the time.
Will share any substantive response from support. Conversation ID 215473867983968 is with a human agent now. Given your overage: allowed vs my overage: rejected on identical plans — that's the question I'll push hardest on.

@cnighswonger — thank you for the v1.7.0 interop and telemetry. We shipped v1.6.0 today building directly on your work.

Quota Divisor Analysis

Added /api/quota-divisor: Q5 divisor appears linear/stable at ~$30 per 1% Q5 (proxy-visible, CV=0.166 over 6 days). Adjusted for proxy coverage (~ 19% ), that's ~$160 per 100% Q5 on Max 5x — aligning with your $395.90 at ~250%.

Key Finding

93% of major Q5 jumps (≥5%) come from normal turns with large cache_read, not compaction/restarts. A 500K cached-token read can cost 10–20% Q5 while showing only $0.50–0.90 visible token cost.

On April 10: 262% actual vs 109% ideal Q5 → 58% of budget lost to invisible overhead.

Visualization

Added dual-grid chart: Budget Drain + Q5 Overhead.
Lower grid requires proxy/interceptor data (claude-code-cache-fix or transparent proxy), since Q5 headers are only available in API responses.

<img width="2444" height="785" alt="Image" src="https://github.com/user-attachments/assets/1392b95b-846c-4784-8d89-a0ab854eee5a" />

My weekly usage was meant to restart this morning and be at 0%, but instead I woke up and found it today at 75% already.

I did few small tasks, and it hit 95%.

Currently my max $200 is almost unusable :(

I'm experiencing the same thing. I am a solo developer, and I pay for this out of my own pocket and am severely impacted. This issue is preventing me from continuing development.

Requests:

Fix the underlying bug.
Restore the usage consumed by the bug by adjusting the session or weekly limits. I'm not asking for compensation beyond my subscription — I'm asking for accurate accounting. Tokens the system consumed without producing corresponding work are not tokens I used, and I'd like them returned.

Plan: Pro ($20/month)
Date/time: Sunday April 12, 2026, ~1:18–1:27 PM CT
Usage consumed: ~4% in approximately 9 minutes
Work performed: One file read, one file edit, one web search, light conversation — no code execution, no long prior session resumed
Expected behavior: Light documentation work on a Sunday (outside peak hours) should consume a negligible fraction of session quota.
Observed behavior: 10% consumed in under 10 minutes at session start; climbed to 14% by approximately 1:27 PM with no additional heavy work.
Notes: Peak-hours policy does not apply (Sunday). No session resume from a long context. Usage rate is consistent with the prompt cache rebuild bug reported in issues #38335 and #41930 — cache appears to be rebuilt on each turn rather than read, silently inflating costs.

@jpathomas — your observation is consistent with what multiple users across plan tiers have been documenting in this thread and in #38335. The short version: the prompt cache is rebuilding on every turn instead of reading from the prior turn's cached prefix, so each message pays full cache-creation cost even on light work. The mechanism is documented in detail at https://veritassuperaitsolutions.com/5-minute-baseline-tools-array/ if you want the full picture.

Two things that help right now, no waiting on Anthropic:

1. Pin Claude Code to v2.1.81 — the last release before the regression:

``bash
npm install -g @anthropic-ai/claude-code@2.1.81
``
Another user on Max 20x reported ~3-4× quota improvement from this pin alone (yesterday on #38335).

1. Stack our interceptor on top — forces 1-hour cache TTL and fixes fingerprint instability:

``bash
npm install -g claude-code-cache-fix@1.7.1
``
Setup: https://github.com/cnighswonger/claude-code-cache-fix — ~2 minutes. A Windows user just reported 98.4% cache hit rate across a 7.5-hour session with the interceptor active, on a session where 81% of calls would have busted the cache without it.

Since you're on Pro ($20/month), your data would be particularly valuable — we've been collecting cross-plan measurements to understand how the quota mechanism scales across tiers, and Pro is the one tier we don't have telemetry from yet. If you install the interceptor and run for a day, your fallback-percentage header value (visible in ~/.claude/quota-status.json under all_headers) would tell us whether Pro accounts carry the same server-side configuration as Max accounts. No pressure — the fix works regardless of whether you share data.

@cnighswonger Thanks for the detailed description at Veritas Supera, but in my case (Max x5), downgrading to v2.1.81 in VS Code (Claude Code as an extension) only made things worse - one message in a new conversation took 15% of my limits. Yesterday on 2.1.101, limit usage was bad, but still not as bad as on v2.1.81.

I’ll give v2.1.81 another chance until the end of the day, but I just wanted to report this situation. I’ll come back here with an update if usage remains the same by EOD.

Update: 3 times after the 5h limits reset, the first message with the small task (the same for all 3 sessions after the limit reset) in a new session caused the usage limit to drop from 100% to 80%. Then, in normal workflow, the limits dropped quickly to 60%, and only after that did usage slow down. That’s what I observed on v2.1.81. Then I switched back to v2.1.101 (the latest version currently available in the VS Code extensions), and I didn't notice that sudden drop in limits from 100% to 80%, but overall the whole limit was still used up faster from the beginning.

Btw: @cnighswonger the link to https://veritassuperaitsolutions.com/three-layer-gate-quota-overage/ is not working right now. But I can see there seems to be some problem with the veritassuperaitsolutions.com domain.

Update 2: Actually v2.1.81 and v2.1.101 have the same issue in case of beginning of the new or existing chat session - sudden drop in limits. It is related rather to cache bug you described recently. I saw that v2.1.108 is now available, will try. If that doesn't help, I'll try claude-code-cache-fix.

@Artur-Y — thanks for reporting back. Your experience is an important correction to our earlier guidance.

We're updating our recommendation. Our Part 1 blog post recommended pinning to v2.1.81 based on cross-version analysis showing it was the last pre-regression release. Since then, Anthropic confirmed the Layer 1 bug was fixed in v2.1.90, and community testing of v2.1.104 shows further upstream convergence — the resume-scatter issue that was our interceptor's primary fix is now mitigated in CC itself.

Updated first-line advice: upgrade to v2.1.104 rather than pinning to v2.1.81. v2.1.81 misses the v2.1.90 bug fix AND the v2.1.104 resume-cache improvements, which likely explains why it performed worse for you.

If v2.1.104 still shows excessive drain, our interceptor (claude-code-cache-fix) adds 1h TTL enforcement on subagent calls, fingerprint stabilization, and a status line that makes the TTL tier visible — so you can see whether you're hitting the 5m downgrade at quota cap.

npm install -g @anthropic-ai/claude-code@2.1.104
npm install -g claude-code-cache-fix@1.7.2

Part 2 of our blog (publishing today) reflects this updated guidance.

Part 2 is now live with the updated guidance: https://veritassuperaitsolutions.com/the-three-layer-gate/

Corrected link for Part 2 (apologies — wrong slug earlier): https://veritassuperaitsolutions.com/three-layer-gate-quota-overage/

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 (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/0cc1a90f-09dc-427b-9248-191343e6179f" />

The workaround that sticks is managing records and instructions outside the Claude context window and injecting your own curated instructions based on these to produce your own reliable context in every prompt before compaction happens.

It's not ideal. But it's worked well for me. I stopped relaying on the session and context window to remember important bits for me and offloaded them to files.

I wrote a solution for this in the form of a plugin for Claude code and Cowork.

https://github.com/NominexHQ/pmm-plugin

Wasn't intended to be just a memory layer for Claude. It's intended as a memory layer for multi-agent workloads in multi user and multi channel environments.

I was happy developing this natively on Claude until my second account for work got banned 30 minutes into paying for a max 20 plan.

It's the dependency on Claude that I'm solving. On any LLM harness actually. Users should be free to choose which harnesses and which models to work with. Memory should be portable across environments.

That explains why I've accelerated my development of the same plugin for opencode. We'll be releasing a single memory framework that works for both opencode and Claude code. Being banned simply poured kerosene on the fire for me.

Having to endure context rot and poisoning is going to be the kerosene on fire for you.

+1, seeing the same thing today (April 14, ~17:00 CET) on Max 5x with Opus 4.6 (1M). Session cap hit noticeably faster than usual, maybe 10% of the 5h window gone in ~10 minutes of normal work.

Secondary data point that might help debugging: there's a mismatch between what the web UI and /api/oauth/usage report while the session is over cap.

• Web UI (claude.ai/settings/usage): Current session 100% used
• /api/oauth/usage response at the same moment: five_hour.utilization: 86
• extra_usage.used_credits was actively climbing, went 5666 → 8394 (+2728) between two API calls a few minutes apart
• /api/oauth/usage itself returned rate_limit_error on several attempts while over cap, so the endpoint is throttled exactly when you most need it to debug

So a statusline script that reads five_hour.utilization directly shows 86% while the user is actually at 100% and burning overflow credits. Not the main bug, but worth flagging because it makes the drain harder to notice in real time - you trust the statusline, statusline lies, by the time you check the web UI you're already deep into extra usage.

CC version: 2.1.108
Plan: Max 5x
Model: Opus 4.6 (claude-opus-4-6[1m])

@przadka Good catch on the 86% vs 100% mismatch. Two separate issues here:

1. API endpoint vs web UI discrepancy — you're seeing /api/oauth/usage report 86% while the web UI shows 100%. That's a real inconsistency worth tracking.

2. Extra-usage balance doesn't live-update — we've noticed that the quota gauges on claude.ai/settings/usage update dynamically (ajax), but the extra-usage dollar balance does not refresh without a manual page reload. So you can be burning credits at $3-5/prompt with no visible indication on screen. Filed as #48093.

Re: statusline accuracy — our interceptor reads quota state from the per-response anthropic-ratelimit-unified-5h-utilization header, not from the /api/oauth/usage endpoint. These headers come directly from the model-serving infrastructure on every API call, so they may be more accurate than the OAuth endpoint (which appears to be a separate system that can lag or throttle).

If you're running the interceptor, you can compare the header-based statusline against the web UI and /api/oauth/usage to triangulate which source is most reliable. Would be valuable data — we haven't seen the header-based reading diverge from reality by more than a few percent in our testing, but more eyes on it would help confirm.

Dropping a data point for this tracker — my Max $200 week was hit too. Pulled my logs and ran them through a burn-rate analyzer I wrote earlier today: $5,163 in 7 days, 100% on Opus, 11,254 API calls. The tool flagged that ~$2,062/week of that could've been Sonnet based on task complexity — which if true means a non-trivial share of the "drain" isn't just Anthropic squeezing, it's also heavy users defaulting to Opus when Sonnet would do.

Doesn't excuse the lack of communication about the 3/23 changes (that's the real bug), but it might help contextualize individual reports here: some of the "abnormally fast" consumption is real rate-limit compression, some is users (me) not realizing Opus costs 5× Sonnet and burning through in ways they didn't before when limits were looser.

If anyone wants to see their own split: https://genie-j.github.io/burncheck/ — single-page, reads ~/.claude/projects/*.jsonl locally, no upload. Source: https://github.com/Genie-J/burncheck. The more of us in this thread with concrete per-model numbers, the harder it is for Anthropic to wave off as edge cases.

I just went from 0% to 100% in 7 minutes, while trying to debug the API limit bug.

I currently have 4 20x accounts and 1 Codex which is my 'second opinion'/reviewer. The lack of transparency and response from Anthropic is enough to check out Codex as my main workhorse and use Claude for review instead (I've found the token limits to be way higher on Codex).

Anthropic; less focus on tangential industries and more focus on your core product would be advisable.

Hi all, if you see this again, can you please run /feedback and share the id here? That will make it possible for us to debug what's going on, or if it's already fixed in the latest release. Things should also be feeling much better with Opus 4.7 (we've raised rate limits for 4.7 to make up for its increased thinking).

I've sent 5 prompts today, and have used 30% of my 5 hour limit on the Pro plan in a few minutes. Literally just now the 6th prompt has jumped to 44% usage.

Hi all, if you see this again, can you please run /feedback and share the id here? That will make it possible for us to debug what's going on, or if it's already fixed in the latest release. Things should also be feeling much better with Opus 4.7 (we've raised rate limits for 4.7 to make up for its increased thinking).

If you haven't yet, I suggest you take look at the many documented bugs, eg listed at https://github.com/cnighswonger/claude-code-cache-fix. Frankly, it's concerning that this isn't being taken seriously.

@bcherny happened again just now, reported via /feedback

I have begun hitting session limits in my Pro account repeatedly over the last week (never before) - and CC in Cli just consumed all my session, half my week, and £21.27 in extra usage for 40 minutes of reworking local text folders using a local .py process 😲 I am hoping this is a bug, and not a new feature. /feedback feels like crying into a void.

+1, same here

@bcherny Hit this again today, reported via /feedback

@bcherny Submitted via /feedback just now.

Feedback ID: fbd1683b-4ad3-47e0-80e8-55d501c1d018

Two data points on the same Anthropic org:

My account (Max 20x + Tier 4 API, heavy Claude Code user with autonomous /loop sessions, BOSS-orchestration): Mar 28 single-day API spike of $26.30, 82% of which was Claude Opus 4.6. Console monthly now at 96% of $60 cap.

My wife's account (Max 20x, human-driven coaching + personal use, some autonomous sessions, NO multi-terminal, no --resume workflows): extra-usage trajectory $15.83 (Mar 8) to $380.28 (Apr 14), 24× increase over 5 weeks. Biggest single jump: Mar 28 → Apr 1 (+$169 in 4 days), exactly aligned with v2.1.88 release.

The second data point matters because her workload doesn't involve any of the Claude Code usage patterns this community has identified as contributing factors (autonomous loops, --resume, multiple terminals, heavy sub-agents). Same inflection date, two different usage profiles. Consistent with a server-side change rather than purely client-side cache regression.

Happy to provide API CSVs or additional data if useful.

Confirmed bug reproduction with ccusage data — Pro plan, Claude Code

I'm a Claude Pro subscriber and hit severe abnormal usage drain today (April 20, 2026) that wiped out my entire monthly quota in a single morning session.

Hard data from ccusage

Session project-a today:

| Metric | Value |
|--------|-------|
| Input tokens | 837 |
| Cache read tokens | 64,798,458 |
| Cache read / input ratio | ~77,000x |
| Total cost equivalent | $36.11 |

Comparison — test-bug session (fresh session, only typed "say hello"):

| Metric | Value |
|--------|-------|
| Input tokens | 3 |
| Cache read tokens | 11,819 |
| Ratio | ~4,000x (normal — just system prompt overhead) |

The project-a ratio is ~19x higher than a completely empty session. I was not using --resume. This was a fresh session in an active project directory.

Environment

• Stack: Nuxt project
• Skills: ui-ux-pro-max (loaded on-demand, 236 tokens per /context)
• MCP: 21st.dev (load-on-demand, 0 tokens overhead per /context)
• Context at peak: 48.2k/200k (24%) — completely healthy
• Claude Code version: 2.1.114

Trigger identified

Running /handoff (a custom skill that generates a session summary) caused an immediate 20% quota drain in a single call. The skill writes a markdown file — minimal real work — but cache read exploded.

Why this is the cache bug and not user error

• Total input tokens for the entire session: 837 (I barely typed anything)
• Cache read: 64 million tokens
• Baseline from empty test session: ~12k cache read for 3 input tokens
• Project context was clean and healthy per /context

Impact

• Entire Pro monthly quota consumed in ~3 hours
• Now on "extra usage" billing for work I did not meaningfully perform
• Significant lost productivity diagnosing what I assumed was a configuration problem

Questions

1. Can Anthropic confirm whether version 2.1.114 is affected by the cache invalidation bugs described in this issue?
2. Is there a patched version available or a reliable workaround beyond avoiding --resume?
3. Is there a path to getting extra usage charges reviewed/refunded for quota consumed due to this bug? The ccusage data makes it clear the consumption was not driven by actual work.

+1 - I've been experiencing two of the above issues. First, token's get consumed much faster than a few weeks ago. A single prompt that only ran for 3 minutes burnt over 40% of my 5-hour limit. Second, even when idle the Claude desktop app appears to burn tokens. I logged in today and check usage to find 5% of my 5-hour limit was consumed yet I had zero prompts.

+1 Since the release of Opus 4.7 (which I'm NOT USING NOW, I switched back to Opus 4.6) I reach my 5-hour limits after 1h, weekly limit after 5d. I NEVER hit my weekly limit before, the 5-hour limit only once or twice. What happend?!

Adding a 2026-04-21 data point on v2.1.116: overnight multi-agent run (pm-coordinator + Sonnet sub-agents) consumed approximately 20% of monthly API utilization while producing zero forward progress.

The compounding effect your reverse-engineering identified is real and severe in autonomous/overnight use cases. Without reliable cache hits, a session that's blocked on permission prompts (separate regression, #39523/#51590) just burns tokens re-rendering the same context over and over while waiting for human input that never comes.

For what it's worth: the native binary install doesn't help with the permissions side of this. Both failure modes need to be fixed. The token drain without caching is bad; the token drain when the session is also completely stalled is indefensible.

I understand Anthropic's public position is "no overcharges" but 20% utilization for a session that accomplished nothing is functionally an overcharge regardless of the accounting semantics. Would strongly support a formal acknowledgment and timeline here.

I just blew through my 5 hour token limit in 10 minutes. I thought I would test claude out coming from codex. Holy cow, what a rude awakening. I can't even pull the work out to save it.

5 hour session burned after 15 minutes of writing one PHP test.

Burning through a Max plan in 3 days. Setup: 1 Opus PM window + 6-8 Sonnet workers at medium effort, coordinating via filesystem handshake files. All sessions running against a large project (CLAUDE.md ~200KB, loaded by every agent on every turn).

Overnight run on v2.1.117: woke up to 20% of monthly quota consumed, zero work done. The permission inheritance bug (#37442) blocked all workers on permission prompts -- agents stuck waiting, context growing, auto-compact triggering, loop repeating.

But even on sessions where work IS happening, the burn rate is unsustainable. 1 Opus + 6 Sonnet sessions reading a large CLAUDE.md on every turn, if cache reads are now counting at near-full rate toward quota, we're paying for the same 200KB being loaded 7 times per turn across all windows. That's structural token waste, not usage.

The combination of: large shared context + multi-window setup + cache-read quota counting + auto-compact loop = quota gone in days, not months. Each individual bug seems minor. Together they make autonomous multi-agent work economically impossible on any plan tier.

Running v2.1.118 now. Permission prompts slightly better. Token burn still happening.

Quantified burn rate, v2.1.118, Thursday morning update:

• Billing cycle started: Tuesday 10pm
• Current usage: 54% consumed
• Time elapsed: ~34.5 hours
• Burn rate: ~1.6% per hour
• Projected to hit 100%: Friday ~8am -- roughly 60 hours into the monthly cycle

Setup: 1 Opus PM window + 6-8 Sonnet workers at medium effort, coordinating via filesystem. Project has a large shared CLAUDE.md (~200KB) loaded by every agent on every turn.

Last night was better than the previous night -- agents actually completed a task rather than spinning. But the burn rate is still on track to exhaust a monthly Max plan in under 3 days.

If cache reads are now counting toward quota at near-full rate (per #24147), 7 agents each loading 200KB context on every turn is the likely structural driver -- not compute, just context loading.

Clean before/after data point -- same workflow, different quota behavior:

Before (prior billing cycles): Full week of Sonnet workers + 1 Opus PM, no quota issues. Workflow ran overnight without hitting limits.

After (current cycle, v2.1.117-118): 54% consumed in 34.5 hours. Same models, same effort level, same multi-agent setup, same project files. Nothing changed on my end.

That is a 5-10x multiplier on effective quota consumption for identical work.

If cache reads are now counting toward quota at near-full rate, the mechanism is clear: a large shared CLAUDE.md loading across 6-8 agent windows on every turn went from near-free to full-price overnight. The compute cost is the same. The file reading cost exploded.

This is not a usage pattern change. Something changed on Anthropic's side. The Mar 23 date that keeps appearing across this thread matches the inflection point.

Correction to my earlier timeline: the inflection point for this user is Opus 4.7 launch (~April 16), not March 23.

Three compounding factors arrived together with the Opus 4.7 release:

1. Opus 4.7 pricing -- if 4.7 costs more per token than 4.6, every Opus PM session got more expensive silently.

1. The 200K vs 1M context window bug (fixed in 2.1.117): before the fix, Opus sessions hit auto-compact at 200K tokens instead of 1M -- 5x more compactions per session, each one burning tokens. This ran for an entire week before the fix shipped.

1. 2.1.117 silently changed default effort to "high" for Pro/Max on Opus 4.6 and Sonnet 4.6. Any worker session not explicitly set to medium jumped to high effort without the user changing anything.

All three hit simultaneously. A week of Opus sessions running the wrong context window limit + higher effort defaults + potential pricing change = multi-agent overnight workflows that used to run fine for a week now burning a monthly Max plan in under 3 days.

Confirmed empirically: default effort is now "high" for BOTH Sonnet and Opus, not just Opus as the changelog implied.

Any multi-agent setup that did not explicitly set effort level on each worker got silently upgraded to high effort across every session after the 2.1.117 update. For a 6-8 agent overnight pipeline, that is 6-8x the effort multiplier applied without any user action or notification.

Users need to explicitly set effort to medium (or their preferred level) on every agent window -- there is no way to set a global default. This is not documented anywhere visible.

Confirmed, brand new seat on our team account as premium, didnt even have terminal or CC open. I had done earlier in the day with a different account and had used a --resume, i dont know if the was a phantom background runner or something. but i sat and watched my 5 hour session hit 100% within 22 mins.
I did find some claude processes running in activity montior, which disappeared once i hit 100% usage

Hey all, we have root caused and fixed this. Detailed technical post-mortem here: https://www.anthropic.com/engineering/april-23-postmortem. If you see any more issues/weirdness, please don't hesitate to run /feedback + open an issue.