Graceful handling when hitting usage limits mid-session
Problem
When using Claude Code on the Max plan with 1M context models (Opus), hitting the usage limit mid-session completely locks the session with a 429 error: "Request rejected (429) · Extra usage is required for long context requests."
There is no way to:
- Save or export key context from the locked session
- Transfer context to a new session
- Compact the conversation to fit within remaining quota
- Even get a warning before hitting the limit
The session just stops working. All conversational context — decisions made, explored approaches, in-progress work — is lost unless you enable extra billing.
Requested improvements (any of these would help)
- Warn before hitting the limit — give users a chance to wrap up, save state, or commit work before the session locks
- Allow context export/summary — when the limit is hit, let the user extract a summary of key decisions, state, and progress that can be carried into a new session
- Allow compaction at the limit — instead of hard-blocking, offer to compact the session down to fit within remaining quota
- Don't hard-block the session — at minimum, allow read-only access to the conversation history so users can manually reconstruct context
Context
This is especially painful for users on the Max tier who are already paying for the highest available plan. Long sessions with large codebases and document work naturally accumulate context. Having the session die without warning or recovery options feels like a penalty for using the product as intended.
Showing cached comments. Read the full discussion on GitHub ↗
7 Comments
Reproducing again today on Sonnet 4.6 (1M context) — Pro Max plan
Hit the same 429 mid-session today:
Model:
claude-sonnet-4-6[1m](Sonnet 4.6, 1M context window)Plan: Pro Max
Context at time of error: ~27% used (approx. 270k/1M tokens) — well within the window
What was happening: A long HTML document editing session — repeatedly reading large files (30–40KB HTML), making targeted edits, running Playwright screenshots for visual QA, and doing several multi-step file rewrites. The session had been running for several hours. No warning was given before the error hit. The session simply stopped returning responses and locked with the 429.
The core frustration: At 27% context usage, there is no reason the session should be hitting a usage wall. The 1M context model is marketed as handling large, long-running sessions — but it's hitting limits that aren't visible or predictable. The suggestion that "extra usage is required" with no path to add it mid-session, no warning before it hits, and no way to save context from the locked session makes this unusable for serious work.
Adding a noise comment to prevent this from being closed.
Adding a noise comment to prevent this from being closed.
Adding a noise comment to prevent this from being closed.
Adding a noise comment to prevent this from being closed.
Adding a noise comment to prevent this from being closed.
+1, especially requested improvement #1 (warn before hitting the limit). One extension: beyond warning the user, give the agent the same signal so it can wrap up on its own — reach a safe stopping point, commit/checkpoint in-progress work, and pause — instead of being cut off mid-task.
#67754 proposes the underlying mechanism (expose session/weekly usage to the model + a threshold hook that fires before the cap); this issue is the user-facing behavior that mechanism would enable. Proactively pausing at a checkpoint before the wall directly addresses the lost-context problem described here.