[Bug]: Usage-limit auto-resume ignores allowances restored before the scheduled reset#22307

Area

apps/server

Summary

A thread with usage-limit auto-resume armed keeps waiting for the reset timestamp from its original failure, even when the provider restores the account's allowance before that timestamp. This leaves work paused while the provider is usable again.

Early restoration can come from a user redeeming a Claude or Codex reset credit, or from a provider-initiated account-wide or service-wide refresh. Recovery should depend on whether the blocking limits have cleared, regardless of what caused that change.

The observed example below involved a banked reset and three Claude threads. Codex reset credits and provider-initiated refreshes have not been reproduced; their relevance is inferred from the same provider-neutral recovery path.

Steps to reproduce

1. Run a Claude subscription-backed thread until its five-hour allowance is exhausted and T3 records a future reset time.
2. Enable Resume at reset, or have Auto-resume limited threads enabled. Leave the continuation armed.
3. Before the recorded deadline, restore the account's allowance early. A banked reset provides a way to exercise this condition; a provider-initiated early refresh presents the same recovery condition. In the observed case, a banked reset was redeemed through a separate dashboard outside T3.
4. Confirm that fresh provider usage readings show capacity restored. Keep the T3 server running and observe the waiting thread before the original deadline.

Expected behavior

For a thread opted into auto-resume, restoring the allowance early should make it eligible to continue once T3 can confirm that the limits blocking that thread have cleared, without waiting for an obsolete deadline.

This should preserve cancellation and other existing recovery guards. It should not restart threads that have been explicitly stopped or had auto-resume cancelled.

Actual behavior

My three threads remained stopped after the allowance was restored. Their saved reset deadline was still 15:10 UTC, despite the account being usable again around 11:44 UTC.

I then cancelled the pending auto-resumes and sent Continue where you left off. to each thread through T3's thread messaging tool. T3 accepted those messages and started new runs before 15:10 UTC.

Evidence

Observed on 20 October 2026; all times below are UTC:

• Around 11:40: three Claude turns stopped with a usage-limit failure recording resetAt: 2026-10-20T15:10:00.000Z.
• At 11:42: fresh usage readings showed the five-hour allowance 100% used and the weekly allowance 99% used.
• After redemption, a successful reading at 11:44 showed both allowances at 0% used. The weekly reset remained 21 October at 20:00.
• Auto-resume was armed. I cancelled it before sending the manual continuation messages.
• The messages started new runs around 11:46. No T3 restart was needed.

I did not leave the threads waiting until 15:10 UTC, so this does not establish a failure to resume at the scheduled deadline. The reported problem is that early restoration is not considered while waiting.

Relevant source

Source inspected at commit d36b7da2485bc889b320a285deea181f637d760a, matching the installed release:

• UsageLimitRecoveryWorker.limitRecoveryCommand derives its deadline from thread.usageLimitResetAt and returns without dispatching while resetMs > nowMs. Its recovery decision does not read fresh account capacity.
• ProjectionStore.getLimitRecoveryCandidates also filters armed recoveries against the original error's failure.resetAt.

These checks explain why an early allowance reset alone cannot make an armed continuation eligible through this recovery path. This is a source-level finding; no isolated automated reproduction or patch has been run.

Impact

Work can remain paused for hours after capacity returns, particularly for unattended threads. Users must notice that the allowance has been restored and manually resume each affected thread.

Version or commit

t3 v0.1.1-nightly.20261020.3411

Commit: d36b7da2485bc889b320a285deea181f637d760a

Environment

Debian GNU/Linux 13, headless Linux VM running t3 serve as a systemd service; Claude Agent provider, Claude Pro subscription, Claude Opus 5.5.

Workaround

After confirming the allowance has been restored, cancel the pending auto-resume and manually continue the affected threads. Sending Continue where you left off. through T3's thread messaging tool started new runs in this case.