Claude Code's limit message is a branch signal, not automatically a bug or proof that your plan is too small. Preserve the current task state, run /usage for the named quota and reset time, then run /status if the active credential or billing route is unclear. If the branch points to a subscription cap, wait or use usage credits only after you know what reset you are buying around; if it points to an API key, treat the next failure as API billing or provider rate limiting until proven otherwise. The May 6, 2026 Anthropic update doubled five-hour Claude Code limits for Pro, Max, Team, and seat-based Enterprise and removed Pro/Max peak-hour reductions, so older March advice about peak-hour drain should now be treated as historical context, not the first fix.
Start Here: The First Five Minutes
When the session stops, resist the impulse to clear context, retry a dozen times, or upgrade before you know which branch you are in. The fastest safe path is a small incident-response loop: save what Claude Code was doing, read the exact limit surface, verify the active route, then choose the least destructive continuation.

Run /usage first. Anthropic's current Claude Code limits documentation says that command shows plan limits and reset information for subscription usage. If it names a reset window, you are probably dealing with a plan, weekly, or model-specific quota branch. If the message looks like an API rate limit or billing failure, run /status and confirm whether Claude Code is authenticated through the subscription path or through an API key.
The second command matters because Claude Code can be routed differently from what you think. Anthropic's environment-variable help notes that ANTHROPIC_API_KEY can make Claude Code use API billing instead of subscription entitlement. In that branch, the next failure belongs closer to API billing, provider limits, or concurrency than to the Claude subscription meter. For API 429 recovery, the separate Claude API 429 troubleshooting page is a better branch once you have confirmed the API route.
Use this quick split before doing anything irreversible:
| If the evidence says... | You are probably in... | Safe next move |
|---|---|---|
/usage shows a named reset time | subscription quota or model cap | wait, switch model if acceptable, or use credits only after checking the reset |
/status shows API-key auth | API billing or provider rate branch | inspect key, project, credit, and request pattern |
| status page or error text shows service trouble | temporary service branch | wait, retry later, collect timestamp if persistent |
| the session is huge or tool output is heavy | context-pressure branch | save state, compact or start a new focused session |
| billing screen or command mentions credits | usage-credit branch | add credits only if you intended that paid route |
This sequence protects two things at once: your current coding task and your bill. Clearing context too early can lose useful state. Buying capacity too early can mask an auth-route problem. Retrying too aggressively can waste time during a temporary throttle.
What The Message Can Mean
The phrase "limit reached" is not one official product state. It can be a plan allowance, a rolling window, a weekly allowance, a model-specific cap, an API rate limit, a low-credit state, a temporary server throttle, or a context-size problem that makes each turn heavier than expected. The exact recovery path depends on the branch.
Anthropic's Claude Code usage page, checked on May 24, 2026, describes plan usage as variable by plan, model, features, conversation length, files, and project complexity. It also states that Claude Code can show remaining plan usage and reset timing through /usage. The broader Claude usage-limit help page makes the same principle clear for Claude plans: limits are not a fixed public token number that applies identically to every session.
That is why a single "how do I remove the limit" answer is dangerous. A developer who has hit a model-specific cap may be able to switch to another model and continue. A developer who has hit the weekly allowance needs planning, not repeated retries. A developer accidentally routed through ANTHROPIC_API_KEY may need to remove or replace the environment variable. A developer hitting API 429s needs request-level debugging rather than subscription advice.
The most useful mental model is branch plus proof:
| Branch | Proof to collect | What it changes |
|---|---|---|
| Five-hour or rolling usage window | /usage reset time | waiting or credits may apply |
| Weekly allowance | /usage weekly meter or plan screen | plan workload and model mix matter |
| Model-specific cap | command or plan surface naming the model | switch model if quality tradeoff is acceptable |
| API route | /status, environment variables, API-key config | subscription allowance may not be the owner |
| Low usage credits | /usage-credits or billing surface | add funds only for the API/credit route |
| Temporary throttle or outage | error text plus status check | wait, retry conservatively, keep evidence |
| Context pressure | large conversation, files, tool output, context warning | compact or start a new focused session after saving state |
The May 6 Update Changed The Old Peak-Hour Story
Older coverage of Claude Code limits often centers March 2026 peak-hour reductions. That advice is no longer a safe first answer. On May 6, 2026, Anthropic announced higher Claude Code usage limits and said it doubled five-hour limits for Pro, Max, Team, and seat-based Enterprise users. The same announcement said peak-time limit reductions for Pro and Max Claude Code users were removed.
That does not mean limits disappeared. It means the most useful first move shifted. The current recovery path should begin with /usage, /status, reset timing, model branch, billing route, and context pressure. Peak-hour history can still explain why many developers remember sudden March drain, but it should not override current command evidence.
The official update also does not give every reader an exact fixed public cap. Anthropic still frames usage as plan-dependent and workload-dependent. A short chat and a codebase session are not equivalent. A session with large file reads, long tool outputs, project instructions, and higher-cost models can hit a limit much sooner than a lightweight prompt session even after the May update.
Use dated language for any policy claim. A fair current sentence is: "As of May 24, 2026, Anthropic's May 6 announcement says five-hour Claude Code limits were doubled for Pro, Max, Team, and seat-based Enterprise, and Pro/Max peak-hour reductions were removed." A weaker sentence is: "Claude Code no longer has peak-hour limits" because that overgeneralizes beyond the specific official wording.
Run The Checks In This Order

