[FEATURE] Continue when the session limit reached

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/12657
2. https://github.com/anthropics/claude-code/issues/3138
3. https://github.com/anthropics/claude-code/issues/12774

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

This is a feature request to ensure the session can continue when the session limit is no longer in effect, thus ensuring the task Claude Code was busy with can continue without losing the current context and state.

This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.

It's still occurring, and a solution would be appreciated. Thanks!

I don't think Anthropic _wants_ to implement this feature 😉

I would love this!

This would be very helpful

Just getting started with Claude Code yesterday and I want this already.

I don't think Anthropic _wants_ to implement this feature 😉

True, that would increase usage considerably, although the weekly / longer limits would still apply.

A script typing "Continue" and pressing enter, with a timestamp parameter is the solution right now

Please, please add this, very frustrating to kick off night jobs and come in the next morning with plenty of tokens available but no progress - am on a team (premium) subscriptions - and am being seriously hampered by this!

Need this! I'd like to queue up a bunch of tasks which can run while I'm sleeping when the session resets

Just started using Claude Pro and ran into this issue. I would love to see it implemented as well!

please do it.

Is there any ETA?

Menu item required: Wait for limit to reset and continue.

► 1. Wait for limit to reset and continue
  2. Stop and wait for limit to reset
  3. Switch to extra usage
  4. Upgrade your plan

<details>
<summary>Example</summary>

!Image

</details>

@aaurelions What version is this releasing with, could not get it to work even after claude --update?

@dhruvil009 I apologize, this is just an example, it is not in the release.

@aaurelions Please resist the urge to pollute using un-usefull, AI generated content.

@aaurelions Please resist the urge to pollute using un-usefull, AI generated content.

I showed clearly what the function should look like. When Anthropics LLM gets to this [FEATURE], it will read it and have a clear idea of the function.
A clear prompt with an example means correct implementation.

> @aaurelions Please resist the urge to pollute using un-usefull, AI generated content. I showed clearly what the function should look like. When Anthropics LLM gets to this [FEATURE], it will read it and have a clear idea of the function. A clear prompt with an example means correct implementation.

Sorry to disagree but I'll be straight.

Your first comment was shitty (not exploitable, not documented, misleading).
It didn't give any sense of what it was about. It didn't even said the basics, such as "this is a UI suggestion".

It felt like you just pasted a LLM-suggested answer without caring what actual humans (or LLMs) would deduce when reading it.

A proper suggestion should be documented, explained, and not be misleading.
AI makes us lazy, that's already proven, it's just one example of such occurence.
Nothing personal.

@Vadorequest I apologize for misleading the human race.

Please add the option to automatically continue after limit reset

To keep alive the thread: I am just waiting for this fix soon.

Are there other CLI tools?

It will be very nice if you add option continue on limit reset

+1 for this but in the Code tab of the Claude desktop app

Loosing a lot of credits because of this...

Until this gets built in, one thing that helps is knowing the limit is coming before it hits. I added a pace indicator to my statusline that shows whether I'm burning faster or slower than the window can sustain -- red -15% means I need to wrap up or switch models, green +20% means I have room.

It also shows a reset countdown so I know exactly when the window rolls over, which helps plan when to pick back up: https://github.com/Astro-Han/claude-lens

Its needed!

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!

Nice, and if using the desktop app or cloud session, and a plan file already exists, you can set a scheduled task to continue at the limit reset time by referring to that plan in the schedule prompt.

So I chose the option 1 Stop and wait for the limit to reset what is the function of this option , if it wont continue after session limits reset ? What brings seeing this option ? I already know I should wait . Do I oversee anything here ?

Can you add option continue on limit reset

When your world-changing software is nagware.

This will be super helpful to implement!

My current hacky workaround with v2.1.112:

1. Depending on your workflow and token usage velocity (hopefully estimable), have CC check the percentage token usage after each task.
2. Define a pause threshold, say 80%. Put that as a line item in your skills or use stop hook.
3. Tell it to take a break for x mins, if you can estimate your token depletion rate.

This is what CC did:

Taking a break. Pausing here; the research agent is running in the background and will finish on its own. I'll resume in 30 minutes and come back with a discussion response on your six points plus a draft copy informed by the research. Paused. Will resume at 00:41 (local) with the full discussion response + draft.

Having an automated "continue on limit reset" would be really useful for me. I am happy for claude to run at low load times for the claude servers e.g. over night, but to make that practical, I need to be able to kick off a job and have it auto-continue. Otherwise it does a bit of work while I'm asleep and then stops when it could have auto-restarted.

