Scheduled tasks: optional fallback provider/model when the primary hits usage limits

[Kevin-Brady-Carrick]

Problem

Scheduled tasks run unattended, so a usage limit on the selected provider/model can prevent a daily report or check from completing until someone notices and manually changes the model. The scheduled-task form offers one model selection; I would like an optional, explicitly configured fallback for these runs.

This is a scheduled-task-specific extension of the general provider handoff proposal in #15846. I have not reproduced a scheduler failure or inspected the scheduler implementation; this is a requested capability, not a claim about a confirmed defect.

Smallest useful scope

• Add an optional Fallback model selection to scheduled tasks, using the existing provider/model picker. Off by default.
• On an explicit usage/quota-limit rejection before the agent begins work, try the configured fallback once. Allow a different provider instance/account as well as another model, since models on one account can share a quota.
• Preserve the task prompt, project, environment, workspace/base branch, permissions, and tool restrictions. Do not broaden permissions during fallback.
• Make cross-provider fallback explicit and opt-in, since it changes which provider receives task context.
• Record the requested model, actual model, fallback reason, and final outcome in the run history. Show this on desktop, web, and mobile.
• If both attempts fail, mark the run failed with an actionable explanation. Avoid loops or repeatedly retrying a quota that resets hours later. Return to the primary model on the next scheduled run.

Prevent duplicate work

A rejected start is different from a usage limit reached after tools have already run. The initial implementation could limit automatic fallback to failures before work begins. If mid-run handoff is later supported, it must preserve completed actions and resume safely rather than replay the original task and duplicate writes, messages, commits, or other effects.

Example

A daily 08:00 read-only health report prefers a Claude model, with a Codex model on a separately authenticated account as its fallback. If Claude reports a usage limit before starting, the same scheduled occurrence runs once with Codex and clearly records that switch.

Acceptance criteria

1. No fallback configured: existing behavior remains unchanged.
2. Primary starts successfully: fallback is not called.
3. Primary receives an explicit pre-start usage-limit rejection: configured fallback is attempted once in the same scheduled occurrence.
4. Both attempts fail: one failed occurrence, with both outcomes visible and no retry loop.
5. Slow responses, ordinary tool/test failures, and permission denials do not trigger a model switch.
6. The next occurrence starts with the configured primary again.
7. Permissions and approved data/provider boundaries remain enforced.

I am seeking maintainer feedback on the direction and scope before proposing an implementation PR, as requested in CONTRIBUTING.md.

[AdEx-Partners-DE]

Part of this is running in my fork, for the same-provider case: with Switch account at usage limit on, a new turn starts on another signed-in account of the same provider when the thread's account has used up a window. The decision sits where turns are dispatched on the server, and scheduled tasks start their turns through that same path. Details and evidence are in #6923 (comment).

Two honest gaps against what you ask for: I verified it with a turn I sent myself, not yet with a real scheduled run, and there is no per-task order and no fallback to another provider. Your point about recording requested model, actual model and reason in the run history is one I am missing too.

Would "another account of the same provider" already cover most of your cases, or is the cross-provider fallback the part you need?

---

Posted by Claude (Opus 5.5, Claude Code via T3 Code) on behalf of @AdEx-Partners-DE.