Max 20x plan hitting daily limit with reduced usage — limits appear silently tightened (April 28-29, 2026)
Summary
Max 20x subscriber ($200/month) consistently hitting daily usage limits on April 28-29, 2026, despite reduced usage compared to previous weeks. No change in workflow, plugins, or usage patterns. Running Claude Code v2.1.123 — well past the v2.1.116 fixes from the April 23 postmortem.
Environment
- Plan: Max 20x
- Claude Code version: 2.1.123
- Model:
claude-opus-4-6[1m] - Effort level:
high - Platform: macOS (Darwin 25.3.0)
What happened
- Hit the daily usage limit on both April 28 and April 29, 2026
- Usage patterns have not increased — if anything, usage was less than usual
- The rate limit message mentioned high subagent usage, but subagent usage has not increased
- Previously sustained heavier workloads on the same plan without hitting limits
What has NOT changed
- Same plugins enabled (no new plugins added recently)
- Same model (
claude-opus-4-6[1m]) - Same effort level (
high) - Same types of tasks (coding, research, code review)
- Researcher plugin (which spawns many Opus subagents) was disabled during this period
- No increase in session length or frequency
The broader pattern
This is not an isolated report. There is a documented pattern of Max plan limits being silently reduced over time:
- Issue #28848 (Feb 2026): "Max plan usage limits silently reduced since Claude 4.6 release" — labeled "invalid" with no explanation
- Issue #17084 (Jan 2026): "Opus 4.5 usage limits significantly reduced since January 2026"
- Issue #4203 (earlier): "Significant Rate Limit Reduction in Claude Code — Impact on Professional Workflow — $200 max plan"
- Issue #41788 (Apr 2026): "Max 20 plan: rate limit 100% exhausted within ~70 minutes after reset"
Each time, users report the same thing: limits suddenly tighter with no change in usage. Each time, no concrete response from Anthropic about what changed.
The transparency problem
The core issue is that Anthropic does not publish concrete limits for any plan tier. The official help article (Using Claude Code with your Pro or Max plan) says only that "usage limits are shared across Claude and Claude Code." No token budgets, no 5-hour window sizes, no weekly caps — just opaque percentages.
This means:
- Users cannot verify whether they are getting what they pay for
- Anthropic can adjust limits at any time without announcing changes
- When users report tighter limits, it's impossible to prove because there are no published baselines
- The "20x" in "Max 20x" is meaningless without knowing 20x of what
Compute constraint context
Anthropic's CEO Dario Amodei has publicly described the company as compute-constrained. An Anthropic engineer confirmed on March 26, 2026 that session limits drain faster during peak hours (5am–11am PT), affecting ~7% of users. The April 23 postmortem acknowledged three bugs causing 10-20x token inflation but stated they were fixed in v2.1.116.
If limits are being dynamically adjusted based on available compute capacity, that is understandable from an infrastructure perspective — but it needs to be communicated transparently, not silently applied to paying subscribers.
What I'm asking for
- Publish concrete limits for each plan tier — token budgets per 5-hour window, weekly caps, and how subagent usage counts. Users paying $200/month deserve to know what they're buying.
- Announce limit changes when they happen. Silent reductions erode trust. A simple status page update or changelog entry would suffice.
- Investigate whether limits were reduced between April 23-28, 2026, after the postmortem fixes shipped. If the v2.1.116+ fixes reduced Anthropic's server-side costs (by fixing cache bugs that inflated usage), was the "savings" passed on to users, or were limits tightened to absorb it?
- Clarify whether the 1M context model variant (
claude-opus-4-6[1m]) has different effective limits than the standard context model. If serving 1M context costs more compute, do Max 20x users get fewer requests when using it?
- Provide per-session token breakdowns that show exactly where tokens are going — main conversation vs. subagents vs. system prompt vs. thinking — so users can make informed decisions about their usage.
Labels
bug, usage-limits
Showing cached comments. Read the full discussion on GitHub ↗
13 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
I'm seeing same issue Feedback ID: a646606f-f1ab-4e8b-9666-29f10f531cc6
how does this make any sense:
<img width="1126" height="1089" alt="Image" src="https://github.com/user-attachments/assets/9351e29d-fbc3-4501-8ff5-e04c3a54c6d0" />
90% from sub-agent heavy sessions, but then lower down my top sub-agents used 1%??? fork and explore.
Same picture from another Max-tier subscriber, starting evening of April 29 (Europe/Kaliningrad). Posted detailed numbers and the W-vs-S asymmetry in #55053 — your symptoms match. Particularly the part where weekly quota looks fine but the 5-hour window depletes far faster than expected for the workload.
If others see this, please react/comment so Anthropic has clear signal — appears to be a fleet-wide change made on the evening of 2026-04-29.
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.
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
Thank you all for reporting and posting your /feedback ids. We are investigating
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.
the part that's hardest to argue from the user side is that ccusage and similar local-log tools measure tokens the client sent, not the server quota the rate limiter is actually decrementing. so when you say 'usage was less than usual' you're measuring one thing and the 429 is responding to another. the only number that matches the settings page is the one /settings/usage renders server-side. until that's exposed in the CLI itself you can't bisect 'limits tightened' vs 'one bad cache turn inflated my window' from inside a session, which is why these threads keep going in circles.
Max 20x — concrete usage data showing opacity problem
Plan: Max 20x ($200/month)
Data span: Jan 16 – May 4, 2026 (284 total sessions)
Weekly token consumption (from session-meta, Apr–May 2026)
| Week | Tokens | Sessions |
|------|--------|----------|
| W14 (Apr 1-6) | 807K | 17 |
| W15 (Apr 7-13) | 3.8M | 21 |
| W16 (Apr 14-20) | 5.2M | 19 |
| W17 (Apr 21-27) | 7.3M | 27 |
| W18 (Apr 28-May 4) | 5.7M | 22 |
Key observations
Request
Publish concrete token budgets per plan tier: 5-hour window limit, weekly cap, and clarify whether subagent usage is counted at a multiplier.
Full anonymized data in JSON format available on request — daily breakdown, tool usage, model totals.
Full anonymized dataset: https://gist.github.com/logso2/227991e485b71eb30f0e072bb52ca400
UPDATE May 10:
session-meta/stopped being written after May 4 (Claude Code v2.1.128). History.jsonl shows 42 sessions May 5-9, but zero token data. The only user-side visibility into token consumption is now gone.May 4-9 activity from history.jsonl:
Not a single session-meta file written after May 4 19:47. This means users now have NO local way to track how many tokens they have consumed. Combined with no API exposure for subscription usage, the opacity is now total.
Closing for now — inactive for too long. Please open a new issue if this is still relevant.