Sign up
View stargazersSign up

[Bug]: Usage-limit auto-resume fires at the reset second and never retries after Claude refuses#22026

opened21d agobySsimonblauth

Before submitting

  • I searched existing issues and did not find a duplicate.
  • I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

  1. Turn on Auto-resume limited threads in Settings → General.
  2. Run a Claude thread until the account hits its 5-hour limit. The run fails with usage_limit and a resetAt.
  3. Wait past the reset.

This happened to two threads on 2026-10-18, and both behaved the same way. I can't make Claude refuse at the reset second on demand. The second half, where the thread is never retried, follows from the code for any retry that fails with the same reset time (see below).

Expected behavior

The thread resumes after the limit resets. If Claude still refuses the resumed turn, the server tries again later instead of leaving the thread failed.

Actual behavior

The server sent "Continue where you left off." 1.3 s after the reset. Claude refused it and reported the same reset time. The server never tried again, and the thread stayed failed until I sent a message by hand about 24 hours later.

Timeline for one thread (UTC, 2026-10-18). The second thread differs by a few milliseconds.

TimeEvent
19:16:09Run 1 fails: usage_limit, api_error_429, resetAt 22:10:00.000Z
22:10:01.3Server dispatches "Continue where you left off." (creationSource: server, message id limit-resume:…)
22:10:02.8Run 2 fails: usage_limit, same resetAt 22:10:00.000Z
Nothing else happens

Claude's own message for run 1 said "resets 12:10am (Europe/Berlin)", which matches 22:10Z, so this is not a timezone mix-up. The notice on run 2 reads "paused until the 5-hour limit resets" with no "in Xh Ym", because the reset was already in the past (ClaudeAdapterV2.ts).

Two parts of the recovery path cause this. Both are unchanged on main at 26c6df72f8.

  1. No margin after the reset. limitRecoveryCommand dispatches as soon as resetMs <= nowMs (UsageLimitRecoveryWorker.ts L49-L54). Claude reported 22:10:00 as the reset and still refused at 22:10:02.
  2. A refused retry is dropped. The retry fails with the same resetAt, which is now earlier than the retry run's completed_at. getLimitRecoveryCandidates filters that thread out (ProjectionStore.ts L3615), and limitRecoveryCommand returns null for it ([L26-L32](https://github.com/pingdotgg/t3code/blob/26c6df72f82d09274bc6066cfe4204f97ab0b2f2/apps/server/src/orchestration-v2/UsageLimitRecoveryWorker.ts#L26-L32)). The comment there says the guard stops an expired reset from starting a retry loop. That concern is real, but with auto-resume on, the guard leaves the thread failed and nothing tells the user that auto-resume gave up.

On #21384 a maintainer wrote that a new failure re-arms on its own when the global auto-resume setting is on. Here the setting was on, but the second failure carried the same reset time, already in the past, so nothing re-armed.

A possible fix: resume a short margin after resetAt, not at it. When a usage-limit retry fails with a resetAt that is not after its own completion, re-arm from the refusal time plus that margin instead of dropping the thread, and cap the attempts so the guard still prevents a loop. One data point on the margin: a local script that resumed 120 s after the reset worked on every limit hit I logged on 2026-10-08, 09 and 10, with no second refusal. That shows a margin helps. It does not show how long the margin must be, and I have not checked whether Claude rounds its reset time.

Related, not duplicates:

  • #21384 (closed): a new, later reset with the global setting off. Here the setting is on and the reset is the same, past one.
  • #17808: "Resume at reset" never fires at all. Here it fires once, too early.
  • #16815: the thread is never armed. Here it is armed and fires.

Impact

Major degradation or frequent failure

Version or commit

0.1.0 (stable). The affected code is unchanged on main at 26c6df72f8.

Environment

Linux x64, T3 Code 0.1.0 server running as a background service, provider claudeAgent, model claude-opus-5-5 (high effort)

Logs or stack traces

shell
1# Root error item of run 1 and run 2 (identical), from orchestration_v2_projection_turn_items
2{"class":"usage_limit","message":"Claude API rate limit reached. Try again later.","code":"api_error_429","retryable":true,"resetAt":"2026-10-18T22:10:00.000Z"}

Screenshots, recordings, or supporting files

No response

Workaround

Send any message to the thread after the reset. I turned auto-resume off and run a small local script that resumes limited threads 120 s after the reset.

Investigated and drafted with Claude Code (claude-opus-5-5).

JJulius Marminge21d ago

Note

Grok responding on behalf of Julius.

Thanks for the timeline. Current main matches it.

The resume is sent as soon as the reset time passes, with no margin (apps/server/src/orchestration-v2/UsageLimitRecoveryWorker.ts:49-54). If Claude refuses that turn and reports the same reset time, that time is now earlier than the new run's completion. Both the worker guard (lines 26-32) and the candidate query (apps/server/src/orchestration-v2/ProjectionStore.ts:3640-3660) then skip the thread. That guard is deliberate: it stops a reset time that has already passed from starting a retry loop. The side effect is that a refused auto-resume leaves the thread failed with nothing scheduled and no sign that auto-resume stopped.

Claude still refusing a second or two after the reset time it reported is on Claude's side, but a single refusal at the boundary shouldn't end auto-resume. None of the open usage-limit fixes (#18937, #20804, #21114, #21735, #21952) change this path, and it's separate from #16815 and #17808, where the thread is never armed or never resumed.

Accepting this as a bug.

AAnshShah30098d ago
Synced from GitHub

I filed #29042 about this before finding this issue and closed it as a duplicate. I have not seen this failure myself: on my install, 9 of 9 auto-resumes that fired at the reset completed. The code-path note below is from reading main @ 7a760a9a88.

The sweep in ProjectionStore.getLimitRecoveryCandidates drops a failed resumed run when its reported resetAt is not after that run's completion. The arm path in UsageLimitRecoveryWorker.limitRecoveryCommand has the same guard. So a retry that is refused with the same reset is never armed again, which fits the report.