Sudden 5-hour session window squeeze starting Apr 29, 2026 evening
Summary
Since the evening of April 29, 2026, the 5-hour session window depletes 5–10× faster than before for the same kind of work. A typical light editing session (a few scp, Read, small patches via Edit) burns ~20–25% of the session window in well under an hour. Sonnet sub-agents launched via Agent repeatedly hit "You've hit your limit" within 15–30 minutes of work — they used to run for hours.
The frustrating part is that the weekly quota is barely touched — W shows ~59% remaining with 23+ hours of headroom — yet the session-window cap blocks me from using that headroom. I have plenty of weekly budget, but the 5-hour window won't let me spend it.
Context
I'm aware of the April 23, 2026 post-mortem about restoring high reasoning effort and reverting the verbosity prompt. Those changes do explain some token-cost increase per turn. They do not explain the disproportionate ratio between session-window depletion and weekly-quota consumption that started on April 29 specifically — i.e. several days after the April 23 fix.
Reproduction signals
S(5-hour session window) hits 20%+ within 30–60 minutes of light tool use.W(weekly) shows large remainder + many real-time hours of headroom.- Multiple parallel
Agent(Sonnet sub-agent) launches all hit limit within minutes — burning quota seemingly faster than total work would suggest. - Started: 2026-04-29 evening (Europe/Kaliningrad timezone). Confirmed by independent users referencing the same date.
Ask
- Please confirm whether anything changed in the session-window accounting on April 29 (UTC evening).
- Either widen the session window proportionally to the new per-turn cost, or document the new ratio so users can plan around it.
Impact
Right now Claude Code, for which I subscribe primarily on Max tier, is significantly less usable than it was a week ago — not because of model quality (which is good), but because the cadence of forced waits has gone from "rare and predictable" to "every hour or so, no matter how lightly I work."
I do want this to keep working — that's why I'm reporting.
---
Mitigations I've applied so far:
- Lowered
effortLevelfromhightomediumin~/.claude/settings.json(~1.5× longer windows but at quality cost). - Stopped launching Sonnet sub-agents in parallel (they cannibalize each other's quota).
- Splitting big tasks into ~30-minute Sonnet chunks instead of 90.
These help, but they're workarounds, not solutions.
37 Comments
+1. Few bug reports are opening now that see the same issue. I've also experienced this as well.
Looks like many people are reporting this kind of issue today. The shrinking is simply too much and makes the Max plan unusable. +1
I leave this here, this happened yesterday 29/04/2026 :
<img width="1368" height="754" alt="Image" src="https://github.com/user-attachments/assets/aaa03efe-b162-481a-b079-504570cbffe7" />
x20 plan the 5 hour limit reached in 20 minutes with one session running that had 5 subagents running in parallel. This has never happened before. It was outside of peak hours.
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
+1. totally unusable
@claude
Same issue on Claude 20x Max, started 2026-04-28. ~50% reduction in effective per-session throughput vs prior baseline, same workload. Feedback ID: 6df5e904-d285-43cc-ab11-4518e6f909df
Hi, just experienced the same issue. First, everything was normal, the 5h limit was being consumed at normal speed. Then suddenly, a request made my usage go from ~35% to 90% (Opus 4.7, xhigh). Just after that, I asked Claude Opus 4.7 (this time with medium reasoning) to perform "git push". Went from 90% to 100% usage, while I believe the cache was still up as I replied immediately after it responded. I'm on a 5x Max plan, and the context window for this chat was 233.6k/1.0M.
Hi all, so sorry about this, we are investigating.
/feedback? Then post your feedback uuid here.More information here will be incredibly helpful.
/feedback doesnt seem to exist on Claude Code Desktop. I would love to help but I can't find a way to get a UUID from the app.
Claude Desktop version: Claude 1.5354.0 (9a9e3d) 2026-04-29T01:14:34.000Z
Good day Suzanne.
How can we get into previous closed sessions or report session ID's? Also, it's not really about specific sessions. The issue is happening at every session. Usage speeded up twice at least.
@szwang I've tried the Claude Code version from last week release and the token consumption is still insanely abnormal. The problem started for me around 29 of April 7:00AM UTC.
I've got several 5h window consumed really fast (under 30 minutes). One 5h window of (~30 min usage) is consuming 15% of the weekly quota. On this pace I will consume my weekly quota in under 3 days. Usually the weekly quota for the Max 5x plan is almost unreachable even when using the effort on max.
Feedback ID: 94b7c59a-e350-4c9a-ae7d-3408768e4a8b
Claude code 20x subscriber here. I never even saw a usage limit past 6 months. Last 2 weeks, the $200 plan feels like the $20 plan.
Feedback ID: 501f7790-3d15-441e-99ea-318491022f18, Claude Code 5x.
I never got a warning that I was nearing the limit. And I had much longer sessions without even hitting 80% on previous days(even without compacting the session, which I did now), and I pretty much never hit the limit 2~ hours into the session window before this.
In my case it happened between 14:00 and 19:00 (2-7 PM) CET.
I understand it might have happened during the "rush hour" in which Anthropic declared to have shrinked the usage limits, but this might have gone too far if that's the case. If there's a dynamic usage allowance, it's not tuned in a sustainable way for the user. Just my 2c.
I must say the non-rush-hour limits feels like they've been shrinked too. Hit the limit in 2h single agent on Max 5x, Opus 4.7. Only coding and self-review. I barely intereacted with it.
This is looking better now. I've been working non stop for the last 3 hours and i'm only at 18% session usage for the 5 hour window. Way more like we expect.
I can confirm. 2h30' @ 60% (5x Max) - maybe we are out of rush hours?
v2.1.126 using since 01 of May 00:05 (UTC) the abnormal usage is gone.
I've noticed that the subagents are back to the old version where the conversation cannot be accessed.
Thanks for fixing the bug.
PS: I just want to add a note that the usage available is still too strict and has been reduced drastically, specially the 5h window. It should be a daily window instead, this 5h window is degrading people's sleeping cycle.
This was me speaking too soon.
Same issue until this evening UK time. Rarely used to hit 5h limit but consistently hit it last 3 days since 29th
+1 Italy here. Hit the 5h mark in 1h 30' <1M tokens. Definitely a daytime issue. limits are at least 2x tighter.
My weekly quota is now depleted too, resetting on Tuesday. This is an absolute nightmare.
I am seeing the same issue on Claude Max 20x.
This has been happening for 3 days. On May 2, 2026, immediately after my weekly limits reset, one prompt consumed 28% of my 5-hour session window. Weekly usage was still only 4% All models and 5% Sonnet-only.
Environment:
This makes Claude Code unusable for normal work. It looks like the 5-hour session window accounting is draining far faster than weekly usage, even immediately after the weekly reset.
I am seeing the same issue on Claude Max 20x.
This has been happening for 3 days. On May 2, 2026, immediately after my weekly limits reset, one prompt consumed 28% of my 5-hour session window. After the second prompt, the 5-hour session window reached 50% used.
Weekly usage was still only 7% All models and 9% Sonnet-only.
Environment:
This makes Claude Code unusable for normal work. It looks like the 5-hour session window accounting is draining far faster than weekly usage, even immediately after the weekly reset.
I am seeing the same issue on Claude Max 20x.
This has been happening for 3 days. On May 2, 2026, immediately after my weekly limits reset, one prompt consumed 28% of my 5-hour session window. After the second prompt, the 5-hour session window reached 50% used. After the next prompt/action, the current 5-hour session reached 83% used.
Weekly usage was still only 11% All models and 16% Sonnet-only.
Environment:
This makes Claude Code unusable for normal work. It looks like the 5-hour session window accounting is draining far faster than weekly usage, even immediately after the weekly reset.
Follow-up: the 5-hour session is now fully exhausted.
After only a few prompts/actions since the weekly reset:
So the session window is completely depleted while weekly usage is still low. This strongly suggests the 5-hour session window is being accounted much more aggressively than the weekly limits.
I found it to be strictly time-related. There are rush hours that aggressively let you eat up those limits. For me in central EU is during the afternoon.
I’m using Claude Code v2.1.126 on the Pro plan. This morning, I asked two built-in subagents to change my codebase, and they consumed my entire 5-hour usage window in less than 10 minutes. The change itself was simple: replacing instances of
System.out.printlnandSystem.out.printfin Java code with Log4j method calls.I had the subagents’ JSONL logs analyzed with a quick Bash script, and it showed 78 Read operations across 23 files, as well as 75 Edit operations across 8 of those files. In particular, the most extreme case appears to have performed 17 full-file Reads on the same file.
I’m still new to Claude Code, so I assume this may have been due to how I used the subagents. Still, I can’t help but question whether this is expected behavior for the built-in subagents. I’m not sure whether this is related to this issue, but I hope the information is useful for the investigation.
grep -hoE '"name"[[:space:]]:[[:space:]]"[^"]+"' "$J1" "$J2" | sort | uniq -c | sort -nr
78 "name":"Read"
75 "name":"Edit"
3 "name":"Bash"
1 "name":"ToolSearch"
== Usage summary ==
usage_entries: 185
input_tokens: 21,269
output_tokens: 47,811
cache_creation_input_tokens: 1,649,869
cache_read_input_tokens: 13,782,441
new-ish input + output: 1,718,949
logged incl cache_read: 15,501,390
Escalation update, May 3, 2026:
This is still happening after the new paid Max 20x subscription period/payment. This is not a stale report from Apr 29/30.
Latest observed usage:
Support response says the pattern can be explained by parallel sessions, subagents, and >150K context. I understand those factors increase usage, but this is still not an acceptable/accountable product state for Max 20x:
/usagestill showed consumptionLocal process check on Windows showed many active Claude/Node/Bun processes, so the parallel-session explanation is plausible. But that strengthens the request: Claude Code should expose, warn, or cap this behavior before it silently burns Max 20x quota.
Please escalate this as a cost/accounting UX bug, not only "expected usage". Paid users need either:
Environment:
Same issue here. Within minutes, my Max (20x) plan is hitting limits, and what is worse, draining hundreds of euros from the extra usage balance. We need Claude to solve these issues, reset limits and refund us the money.
Session window draining 5-10x faster is usually accumulated context bloat — old tool outputs, stale reads, and metadata all get re-sent every turn. Cozempic's guard daemon auto-prunes continuously with 4 thresholds so context stays lean throughout the session.
pip install cozempic— hooks wire automatically on first run. https://github.com/Ruya-AI/cozempic — let me know if it helps.My Claude Code on PRO is unusable, I get one or two prompts and my usage jumps to 74% straight away and then runs out. I put $5 API credit in and got one prompt and it was used up. I tried to run /feedback but I get the error "/feedback is only available for local sessions on this desktop build"
5h window still consuming 12% of weekly usage on Max 5x using effort xhigh
It wasn't able to complete the plan without hitting the 5h limit and the main conversation context was still under 150k
Built-in subagents were used to avoid context rot, each tackling 1 phase of the plan.
Fedback ID: c5e34a45-b519-48ba-bd78-64854fee5467
At this point it's clear this was intentional.
Now they released the news about SpaceX partnership which will grant more computational power and allow them to remove the peak hour squeeze: basically back to pre-April 29th (intentionally) bugged limits. Cringe af.
The exact same issue recurred on June 10, 2026 — one-to-one with the original April 29 squeeze.
Timeline (Europe/Kaliningrad):
Workflowtool) with no session-window problems whatsoever. Effort level is constant in our setup, so it is not the variable.ssh/Read/Editcalls plus one background Sonnet sub-agent. This is the same 5–10× depletion rate described in the original report.What changed on our side right before the recurrence: the session was migrated to the newly released model (
claude-fable-5) after the model update rolled out. Same machine, same settings, same workload pattern as the previous two weeks.Symptoms identical to April 29:
Agent/Workflow) hit "You've hit your session limit" within minutes;Will attach a
/feedbackUUID from the affected installation shortly.i'm seeing the same since apr 29 evening, the 5 hour session window burns 5 to 10x faster for light edits and sonnet agents hit limit in 15 to 30 minutes. fwiw wozcode cut my token spend about 50 percent with better caching https://wozcode.com