The first command is /usage because it tells you whether the limit belongs to the subscription meter and, when available, when that meter resets. Record the exact wording and reset time. A screenshot is useful if you later need support, but do not spend the next half hour documenting before preserving the work.
The second command is /status when the branch is not obvious. That command helps confirm the active authentication state. If Claude Code is using an API key, a subscription-plan explanation may be the wrong owner. Check your shell, project, and CI environment for ANTHROPIC_API_KEY. A globally exported key can surprise you in a local terminal. A project-level setting can surprise a teammate who expected subscription auth.
The third check is /usage-credits if the interface points toward additional paid usage. Anthropic's Claude Code docs describe usage credits as a way to continue after included usage is exhausted, with separate behavior from ordinary plan allowance. Treat credits as a paid continuation route, not as proof that your subscription failed. Add them only after you know the branch and the reset window.
The fourth check is context size. Claude Code sessions can become expensive because the conversation carries prior instructions, tool results, files, and decisions. If the session has been reading large logs, generated files, or long command outputs, the limit may be real even if your latest prompt was short. Save the current task summary, commit or stash relevant changes if appropriate, and then decide whether /compact or a fresh focused session is safer.
The fifth check is service status or error-family text. The Claude Code error reference separates usage limits, authentication failures, rate limits, network problems, policy refusals, and server errors. If the visible error is closer to rate_limit_error, api_error, authentication failure, or network failure, follow that branch instead of treating every stop as a subscription quota event.
Which Next Action Is Safest?

