[FEATURE] Auto-continue after subscription rate limit resets

[cheapestinference]

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:

• [FEATURE] Continue when the session limit reached #13354 (41+ upvotes, primary tracking issue)
• [FEATURE] Implement an "Auto-continue once limit resets" operation to /rate-limit-options #26789 (closed as dup)
• [FEATURE] Auto-continue after the limit is reset #18980 (closed as dup)
• [FEATURE] Better “Stop and wait for limit to reset” #28484 (better "stop and wait" behavior)
• [BUG] Claude does not continue after "Claude usage limit reached. Your limit will reset at 2pm (America/New_York)" #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 install

How 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 --print mode (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:

1. When rate limit is hit, show the reset time (already done)
2. Add an "Auto-continue when limit resets" option to /rate-limit-options
3. Claude Code sleeps internally until the reset time + margin
4. 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)

[kachebb]

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!

[dsecareanu]

What do you want to do?

❯ 1. Stop and wait for limit to reset
2. Add funds to continue with extra usage
3. Upgrade your plan

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).

[cheapestinference]

Yep that would be perfect El El lun, 30 mar 2026 a las 12:08, Daniel Secareanu < ***@***.***> escribió:

…

*dsecareanu* left a comment (anthropics/claude-code#35744) <#35744 (comment)> What do you want to do? ❯ 1. Stop and wait for limit to reset 2. Add funds to continue with extra usage 3. Upgrade your plan 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). — Reply to this email directly, view it on GitHub <#35744?email_source=notifications&email_token=BZFGPDPOUWNVECXFHBNGES34TJBS7A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIMJVGM4DEMRXHA32M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-4153822787>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BZFGPDM26NAWXZXLGQMFZ334TJBS7AVCNFSM6AAAAACWWJSSKKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DCNJTHAZDENZYG4> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[Venelinhr]

Great!

[krMaynard]

This would be great to have!

[Keesan12]

+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:

• what was in flight when the limit hit
• whether the last turn actually changed state
• why another attempt is justified
• a small retry budget for the resumed turn

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.