+1 to this, the headless-execution model which CC's pricing and interface seem to be largely designed around needs an auto-continue-on-tokens-available option to get a good UX, ideally with a configurable threshold so customers can keep some tokens in reserve for interactive usage.

Auto-continue would also spread out usage a bit server-side, rather than users planning sprint-periods all around similar time-frames since they have to be there when CC's limit resets, which has clearly been an issue for the backend team as well.

Loosing a lot of credits because of this...

Straight on point. Unless the agents need review from user, it should continue its task.

Even tho the source code got leaked, and within this month still no proper solution by anyone?
That means they don't care about it, cause you're spending more tokens.

Maybe.
Having run a software company, just because you can't implement something now, doesn't mean you don’t care about it. You have priorities and shareholder pressure that plays into it, as well as capacity constraints.
However in this case, there is a high possibility that overall profit is reduced if they implement this feature. But more than that, the overall perception of the product actually worsens if they implement it; if it ships, people will use it and avoid paying more to keep working now, the net perception change is that "Claude is good but it's slow because you keep awaiting limit resets", rather than potentially "I pay more when I hit limits, but it's worth it".
That's not going to be true for all users, but many, as much as I want this feature, if I were in their shoes, I wouldn't ship it.

the net perception change is that "Claude is good but it's slow because you keep awaiting limit resets", rather than potentially "I pay more when I hit limits, but it's worth it".

Honestly even if this was only enabled for Max usage, I'd be decently happy with it (though Anthropic would need to be a bit more transparent w.r.t. their compute and monetary constraints to market that properly). I'll definitely grant that the messaging gets _more_ tricky in this situation, though.

However in this case, there is a high possibility that overall profit is reduced if they implement this feature.

I currently haven't invested in workflows that could make use of Max-level compute _precisely because_ there's no use investing in long-running sessions when I anyway have to periodically check the machine for usage limits and then reset it once it reaches them. Same reason it took me months to get my life to a state where I could justify Pro's price-vs-usefulness. So anecdotally at least, this limitation is _costing_ Claude Code potential business, at least among those that will not be investing in "pay more to keep working now".

• I also expect most high-volume players running into usage limits would use multiple independent subscriptions and tmux wrappers to leverage the Pro/Max bundle-pricing rather than API-level pricing, significantly reducing the monetary value of _lacking_ headless execution without limit resets needing manual action (I haven't run the numbers, but pretty sure it's cheaper). Whether or not Anthropic's ToS specifically forbids this, people will be people regardless.

No idea how, but my session decided to solve this by itself. Will keep an eye in my next limit if happens - but was great feeling to have this restart! Or at least Claude not to give us human-in-loop options after limit goes in, that way we can schedule our own crons.

<img width="868" height="313" alt="Image" src="https://github.com/user-attachments/assets/a3d07b41-5a46-4034-a3f2-055ac01ef266" />

Still waiting for Anthropic to implement the _continue automatically when session time is reset/renewed_, so we don't need to babysit the claude in terminal. Amazon and Google are investing millions, I think the Anthropic will have all resources to make this happen.

@datagero do you have any skill or plugins that would continue execution?

Looks like my subagent was able to resume after hitting usage cap. I am 10~20 minutes away from the refresh though, so possibly the main agent triggered a nudge to that stuck subagent after some silence, which happened to go past that refresh threshold.

Wave 3 complete. All three Phase 6 tasks landed cleanly — picked up Task 15 directly after the subagent hit its usage cap mid-edit.

yes please implement this, it'd be nice if this would be implemented on the web version of the claude too!

Related, see also https://github.com/anthropics/claude-code/issues/56978

I use continue each time to start after a limit hit or new chat opening so for me it means after I hit a limit, begin after a pause, or have to start a new chat due to slowness.

I have to start another chat because it has become so unresponsive due to memory, an issue in itself.
so I have the Ai save to memory, update docs, update issues, changelog, commit, so that nothing is left in a bad state or forgot on new chat as this happens often.

Then in new chat it has to load many files, and its on memory, which counts toward my limit?
Sometimes my limits are waiting 2 hours others have been like four days. The fact that it hit a limit and just quits is another issue that needs to be addressed.

And when I come back, especially like the four day one it has totally forgotten where we at, even in same chat which it has access to read?

Today, after waiting two days and I type "continue" it actually tried to fix a github issue that was closed seven days ago....

I do not totally understand the limits nor do I want to, just letting me know I am getting close, and not stopping simple issue fix, leaving my code in a bad state, because of limit hit would be nice.

Also non peak hour use, a personal project (non-corporate use), should be treated differently in my opnion.

Adding a noise comment to prevent this from being closed.

