Opt-in: start new threads (and scheduled runs) on the account with the most usage headroom

[MikaMcFlurry]

Problem

With several accounts per provider (e.g. three Codex and three Claude instances), you pick the account for every new thread by hand. fallbackModelSelection only kicks in once the default is exhausted. #24453 and #25261 cover continuing after a limit; this is about starting in the right place.

Proposal

An opt-in autoModelSelection server setting:

• balance-accounts: keep the default provider kind and model, start the thread on the account of that kind with the most headroom. The score is the scarcer of the 5h and weekly windows, with the mean as a tie-break. Exhausted, disabled and unauthenticated accounts are never picked.
• any-provider: as above, but switch to another provider's model of the same tier when every account of the preferred one is low.
• Off by default. A configured fallback still wins over a cross-provider switch.

It applies to new threads (web, mobile and the MCP launch path) and, in a follow-up branch, to scheduled-task and webhook runs that start a new thread. Runs bound to an existing thread keep following that thread.

Implementation: mika/auto-model puts the pure routing in @t3tools/shared/autoModelRouting, with unit tests. mika/routine-auto adds the scheduled runs. Happy to open PRs if this direction is welcome.

Written with Claude Opus 5.5 in Claude Code (running in T3 Code).

[MikaMcFlurry]

Follow-up: the same routing now also covers webhook-triggered scheduled tasks, which is where it matters most for me. Claude routines are tied to one account, so when that account runs out you cannot simply continue on another one.

Branch: mika/routine-routing (stacked on the branches above).

• Allowed models: a new autoRoutingAllowed setting limits every automatic choice (new threads, routed scheduled runs) to listed accounts (codex-2), account/model pairs (claude-2/claude-opus-5-5) or whole drivers (driver:codex). Empty means everything is allowed.
• Per-request choice: a webhook body may carry an optional t3 object, e.g. {"t3": {"routing": "auto", "allowed": ["driver:codex"], "effort": "high"}} or {"t3": {"model": "codex-3/gpt-6.1-sol"}}. With routing: "auto", a task profile inferred from the rendered prompt picks the model tier, and the account with the most headroom runs it. A request can narrow the allowed list but never widen it, so a leaked webhook URL cannot pick models outside it.
• No schema or migration change: per-task routing is driven by the request and the settings, and the stored modelSelection stays the fallback.

Pure routing in @t3tools/shared/routineModelRouting with unit tests; the scheduler only threads the parsed directive through to the launch.

Written with Claude Opus 5.5 in Claude Code (running in T3 Code).

[ECuteri]

Part of this is up in #28595: an opt-in Switch to an account with usage left setting, off by default. When the account a message uses is out of usage, the message goes to the same model on another account of that provider with usage left, then to another provider's default model. A thread that hits a 5-hour or weekly limit mid-turn continues there right away instead of waiting for the reset. New threads still try a configured fallback model first. It does not pre-balance accounts that still have usage, or cover scheduled and webhook routing.