Per-thread "On usage limit" setting to auto-resume at reset without interaction

[rwspatin]

Problem

When a thread hits a provider usage limit, T3 Code shows a notice with a Resume at reset action. That works, but it's opt-in after the fact: someone has to see the notice and click it. For long autonomous work (overnight runs, scheduled tasks, delegated subtasks, queued prompts), the whole point is that I'm not watching. If I don't click, the thread just sits there until I come back.

I'd like to decide up front, when starting or configuring a thread, that it should be fully autonomous: if it hits the limit, it schedules its own resume and continues when allowance returns, without any interaction.

Proposal

1. Per-thread setting: "On usage limit"

   • Ask (current behavior: show the notice with Resume at reset)
   • Auto-resume at reset (arm the resume automatically as soon as the limit is hit)
   • Stop

   Exposed in the thread header/composer options next to the provider/model selection, and via MCP (t3_thread_configure, t3_thread_launch, delegate_task, schedule_task) so orchestrators and scheduled runs can launch autonomous threads.

2. Global default in Settings (per provider, if that's simpler) that new threads inherit, so I can make autonomous the default once instead of per thread.

3. Inheritance: delegated child tasks and scheduled-run threads inherit the parent's setting unless overridden.

Behavior when Auto-resume at reset is set:

• On a usage-limit error, arm the existing resume-at-reset mechanism immediately; the notice still shows ("Will resume at 14:05 (local TZ)", with Cancel).
• If the queue has pending messages, resume the queue too, not just the session.
• If resume fails because the allowance isn't actually back yet, retry with backoff instead of giving up.
• Also resume early if the allowance comes back before the announced reset.

Related bugs

The setting is only useful if auto-resume itself is reliable. These open issues are effectively prerequisites:

• [Bug]: "Resume at reset" never fires: banner shows "Cancel auto-resume" but the thread is not resumed after the usage limit resets #17808: "Resume at reset" never fires even though the banner shows "Cancel auto-resume"
• [Bug]: Usage-limit auto-resume fires at the reset second and never retries after Claude refuses #22026: auto-resume fires at the reset second and never retries after Claude refuses
• [Bug]: Usage-limit auto-resume resumes the session but leaves the queue paused #26037: auto-resume resumes the session but leaves the queue paused
• [Bug]: inactivity auto-settle cancels a pending usage-limit auto-resume #18928: inactivity auto-settle cancels a pending usage-limit auto-resume
• [Bug]: Usage-limit auto-resume ignores allowances restored before the scheduled reset #22307: auto-resume ignores allowances restored before the scheduled reset
• [Bug]: Codex "Subscription Sharing usage limit" stream error isn't treated as a usage limit, so there's no resume-at-reset option #25333: Codex "Subscription Sharing usage limit" isn't treated as a usage limit (no resume option)

Thanks!

[rwspatin]

Correction to the premise above: auto-arming already exists as an environment-wide switch, Settings → Usage limits → "Resume after usage limits" (autoResumeLimitedThreads, off by default). With it on, UsageLimitRecoveryWorker arms recovery for every limited thread without a click. So "you always have to click" is wrong; sorry for the noise.

What's actually missing is granularity. The switch is all-or-nothing for the whole environment, and I don't want everything to be autonomous:

• Per project: some projects should always auto-resume. Add autoResumeLimitedThreads to PROJECT_SCOPED_SERVER_SETTING_KEYS / ProjectSettingsOverrides, resolved through resolveProjectSettings, the same way continueThreadsAfterServerUpdate already works per project.
• Per thread: inside a project where I run several tasks in parallel, I sometimes want just one thread to be autonomous. Add an optional per-thread override (inherit / on / off, default inherit), modeled on thread.auto-settle.set / autoSettleDisabledAt.

Resolution order: thread override → project override → environment setting. Delegated child tasks and scheduled-run threads would inherit the parent thread's override.

Both the SQL candidate filter in ProjectionStore.getLimitRecoveryCandidates and limitRecoveryCommand would resolve the effective policy, so the decision stays in one place per path.

I'll link a PR with a concrete proposal here soon. Happy to adjust scope, or split project-level and thread-level into separate PRs, if maintainers prefer.

[rwspatin]

As promised, first step: #26378 makes "Resume after usage limits" overridable per project, using the existing project-settings override mechanism. The per-thread override (inherit / on / off) would come as a follow-up on top of it, if you're open to it.