Claude Code · Usage guides

Claude Code Limit Reached: Identify the Limit and Resume Work

Distinguish Claude Code context, subscription usage and request-rate limits; check the right interface, preserve work and choose a supported recovery option.

Claude

The quick answer

First run /status to confirm the account and authentication method. Then distinguish conversation size, subscription allowance and temporary request throttling: they require different recovery steps. The branches below paraphrase the official error reference.

Conversation context is too large

Message excerpt in English: Prompt is too long.

Check /context for the current conversation breakdown. Save important constraints, then use /compact to continue the task or /clear to start an unrelated one. If a single large input cannot be compacted, shorten that input. Verify the next request fits; this does not restore account allowance. See context, clearing and caching for the comparison and examples.

A subscription window is exhausted

Message excerpt in English: You've hit your session limit.

Use /usage or Claude Settings → Usage to identify the session, weekly or model-family window named by the limit. Record its reset date and time zone. Save changes and unfinished work before waiting. Changing models only helps when the alternative is available and the shared windows still have allowance.

At the stated time, recheck the official usage display and try a small next step. A local countdown ending is not evidence of recovery. See window timing and supported automatic waiting.

Requests are temporarily throttled or return 429

Message excerpt in English: Server is temporarily limiting requests / Request rejected (429).

A short-lived server throttle is not proof that subscription allowance is exhausted. Let the client's retry finish, wait briefly and check Claude service status if it persists. Verify that a subsequent request succeeds; clearing context is not the treatment for a server throttle.

For an API or provider rate limit, check /status and the active provider console. Confirm the expected credential is in use, reduce parallel requests, and respect any retry delay. If the restriction persists, review the provider's limits. A successful retry confirms that request could run; it does not refill a subscription window.

Paid continuation and spending limits

If the message concerns a spending cap or credit balance, inspect the billing account named by /status and the relevant usage or billing page. An administrator may need to authorize more spending. Raising a cap or buying credits can cost money; waiting only helps when the displayed restriction has an applicable reset. Confirm the account shows capacity before resuming.

For paid capacity, /usage-credits lets Pro/Max users buy additional usage and Team/Enterprise users request it from an admin. Confirm pricing, spending controls and account eligibility first. API-key access uses separate API billing and applicable limits; it does not refill subscription allowance. Neither option is a free reset. See official paid-plan options.