Anthrooooooooopic

great idea

.

Please

pls this would be so useful!

the 'wait then resume' part holds. the reset timestamp doesn't, it's scraped from the limit message after the wall, not the server window.

the endpoint that returns the rolling-window reset as a real timestamp before you hit the wall: https://claude-meter.com/r/nu3s9esf

bump

An issue I have that is related to this: I know I have hit the limits but claude code hasn't realised that yet. Because the CLI wrapper hasn't caught the 429 rate-limit error yet, it is stuck in a loop cycling through its loading spinner verbs (like "Discombobulating..." or "Moonwalking...") while its internal timer keeps ticking but token count is frozen. 2 questions here: is it safe to allow this to continue? Will it progess when my limits refresh or am I better off killing the execution (Ctrl C)? Then continuing when my limits do refresh.

An issue I have that is related to this: I know I have hit the limits but claude code hasn't realised that yet. Because the CLI wrapper hasn't caught the 429 rate-limit error yet, it is stuck in a loop cycling through its loading spinner verbs (like "Discombobulating..." or "Moonwalking...") while its internal timer keeps ticking but token count is frozen. 2 questions here: is it safe to allow this to continue? Will it progess when my limits refresh or am I better off killing the execution (Ctrl C)? Then continuing when my limits do refresh.

I am seeing the stuck loop cycling also, but I'm in also Claude Code GUI extension, can not terminate like usual (esc or button), turning internet connection on and off does terminate it most of the time and it goes back to normal.

please

Related community angle on the same pain: proactive pause before 100%, not only auto-continue after.

On long Fable / 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-guard
not official. macOS 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

Same issue here — long-running tasks keep getting killed by the session limit.

I built claude-tmux-dog to work around it. It runs Claude Code inside a tmux session with a watchdog that:

• Auto-resume after quota reset: detects AccountQuotaExceeded, parses the reset time from the error, waits, and sends "continue" once the limit resets.
• Auto-compact on full context: monitors ↑ token count and sends /compact before hitting context limits.
• Process watchdog: auto-restarts claude if it crashes, keeps sessions alive for extended runs.
• Stall detection: nudges claude when it goes idle (timeouts, network hiccups).

Been using it for a few days now — session limit is no longer a blocker.

For anyone hitting this inside the Claude desktop app / GUI extension (a few comments here mention being stuck there, not just in the CLI): that case is trickier because when credits run out Claude doesn't emit a Stop event, so a hook can't catch it.

I built an open-source tool for exactly that — claude-auto-continue (claude-ac). On the desktop app it finds the Claude window and clicks the real "Resume work" button via Windows UI Automation / the macOS Accessibility API: one click when your credits are back, or an opt-in automatic mode that waits for the quota reset and resumes on its own. For the terminal there's also a Bash wrapper that detects the limit in the output, waits, and relaunches with --continue.

It can also list your blocked sessions split by Chat / Cowork / Code, so you only resume the ones you care about. MIT, no telemetry, no open ports, and it never spends money — it only clicks the resume buttons, never upgrades or purchases: https://github.com/blackstardigitalstudio/claude-auto-continue

I understand that Anthropic would rather we upgrade or pay for additional usage, and having to wait and manually re-trigger is both a risk to revenue (because if it auto-restarts, we can leave things running without upgrading and don't experience that pain) and to experience (if it auto-restarts, it may restart something that is not a high priority rather than restarting the thing I need most.)

However. For non-enterprise clients who are already on a Max plan? This could be an option for people on higher plans in a non-enterprise environment with minimal risk, as few of them are ever going to upgrade further.

Asking the question to "stop and wait, upgrade, or auto-resume" at Max or higher would resolve this cleanly with minimal revenue risk and would be very much appreciated.

bump

Bump from me as well.
Just a simple "continue" option would be nice, even if doesn't wait automatically, but I can click it myself after a few hours.
Otherwise it is just bad behaviour and effectively disruptive of the workflow and the tokens spent up to that moment.

@massyn Isn't this a dupe of #6254?

I opened this feature request https://github.com/anthropics/claude-code/issues/68284 and hacked around a solution that I thought wasn't so hard to bake into the Claude code.

https://github.com/softcane/cc-session-recover

There are other similar open issues. However, my thoughts are that I think this fix as a native feature in Claude code is not in the best interest of Anthropic's income statement. For example, many regular users are currently not utilising the weekly quota usage and that unused capacity is shared among others who are either enterprise users or know how to precisely set up the loops.

Imagine this, if this becomes a native feature, developers would start scheduling tasks at 9 pm and would continue until they wake up.

What you think?