Environment
- Plan: Max 20 ($200/month subscription)
- Claude Code version: 2.1.89 (auto-updated today, April 1 2026)
- Previous versions: 2.1.86 (Mar 28) → 2.1.87 (Mar 29) → 2.1.88 (Mar 31) → 2.1.89 (Apr 1)
- Model: Claude Opus 4.6 (1M context)
- OS: Ubuntu 24.04, Linux 6.14.0-1020-oem (HP ZBook Ultra G1a)
- Node: v22.22.1
- Settings: effortLevel: "high", 1 PostToolUse hook (ruff linter, lightweight)
Problem
Starting today (April 1, 2026), my 5-hour rate limit reaches 100% far too quickly. This happened twice in the same day.
This has never happened before. I have been a Max 20 subscriber for months and have never hit the limit this fast, even with identical (or heavier) usage patterns.
Timeline
| Time |
Event |
| ~08:30 KST |
Started working (remote session) |
| ~11:30 KST |
Noticed rate limit already at 100% — roughly 3 hours of normal usage |
| 12:00 KST |
Rate limit reset confirmed |
| 12:00~ KST |
Resumed normal work immediately after reset |
| ~13:10 KST |
100% usage again — exhausted in ~70 minutes of light conversational work |
What I was doing
- Normal conversational coding tasks (not bulk/batch)
- Working from home directory with project CLAUDE.md (~17KB) + MEMORY.md (~14KB) auto-loaded
- No unusual tool-heavy operations, no massive file reads
- Same workflow I've used daily for months without issues
What changed
- v2.1.89 auto-updated today (Apr 1, 10:15 KST) — but the morning session (pre-update) also had the same issue
- v2.1.88 installed Mar 31 — issue may have started then
- No changes to my settings, hooks, or project files before this started
Investigation done
- Optimized CLAUDE.md + MEMORY.md from 30KB → 14KB (53% reduction) — did not resolve the issue
- Confirmed no heavy background processes or concurrent Claude Code sessions
- Checked GitHub issues — found related reports:
Expected behavior
With Max 20 plan and normal conversational usage, the 5-hour rate limit should last at least 3-4 hours of active use, as it has for the past several months.
Actual behavior
- Morning: 100% in ~3 hours
- Afternoon (after reset): 100% in ~70 minutes with even lighter usage
Reproducible across two consecutive reset cycles on the same day.
Possible causes
- Server-side change in how cached/thinking tokens are counted against rate limits
- Prompt cache invalidation causing full re-processing of system prompts each turn
- Rate limit calculation regression in v2.1.88 or v2.1.89
- Model change (Opus 4.6) affecting internal token accounting
Request
I am paying $200/month for the Max 20 plan, and the service has become practically unusable — 70 minutes of light usage per 5-hour window is not acceptable for a premium subscription. This is severely impacting my daily workflow and productivity. I would appreciate a prompt investigation and resolution of this issue. Thank you.
Related issues
Environment
Problem
Starting today (April 1, 2026), my 5-hour rate limit reaches 100% far too quickly. This happened twice in the same day.
This has never happened before. I have been a Max 20 subscriber for months and have never hit the limit this fast, even with identical (or heavier) usage patterns.
Timeline
What I was doing
What changed
Investigation done
Expected behavior
With Max 20 plan and normal conversational usage, the 5-hour rate limit should last at least 3-4 hours of active use, as it has for the past several months.
Actual behavior
Reproducible across two consecutive reset cycles on the same day.
Possible causes
Request
I am paying $200/month for the Max 20 plan, and the service has become practically unusable — 70 minutes of light usage per 5-hour window is not acceptable for a premium subscription. This is severely impacting my daily workflow and productivity. I would appreciate a prompt investigation and resolution of this issue. Thank you.
Related issues