Repository navigation
Bring "Resume at reset" to the current release #13069
Description
Activity
Reacted by Alvis Tang and fullheartTriage
Thanks for the clear ask and the screenshot — this is a real pain on multi-thread Claude usage.
Short answer: Resume at reset is already implemented for orchestration V2, and we are not backporting it to the current (
v0.0.42/main) release.What we checked
- #12686 adds per-thread Resume at reset, optional Auto-resume limited threads, and a server-side
UsageLimitRecoveryWorkerthat can continue after the provider-reported reset (including with no client connected, and after restart). - That work sits on the V2 stack with the Limited stop state (#12677) and snooze-until-reset (#12687), and is included in the open V2 PR (#2829).
- Current
main/ stablev0.0.42has none of that UI or scheduling path — your screenshot matches today’s behavior (limit message + reset time, manual “continue” later).
Why not an independent / current-release ship
Earlier V1 PRs for the same idea (#12458, #11215) were closed for the same reason: we are not taking further orchestration/provider-layer changes on the pre-V2 server; they would conflict with or be discarded by the rewrite. Resume-at-reset is built on V2 commands and projections, not something we can safely peel onto
v0.0.42.What to do today
Until V2 lands: after the reset time, re-open the thread and send a short continue (as you’re doing), or switch that thread to another provider instance with quota.
Tracking
This ships with orchestration V2 — follow #2829 (and #12686 for the resume layer). Closely related: #10545 (Limited vs Failed), discussion #8920 (snooze until reset).
Happy to close this as planned-for-V2 once that’s clear on your side; otherwise we can leave it open as a pointer until V2 merges.
Reacted by Paweł Kica- #12686 adds per-thread Resume at reset, optional Auto-resume limited threads, and a server-side
Thank you very much @juliusmarminge !
Thanks for taking the time to report this and provide the details. We revisited it during the orchestrator V2 cleanup.
The requested Resume at reset control is now present on the pinned V2 main tree, with a server UsageLimitRecoveryWorker. The request to ship this before V2 is superseded by V2 landing.
I’m closing this based on the current source and the evidence in this thread.
Verified source availability, not delivery of a particular packaged stable release.
If you still hit this on a current build, please reply with the app/server versions and the steps that reproduce it. We can reopen this if the original problem is still there.
Could per-thread "Resume at reset" ship before v2? I run multiple threads and currently have to return after a usage reset to send "continue" manually. #12686 implements this in v2. Could it be backported or released independently? I'm on v0.0.42.