[FEATURE] Auto-continue after subscription rate limit resets
Problem
When Claude Code hits the subscription usage limit ("5-hour limit reached - resets 3pm"), the session pauses and the user must manually wait and type "continue" to resume. For long-running tasks (overnight work, AFK coding), this kills productivity.
This has been reported multiple times:
- #13354 (41+ upvotes, primary tracking issue)
- #26789 (closed as dup)
- #18980 (closed as dup)
- #28484 (better "stop and wait" behavior)
- #5977 (context loss after usage limit)
Community Solution
I built an open-source tool that solves this today:
npm i -g claude-auto-retry
claude-auto-retry installHow it works: Intercepts the claude command transparently via a shell function, monitors the tmux pane for rate limit messages, waits for the reset time (timezone-aware), and sends "continue" automatically via tmux send-keys.
- Zero dependencies, zero workflow change
- Works with and without tmux (auto-creates session if needed)
- Verifies Claude is still the foreground process before sending keys
- Supports
--printmode (buffers + retries for piped usage) - 59 tests, MIT licensed
Repo: https://github.com/cheapestinference/claude-auto-retry
npm: https://www.npmjs.com/package/claude-auto-retry
Suggested Native Fix
While the community tool works, this behavior should be built directly into Claude Code:
- When rate limit is hit, show the reset time (already done)
- Add an "Auto-continue when limit resets" option to
/rate-limit-options - Claude Code sleeps internally until the reset time + margin
- Automatically resumes the conversation — no tmux, no wrapper, no external tool
This would be a much cleaner UX since Claude Code already knows the reset time from the API response and can handle the retry internally without needing terminal monitoring.
Environment
- Claude Code 2.1.x
- Anthropic Pro/Max subscription
- All platforms (Linux, macOS)
Showing cached comments. Read the full discussion on GitHub ↗
14 Comments
I have a workaround by scheduling claude to resume the session and continue at the limit reset time.
The solution is described at
https://gist.github.com/kachebb/307c8faa101ff980ac0013c465870b1c
Hopefully it helps!
What do you want to do?
❯ 1. Stop and wait for limit to reset
Enter to confirm · Esc to cancel
Replace option 1 with 2, 2 with 3, and add an option 3 to resume once the rate limit has expired (which could be automatically triggered to solve the issue raised by multiple other users).
Yep that would be perfect
El El lun, 30 mar 2026 a las 12:08, Daniel Secareanu <
@.***> escribió:
Great!
This would be great to have!
+1 on auto-continue, but I think it needs one more guardrail to be genuinely useful: resume should not be blind.
The frustrating case is when the limit resets, the session wakes up, and the next turn just replays the same bad retry pattern that burned the budget in the first place. In practice I would want the client to resume with a tiny receipt:
Auto-wake without that context is still better than manually typing continue, but auto-wake plus a receipt is what turns it into an operator feature instead of a convenience feature.
Related community angle on the same pain: proactive pause before 100%, not only auto-continue after.
On long Fable 5 / subagent runs, chat messages can queue — so "slow down at 90%" never lands in time, and extra usage can keep burning after 100%. I made a small macOS tool that arms at session start (
/usage-guard), watches the 5h window externally, and checkpoints + resumes after reset: https://github.com/shirley-xue-2025/usage-guardmacOS only for now.
I hacked around a solution that I thought wasn't so hard to bake into the Claude code.
NO tmx, no OS hack, just Claude code native, and simple.
https://github.com/softcane/cc-session-recover
Another community option for anyone landing here from long AFK runs.
I kept hitting this on the Claude desktop app, not just the CLI, so I built claude-ac. Two things I wanted and couldn't find elsewhere: (a) it covers the desktop app, not only tmux/terminal — it clicks the real resume button via Windows UI Automation / the macOS Accessibility API; (b) a check-up that lists your paused sessions split by Chat / Cowork / Code, so resume isn't blind — you wake only the ones worth continuing instead of replaying everything (addresses @Keesan12's point above).
Three modes: one-click resume, opt-in auto-resume that waits for the reset and fires on its own, and a CLI wrapper that detects the limit in the output and relaunches with --continue.
Honest caveat: Claude doesn't emit a Stop event when credits run out, so the desktop resume goes through UI Automation rather than a hook. No telemetry, no open ports, never triggers purchases or upgrades. MIT.
https://github.com/blackstardigitalstudio/claude-auto-continue
Fully agree the clean answer is native — an "auto-continue when the limit resets" option in /rate-limit-options would beat any external wrapper.
@cheapestinference: another issue for "This has been reported multiple times": #6254.
Another native option: cc-workflow-nudge is a Claude Code plugin (a PreToolUse hook plus a skill) that arms when a big Workflow starts, reads your 5-hour window's reset time, and schedules a CronCreate task to continue the interrupted run in the same session, with no tmux and no send-keys. I scoped it to Workflows because those are the runs most likely to burn through a lot of tokens and hit the limit; if you just have a long single conversation you're worried about, you can trigger the skill by hand instead. On the "resume shouldn't be blind" concern raised above, it re-checks that the quota actually reset before continuing, and re-arms and waits if it hasn't, instead of burning the turn. As of v0.2 it reads the reset time from Claude Code's own status line data (no OAuth token, no unofficial API); the one real tradeoff left is that the schedule lives inside the CC session, so if CC crashes or you close it before reset nothing resumes, unlike the external watchers in this thread.
Repo (MIT): https://github.com/rrrrrrrrrricoxi/cc-workflow-nudge
Small follow-up: the feedback in this thread pushed a concrete fix in claude-ac, so thank you.
@Keesan12's "resume should not be blind" and @rrrrrrrrrricoxi's "re-check that the quota actually reset before continuing, and re-arm and wait if it hasn't" were exactly right for the message-send path (Claude Code, where there's no native resume button and you reactivate by sending a message). Sending consumes a real turn, so firing blindly at reset time can just replay the failed state.
v1.7.0 now verifies before it sends: it checks whether the limit is still active (native resume button present, or a "usage limit / resets at" banner still showing) and, if so, re-checks every 25s for up to ~6 min, only sending once the quota is actually back — otherwise it skips instead of burning the turn. The resume message is also no longer a blind "continue": it asks the session to first summarize what was in flight and what's left, then proceed.
Clicking the native resume button stays as-is, since that's safe (the app just re-shows the limit if credits aren't back yet).
Fully agree the clean answer is still native — an "auto-continue when the limit resets" option in the rate-limit prompt would beat any external wrapper.
Slightly different angle that's been working for me, since these threads are about not losing work to the reset: instead of resuming a blocked session, I queue the next pieces of work during the day and let them run overnight once limits reset, with reports waiting in the morning. Open-sourced it here if useful: https://github.com/rohanprichard/claude-overnight (mine).
Until this is built into the clients, I ended up making an open-source tool for it: unsnooze.
It tracks AI coding sessions that stop because of official usage limits (Claude Code, Codex, and several other CLIs), records the reset time from the actual limit event, and resumes the same session in tmux or Zellij when the quota resets.
It survives laptop sleep, never auto-approves anything, can optionally queue a prompt to run after resume, and manages multiple sessions across projects from a single daemon.
npm install -g unsnooze
MIT licensed: https://github.com/saaranshM/unsnooze