Once you know the branch, the continuation choice is usually straightforward. The hard part is not the action itself; it is avoiding the action that solves a different problem.
If /usage gives a near reset time, waiting is often the cleanest fix. Before you wait, ask Claude Code to summarize the current task state into a short handoff note if the session still accepts input. If the session is fully blocked, write a human note with the file paths, failing command, last useful plan, and next intended step. That note makes the resumed session cheaper and safer.
If the branch is model-specific, switching models can be reasonable. Do it only when the task can tolerate the quality or behavior change. A codebase-wide migration, security-sensitive refactor, or subtle debugging task may be better paused than completed with the wrong model. A simple doc edit, test update, or repetitive cleanup can often continue on a lighter model.
If the branch is context pressure, compact or start fresh after preserving state. The stop rule is important: do not clear the session before extracting the task goal, files touched, commands run, current failure, and pending decision. A fresh session with a clean task brief often works better than a long session carrying every earlier detour.
If the branch is usage credits, use them only when you understand the billing route. Credits are useful when the work is time-sensitive and the reset is too far away. They are a poor fix when an accidental API key, failing billing setup, or temporary server branch is the real cause.
If the branch is API billing or provider rate limiting, move into API diagnostics. Check key ownership, workspace, project limits, concurrency, retry behavior, and request shape. The Claude API 429 page covers that branch more directly because API limits are request-level and billing-level problems, not just Claude Code session problems.
If the branch looks like account suspension or disabled organization rather than usage, stop changing usage settings and preserve account evidence. The sibling Claude Code ban and refund page separates suspension, disabled organization, login, support, and refund routes. Usage-limit recovery and enforcement recovery should not be mixed.
Why Long Coding Sessions Still Hit Limits Fast
Even after the May 6 update, long coding sessions can drain faster than a developer expects. That is not necessarily a bug. Code work naturally creates heavy context: project instructions, file reads, diffs, command output, stack traces, dependency logs, test failures, and repeated plan revisions.
The latest prompt may be short, but the request is not only the latest prompt. The model often needs prior conversation, files, tool outputs, and system instructions to maintain continuity. A session that has read ten large files can become expensive even when the next human message says "continue". A session that has pasted long terminal output can become expensive even when the next action is small.
Three patterns cause most avoidable pressure:
| Pattern | Why it hurts | Better habit |
|---|---|---|
| Long multi-topic sessions | every new task inherits old context | split unrelated tasks into new sessions |
| Large unfiltered file reads | every turn carries too much reference material | ask for targeted files, symbols, or ranges |
| Repeated failing commands | logs accumulate without changing the branch | summarize the failure, then change one variable |
| Bloated project instructions | every session starts with unnecessary background | keep always-loaded instructions short |
| Tool-output dumping | huge output becomes part of the work history | save logs to files and quote only decisive lines |
This is also why a plan upgrade alone may not solve the problem. More allowance helps, but inefficient context still burns through it. A cleaner session shape can make Pro or Max feel materially different without changing the plan. For lower-cost route planning, the Claude Code pricing and lower-cost options page can help after the active interruption is resolved.
Prevention: Build A Lower-Interruption Workflow

