You’re mid-refactor, the model’s on a roll, and then the session just stops — “you’ve reached your usage limit” — with no warning that you were even close. If that’s happened to you more than once this year, you’re not imagining a pattern. Claude Code rate limits got worse before they got better in 2026, and most of what you’ve read about them online is either outdated or only tells half the story. The other half — why a handful of MCP servers can drain your quota faster than actual coding does — is the part that actually changes how you work.
How Claude Code Rate Limits Actually Work
Claude Code doesn’t run on a single quota. It runs on two independent gates stacked on top of each other: a rolling 5-hour window that resets continuously, and a 7-day weekly cap that resets on a fixed cycle. Hit either one and you’re throttled — being nowhere near your weekly cap doesn’t help you if you’ve blown through the 5-hour window in one long session.
The part that trips people up: on Pro and Max plans, that usage pool isn’t exclusive to Claude Code. Claude.ai chat sessions and Cowork draw from the same shared budget. Spend an hour brainstorming with Claude.ai in the morning and you’ve already eaten into the allowance you meant to use for an afternoon coding session — there’s no separate “coding” meter.
Weekly caps themselves are a relatively recent addition. Anthropic layered them onto the existing 5-hour windows on August 28, 2025, affecting fewer than 5% of subscribers at launch. At that point, Pro users had roughly 40–80 hours per week of Sonnet access, and Max ($100/month) users had roughly 140–280 hours. Those numbers would get a lot messier eight months later.
The 2026 Rate Limit Timeline: What Actually Happened
If you hit a wall with Claude Code sometime between March and May of 2026, it wasn’t your imagination — that stretch was genuinely rough, and Anthropic has since said so publicly.
March 2026 — the caching bug. A prompt-caching bug caused some sessions to drain usage limits 10x to 20x faster than intended. Anthropic compounded it by reducing 5-hour limits during weekday peak hours (roughly 5–11 AM PT, reported elsewhere as 8 AM–2 PM ET) for Free, Pro, and Max subscribers — meaning the exact hours most developers actually work were the hours limits got tighter. By March 31, Anthropic publicly acknowledged users were hitting limits “way faster than expected” and ran a temporary fix from March 13–28 that doubled 5-hour limits during off-peak hours and weekends, with bonus usage exempted from weekly caps. It was a stopgap, and it expired on schedule.
April 2026 — the apology. Anthropic admitted to three internal engineering missteps, reset all subscriber usage limits, and issued a public apology. Product lead Lydia Hallie wrote on X: “We’re sorry this has been a bad experience.”
May 6, 2026 — the permanent fix. Anthropic doubled the 5-hour rolling-window limits for Pro, Max, Team, and seat-based Enterprise plans, and removed the peak-hour limit reduction for Pro/Max entirely. Weekly caps stayed unchanged, and the Free plan still has zero Claude Code access. Anthropic tied the capacity increase to new compute — a SpaceX deal for 300+ MW (220,000+ NVIDIA GPUs at the Colossus 1 cluster), an Amazon partnership (5 GW), and a future Google deal starting 2027.
Worth flagging: one source, TrueFoundry, still lists weekday peak-hour throttling as active as of its most recent retrieval, which conflicts with three other sources stating it was removed on May 6. The May 6 removal is corroborated by more independent sources, so treat it as the current state — but don’t be surprised if peak-hour behavior still feels inconsistent depending on when you’re reading this.
Current Claude Code Limits by Plan
Anthropic doesn’t publish exact prompt or token counts per plan, so the numbers below come from independent third-party testing rather than an official table. Treat them as directional ranges, not guarantees — actual usage varies with prompt length, context size, and model choice.
| Plan | Price | 5-Hour Window (approx.) | Weekly Cap (approx.) |
|---|---|---|---|
| Pro | $20/mo | ~10–45 prompts (≈44,000 tokens) | ~40–80 hrs/week Sonnet (shared pool with Opus) |
| Max 5x | $100/mo | ~50–225 prompts (≈88,000 tokens) | ~140–240 hrs/week Sonnet, 15–35 hrs/week Opus |
| Max 20x | $200/mo | ~200–900 prompts | ~240–480 hrs/week Sonnet, 24–40 hrs/week Opus |
| API (pay-as-you-go) | Per-token | Tier-based requests/tokens per minute, not session-based | No weekly cap — billed per token |
Estimates last verified: August 2026 (independent testing, not official Anthropic figures).
The Pro/Max split matters more than the headline numbers suggest. Max plans separate Sonnet and Opus into distinct weekly buckets, so heavy Sonnet use doesn’t touch your Opus allowance. Pro shares one pool across both models — use Opus on Pro and you’re draining the same limited bucket you need for everything else. On Max, the Opus bucket is smaller and drains first if you lean on it. And if you’re pushing prompts past 200K tokens, expect 2x standard API billing on those requests, per one source.
The Real Reason You’re Hitting Claude Code Rate Limits
Plan math explains part of the picture. It doesn’t explain why two developers on the same Max plan can have wildly different experiences — one cruising through a full workday, the other hitting a wall by lunch. The gap usually comes down to three things, and the first one catches almost nobody by surprise until they see the number.
MCP servers are quietly expensive. Every connected MCP server registers its full tool catalog into the model’s context on every single turn — whether or not you ever call those tools. That’s typically 200–800 tokens of prose plus JSON schema per tool, times roughly 50 tools per server. One documented case showed seven connected MCP servers consuming 67,300 tokens — 33.7% of a 200K context window — before a single user message was even sent. A “just in case” server you connected once and forgot about is still billing you for its tool definitions on every message.
Subagents inherit the whole mess. Subagents don’t get a clean slate — they inherit the parent session’s full MCP tool definitions. With enough servers configured at the user level, subagent tool schemas alone can exceed Sonnet’s 200K context limit, causing the subagent to fail immediately with a “prompt is too long” error before it executes a single tool call. This is a tracked, known issue against anthropics/claude-code on GitHub, not an edge case. Subagents also start cold, so they frequently re-read files the parent session already loaded — duplicating token cost on top of the schema overhead.
Model choice and session length compound it. Opus burns through allowance faster than Sonnet, and on Max it draws from a separate, smaller weekly bucket that depletes first. Long, unmanaged sessions accumulate stale conversation history, and every resend of that bloated context re-costs tokens — prompt caching offsets some of this, but only for the portion of the prompt that’s actually cached.
If you want one number to check today: open a fresh Claude Code session, look at how many MCP servers auto-connect, and ask whether you’ve actually used all of them this week. Most developers haven’t.
How to Work Around Claude Code Rate Limits
Not all workarounds are equal — some are just good hygiene, and one is a genuine Terms of Service gray area. Ranked roughly by legitimacy and impact:
1. Proactive context hygiene. Run /compact at natural checkpoints — after finishing a refactor, fixing a bug, before starting a new module — to compress history while keeping the decisions that matter. Use /clear when you’re switching to a genuinely unrelated task, or when the context is “poisoned” by an assumption Claude keeps reverting to; /clear wipes conversation history but keeps the code changes already made. A commonly cited target is keeping context utilization around 60%, comfortably under the roughly 80% threshold where Claude Code’s auto-compact kicks in — check in every 30–45 minutes of active work. Anything that has to survive a compaction (architectural decisions, non-obvious constraints) belongs in CLAUDE.md or another file that gets deterministically re-read, not left to a lossy auto-summary.
2. Let prompt caching actually work for you. Claude Code caches automatically when a session resends the same context prefix, and cached input tokens are billed at roughly 10% of base price — for most rate-limit purposes they also don’t count against per-minute input-token limits. The practical rule: keep stable content (system instructions, CLAUDE.md, background context) at the very start of the prompt, and don’t let gaps between messages exceed the cache TTL — 1 hour on a subscription plan, dropping to just 5 minutes once a session is drawing on metered API credits. Miss that window and the next message reprocesses the full context at full cost.
3. Switch models for routine work. Drop from Opus to Sonnet for anything that doesn’t need Opus-level reasoning. On Max, this conserves the separate, smaller Opus weekly bucket; on Pro, it slows how fast you drain the one shared pool.
4. Move to API pay-as-you-go billing. Metered API billing removes the session-based 5-hour and weekly caps in favor of per-token pricing with standard tier-based rate limits. Useful for teams or automation pipelines that need predictable throughput rather than a subscription’s flat ceiling — at the cost of variable spend that needs its own monitoring.
5. Build a multi-tool bench instead of one hard stop. Rather than treating Claude Code as the only option, pair it with something else and switch based on task shape: Claude Code for complex multi-file refactoring, Gemini CLI when a task needs an entire large monorepo in context, Codex CLI for intent-driven single-file work. our AI coding assistant comparison breaks down how these tools stack up outside of the rate-limit question, and our Cursor vs Copilot comparison is a useful reference if Claude Code isn’t your only editor-integrated tool. This isn’t a hack so much as a resilience strategy — a rate-limited tool becomes an inconvenience, not a dead stop, if something else can pick up the task. If you’re hitting limits constantly because of heavy, repetitive automation rather than interactive coding, it’s also worth asking whether a self-hosted open-weight model on your own GPU makes more sense for that specific workload — our guide to self-hosting a coding assistant on a Vultr GPU instance walks through what that setup actually costs.
6. Multi-account switching — use with real caution. Running claude logout then claude login with a different account gives you that account’s independent usage window. Developers do this in practice, and Anthropic has an open GitHub feature request (#34341) to formalize automatic rate-limit failover across profiles. But this is explicitly not an officially sanctioned workflow, and a more aggressive version — using anti-detect browsers to run multiple accounts in parallel — technically violates Anthropic’s Terms of Service, even if enforcement is unclear. Know what you’re trading before you lean on it.
Which Workaround Should You Actually Use?
If you only do one thing, do context hygiene — it’s free, it’s low-risk, and it’s the single biggest lever most developers haven’t touched. Pair it with an honest MCP server audit: disconnect anything you haven’t used this week, since that’s the fastest way to claw back context you didn’t know you were spending. If you’re a solo developer on Pro hitting walls mid-session, model switching (Sonnet over Opus for routine work) buys the most runway for the least effort. If you’re running Claude Code inside automation or CI where predictable throughput matters more than flat pricing, API billing is the more defensible move than stacking accounts. Save multi-account switching for genuine emergencies, not as a standing workflow — it’s the one option here with real ToS exposure.
FAQ: Claude Code Rate Limits
Why did Claude Code start hitting rate limits so much faster in 2026?
A prompt-caching bug introduced in March 2026 caused some sessions to drain usage limits 10x to 20x faster than intended, compounded by weekday peak-hour throttling that Anthropic added around the same time. Anthropic acknowledged the issue publicly, reset usage limits in April, and made a permanent fix — doubling 5-hour limits and removing peak-hour throttling — on May 6, 2026.
Do MCP servers really affect my Claude Code rate limits?
Yes. Every connected MCP server registers its tool definitions into context on every turn, whether or not the tools get used. A documented case showed seven MCP servers consuming 33.7% of a 200K context window before any user message was sent — that’s context (and quota) spent before you’ve typed a word.
Does Claude Code prompt caching help with rate limits?
Yes, indirectly. Cached input tokens cost roughly 10% of standard input pricing and, for most rate-limit purposes, don’t count against per-minute input-token limits. The catch is the cache TTL — 1 hour on subscription plans, 5 minutes on API credits — so sessions with long gaps between messages lose the benefit.
Is switching Claude accounts to dodge rate limits against the rules?
Anthropic hasn’t officially sanctioned multi-account switching for rate-limit purposes, even though it’s a known community workaround with an open GitHub feature request to formalize it. Using anti-detect browsers to run multiple accounts in parallel goes further and technically violates Anthropic’s Terms of Service. Treat it as a last resort, not a standing habit.
Should I switch from Claude Code to another AI coding tool because of rate limits?
Not necessarily as a replacement — as a backup. Developers increasingly run a multi-tool bench (Claude Code, Cursor, Codex CLI, Gemini CLI) and switch based on task shape rather than picking one tool exclusively. That way a rate-limited tool is a minor inconvenience instead of a hard stop on your workday.
Final Verdict: Fix Your Habits Before You Fix Your Plan
Claude Code rate limits got a real, permanent improvement on May 6, 2026 — the 5-hour windows doubled, and the peak-hour penalty is gone. But a bigger plan alone won’t fix a rate-limit problem that’s actually a context-management problem. If you’re hitting walls regularly, audit your MCP servers before you reach for your wallet: a handful of unused ones can cost you more context than an entire coding session. Run /compact and /clear deliberately instead of letting sessions bloat for hours, and save Opus for the work that actually needs it. Only after those habits are in place does upgrading plans or switching to API billing start to make sense — and if Claude Code still isn’t enough on its own, pairing it with a second tool is a more sustainable fix than stacking accounts.
