On September 25 the official @ClaudeDevs account posted a change that a lot of Pro and Max subscribers had been asking for since spring: Claude Code will now try to find a graceful stopping point when you hit your 5-hour limit mid-task, instead of cutting off mid-edit. It gets a small, fixed allowance pulled from your weekly limit to wrap up what it can. If you need to keep going past the wrap-up, you continue with extra usage, paid on top.
The rollout is staged. Pro plans get the wrap-up once a week. Max and Team Premium plans get it every time a 5-hour session limit is hit. That tier split matters more than it looks, and I'll come back to it.
What the hard cut actually looked like
Before this change, hitting the wall mid-task was brutal in a specific way. The session locked with a 429, and the message told you the problem and the price in one line: "Request rejected (429) · Extra usage is required for long context requests." That quote is from issue #56978 on the Claude Code repo, filed by a Max user running 1M-context Opus.
The thread documents the failure mode in detail. One reproduction happened on Sonnet 4.6 with a 1M context window at roughly 27% context used, during a long HTML editing session. The session had run for hours, no warning fired, and then every request died. No context export, no compaction offer, not even read-only access to the history. Decisions made, approaches explored, work in progress, all locked behind a paywall or lost.
That issue lists four asks: warn before the limit, allow a context export at the limit, allow compaction to fit remaining quota, and at minimum keep the history readable. The wrap-up feature is a partial answer to the first and second asks, delivered at the platform level.
What Anthropic didn't specify
Three things are officially unspecified, and coverage of the announcement picked at all three.
First, the size of the "small, fixed allowance" is unknown. Nobody outside Anthropic can say whether it is measured in tokens or in wall-clock time, or how much weekly quota it eats per wrap-up.
Second, because the allowance is carved from your weekly limit, a tight weekly budget now runs out slightly sooner if you lean on wrap-ups. The meter did not get bigger, the failure moment got softer.
Third, Pro's once-a-week cap leaves the second and third wall of a heavy week completely unprotected. If you hit the 5-hour limit twice in a week on Pro, the second hit is the old hard cut again. Timing matters: schedule the work most likely to get chopped for a moment when quota is plentiful, and don't count on the wrap-up as a backstop.
For background on the quota itself: Anthropic doubled the 5-hour limit on May 6 and added a temporary 50% weekly boost, later extended through September 14. From September 14 the weekly quota settled at 25% above the old baseline, which is about a sixth less than the boost period gave you. The September developer blog put it plainly: "Five-hour limits went up on Pro, Max, Team and seat-based Enterprise plans."
What a wrap-up window can't reconstruct
Here's the part I care about as someone who writes agent configs. The wrap-up finishes the current edit. It does not write your handover.
When the window closes, the next session still starts without your decisions, your dead ends, or your task state, unless something wrote them down. That is a different problem from the 429, and it's the one issue #38898 has been tracking since March: persist session memory at the cutoff, save a checkpoint file, warn, and offer resume. The platform now handles a slice of that. The rest is still your config's job.
This is the same lesson we keep relearning with compaction: what survives a session boundary is what someone explicitly serialized. I tested this directly when writing about what agents remember after a handoff, and the honest summary is that implicit memory survives almost nothing.
The checkpoint hook you can write today
You don't have to wait for Anthropic to ship checkpointing. The pattern sketch in the #38898 thread is a Stop hook that dumps session state to a file, plus a SessionStart-side restore. The core of it:
{
"hooks": {
"Stop": [{
"hooks": [{
"type": "command",
"command": "bash ~/.claude/hooks/checkpoint.sh"
}]
}]
}
}
And the script, trimmed to the parts that matter:
#!/usr/bin/env bash
INPUT=$(cat)
REASON=$(echo "$INPUT" | jq -r '.stop_reason // "unknown"')
DIR="$HOME/.claude/session-checkpoints"
mkdir -p "$DIR"
jq -n \
--arg reason "$REASON" \
--arg dir "$(pwd)" \
--arg branch "$(git branch --show-current 2>/dev/null)" \
--arg time "$(date -Iseconds)" \
--arg status "$(git status --porcelain 2>/dev/null | head -20)" \
'{reason:$reason, directory:$dir, branch:$branch, time:$time, uncommitted:$status}' \
> "$DIR/$(date +%Y%m%d-%H%M%S).json"
Every normal stop writes a checkpoint, so a limit hit just means the latest checkpoint is the recovery point. It costs a few kilobytes per session. On resume, read the newest checkpoint back in as context. It's not fancy, and it doesn't capture in-flight reasoning, but it captures directory, branch, uncommitted files, and stop reason, which is most of what I actually need to restart.
The one caveat: hook input fields like stop_reason are not a stable public contract. Anything you build on them can break on an upgrade, so keep the checkpoint script dumb and version-tolerant, and test it after major version bumps.
Watching the meter before it matters
The other half of the problem is visibility. /usage in Claude Code now shows a real breakdown: recent usage attributed to skills, subagents, plugins, and individual MCP servers, each as a percentage of the total, with an MCP server's share counting only requests that actually consumed its tool results. Behavior flags call out long context and cache misses once one of them accounts for 10% or more of recent usage. That attribution data is what tells you which part of your setup is eating the 5-hour window.
What's still missing is quota data in the statusline JSON. Issue #28999 documents ten duplicate feature requests from January through March, all asking for the same plumbing: pipe the 5-hour and weekly numbers that /usage already displays into the statusLine payload. The community workaround is a script that polls the undocumented OAuth usage endpoint with a 5-minute cache. It works, and it's exactly the kind of thing that breaks without warning, because the endpoint is unsupported.
My own habit is dumber and more durable: run /usage before starting anything you expect to run long, and treat the check as part of the task, not an interruption.
What this means for your agent config
The platform got gentler, and your config should get more explicit. Three concrete moves:
- Add an end-of-session protocol to your rules file: what to write when a session is ending, where the handoff notes live, what state the next session needs. The wrap-up window makes the edit land, your rules decide whether the knowledge lands.
- Keep the checkpoint hook cheap and automatic, so the boundary costs you nothing on good days and saves you on bad ones. This is the same state-file discipline that keeps parallel agents from corrupting each other's work.
- Know your burn pattern. With Opus 5.5 now the default on Pro and Team Standard, context-heavy sessions eat windows faster than most people adjusted for yet, a shift I measured when the default flipped.
If you want a starting point, the kits in AgentConfig Studio ($29) ship with a session-handoff protocol and versioned rules files, which is the layer this change makes relevant.
The September 25 wrap-up is Anthropic catching up to a request users filed in March. It softens the wall. It doesn't remember anything for you.
Top comments (0)