The best prevention stack is boring: smaller task scopes, clearer handoffs, explicit reset awareness, and fewer accidental billing routes. You do not need to optimize every token; you need to keep each session from becoming a large, ambiguous bundle of old work.
Start each substantial coding task with a compact task card:
mdGoal: - Fix the failing checkout test without changing payment behavior. Relevant files: - app/checkout/actions.ts - app/checkout/actions.test.ts Known state: - test fails on expired coupon branch - no schema migration expected Stop rule: - ask before changing billing or auth logic
That task card reduces exploratory context and gives a future fresh session enough continuity. If the task grows beyond the card, update the card rather than leaving all reasoning buried inside the conversation.
Keep a reset habit. When /usage shows a reset time, write it down near the task plan if the work matters. If the weekly allowance is the bottleneck, batch deep codebase work around periods when you can afford it and use lighter sessions for doc, review, or test triage. If a model cap is the bottleneck, decide which tasks truly need that model.
Keep auth explicit. If you use both subscription and API routes, make the route visible in your shell profile, project README, or task script. Do not let ANTHROPIC_API_KEY sit silently in every terminal if you sometimes expect subscription usage. In team environments, document whether Claude Code work is supposed to consume personal plan allowance, team plan allowance, usage credits, or direct API spend.
Use /compact as a controlled tool, not a panic button. Compact after a logical milestone, after saving the handoff state, or before entering a new subtask. Do not compact immediately after a confusing failure if the missing details are still needed to debug.
When To Upgrade, Use Credits, Or Switch To API
Plan and billing choices should come after branch proof. If the problem is a near reset, waiting may be cheaper than paying. If the problem is repeated weekly exhaustion on normal work, a higher plan or team plan may make sense. If the problem is programmatic or multi-agent API traffic, subscription allowance may be the wrong contract entirely.
Use this route test:
| Need | Better route | Watch out for |
|---|---|---|
| Finish one urgent blocked task | wait, credits, or short API route after proof | accidental spend if auth route is unclear |
| Sustained personal Claude Code work | plan upgrade or better session hygiene | no fixed public cap applies to every workload |
| Team coding work | Team or Enterprise plan with shared policy | seat ownership and usage visibility |
| Automated API workload | API route with project-level limits | 429 handling, budget caps, and retries |
| Debug one API limit error | API diagnostics | subscription quota advice may not apply |
Do not treat third-party gateways or subscription workarounds as default fixes for Claude Code limits. They can be useful for specific API/developer jobs only when their current model coverage, billing behavior, limits, support, and failure rules have been verified. For the active Claude Code limit message, the official branch proof should come first.
FAQ
Why did Claude Code stop when I barely typed anything?
The latest message may be short while the session context is large. File reads, logs, prior tool outputs, project instructions, and conversation history can make the next request much heavier than it looks. Run /usage, inspect context pressure, and decide whether a saved handoff plus fresh session is safer.
Does the May 6 update mean peak-hour advice is obsolete?
Older March peak-hour advice should be treated as historical context for Pro and Max Claude Code users. Anthropic's May 6, 2026 announcement said Pro/Max peak-hour limit reductions for Claude Code were removed and five-hour limits were doubled for Pro, Max, Team, and seat-based Enterprise. Limits still exist, and /usage remains the safer source for the active reset branch.
Should I clear context immediately?
No. First preserve the current task state: files, commands, last useful decision, current failure, and next intended step. Then compact or start fresh if the branch points to context pressure. Clearing too early can make the recovery slower and less accurate.
When should I use usage credits?
Use credits when /usage or the billing surface proves the included usage branch and the work is worth continuing before reset. Do not add credits to solve an accidental API-key route, an outage, a context-length problem, or a support/enforcement branch.
How do I know whether Claude Code is using API billing?
Run /status and inspect environment variables such as ANTHROPIC_API_KEY. Anthropic's Claude Code API-key documentation says that environment variable can configure Claude Code for API use. If the API key route is active, troubleshoot key ownership, project billing, provider limits, and API errors instead of assuming subscription quota.
Is surprising quota drain an official bug?
Treat it as unproven until branch checks rule out normal quota, model cap, API route, temporary throttle, and context pressure. Community reports can show that the symptom is common, but official docs and current command output should own the recovery decision. If the numbers still look impossible after branch proof, collect timestamps, screenshots, command output, and status evidence before contacting support.
Can a plan upgrade fix the problem?
Sometimes. A higher plan can help if you repeatedly exhaust normal subscription allowance on legitimate work. It will not fix an accidental API key, inefficient context, service trouble, or a wrong model choice. Upgrade only after the branch explains why more included usage is the actual missing resource.
What should I keep for support?
Keep the exact message, timestamp, /usage output, /status output, active model, whether ANTHROPIC_API_KEY was set, the reset time shown, and a short description of the task. If the problem looks like API 429, include request IDs and provider/project details. If it looks like account suspension, preserve account and billing evidence before changing settings.
Current Official References Checked
- Models, usage, and limits in Claude Code, checked May 24, 2026.
- How do usage and length limits work?, checked May 24, 2026.
- Use Claude Code with your Pro or Max plan, checked May 24, 2026.
- Manage API key environment variables in Claude Code, checked May 24, 2026.
- Manage usage credits for paid Claude plans, checked May 24, 2026.
- Claude Code error reference, checked May 24, 2026.
- Higher usage limits for Claude, published May 6, 2026 and checked May 24, 2026.
