Configurable fallback chain for usage limits: if this instance is limited, continue on the next one

[schedawg74]

Problem

I run long, unattended tasks in T3 Code and have more than one provider instance set up, for example two Claude subscriptions plus Codex. When the active instance hits a usage limit, the thread stops and offers "Resume at reset" or "Snooze until reset". The work then waits for hours, or until I switch the model by hand, even though another instance I already configured still has quota.

Proposal: an ordered fallback chain for usage limits

Off by default. As soon as more than one provider instance is configured, Settings lets me define an ordered fallback chain:

Primary:     Claude (account A) · Opus
Fallback 1:  Claude (account B) · Opus
Fallback 2:  Codex · <model> · high effort

If the primary is limited, the thread continues on fallback 1. If fallback 1 is also limited, it continues on fallback 2, and so on down the chain.

Behaviour I'd expect:

• Trigger only on usage or quota limits (session/weekly windows, 429 with a reset time). Other errors keep today's behaviour.
• Each entry is a provider instance + model (+ effort), picked with the existing model picker. A fallback can be another account of the same provider, which is the most common case for me: same model, separate quota.
• Skip entries that are already known to be limited (Usage → Limits already knows their reset times), so the thread does not bounce through dead entries.
• Continue the same thread. Use native continuation when the next entry can share the session, and the existing context handoff otherwise.
• Make the switch visible. Show a timeline marker such as "Switched from Claude (A) to Claude (B): usage limit, resets 14:00".
• When the whole chain is limited, fall back to today's behaviour: auto-resume at the earliest reset.
• Nice to have: override or disable the chain per thread, per scheduled task, and for delegated child tasks. Also an option to return to the primary after its limit resets.

Why

Multiple provider instances and context handoff already exist. A user-defined chain connects them, so long runs keep going overnight without manual switching or paying for extra usage on one account while another account still has quota.

Related

• Option to automatically hand off to a fallback provider when hitting usage limits #15846: automatic handoff to a single fallback provider. This proposal extends it to an ordered chain that also covers several accounts of the same provider.
• Continue a thread on another account when it hits a usage limit #18949: continue a thread on another account at a usage limit (same-provider case, Claude shadow home).
• Scheduled tasks: optional fallback provider/model when the primary hits usage limits #16512: fallback for scheduled tasks.
• Usage-limit recovery: resume with the original task, show Resume for limited subagents, fail over to another configured account #21024: usage-limit recovery, including failover to another configured account.
• [Feature]: Auto-select the account with the most remaining quota before starting a task #6923: pick the account with the most remaining quota at task start.

[Derwish101]

Adding a concrete use case for this proposal: Codex subscription → Claude subscription when Codex hits a usage limit → Codex after reset, in the same thread. I want to keep using official T3 releases, so I would prefer this upstream rather than maintaining a custom app build.

Would a narrow first slice of this proposal be welcome?

• Opt-in, with explicitly selected provider instances/models; for my setup these are subscription-authenticated Codex and Claude, with no automatic move to an API-funded provider.
• Continue an interrupted thread only for a classified usage-limit failure, using the existing cross-provider context handoff and workspace. Other failures retain their existing behavior.
• Return to the primary on the next user message submitted while the thread is idle after the reset time; never interrupt active Claude work. A manual model choice cancels automatic return.
• Respect manual stops, snooze, pending approvals, and newer work; reject stale or duplicate fallback triggers. If the fallback is unavailable or also limited, preserve the normal recovery path rather than loop between providers. Make the switch visible.

I checked the existing resolveNewThreadModelSelection helper and the related implicit-delegation work in #28222, #28226, and #28234. This request concerns recovery of an already-running thread, rather than only selecting a provider for a new thread or child task. It should reuse the existing fallback configuration and eligibility checks wherever possible.

A local prototype was prepared against installed-source commit 044f07257c96, using the usage-limit recovery worker and guarded orchestrator commands, with saved primary-selection/reset metadata. Focused tests and server typechecking/builds passed, including routing tests. It has not been validated against actual live quota exhaustion or rebased/adapted to current main, and the installed app has not been modified. Cross-provider handoff also cannot promise identical native context or exactly-once external actions.

Per CONTRIBUTING, I am asking for maintainer approval of direction and scope before opening a feature PR. Would you prefer this as the first slice of the existing chain proposal, and where should interrupted-thread recovery integrate with the newer fallback infrastructure?