[Feature]: Auto-select the account with the most remaining quota before starting a task

[sionzee]

Before submitting

• I searched existing issues and did not find a duplicate.
• I am describing a concrete problem or use case, not just a vague idea.

Area

apps/web

Problem or use case

I run t3code with 7 separate Claude Max (x25) accounts. Today the account used for a new task is whichever one happens to be selected, not the one with the most headroom.

The failure mode is predictable: I start a long task on an account whose Opus/Fable quota is nearly exhausted, and the run dies mid-task on a rate/quota error. I then have to notice it, switch accounts manually, and restart, usually losing the in-flight work.

Picking manually does not really work either, because the only way to know an account's remaining quota is to open Claude Code and check usage on each account.

Proposed solution

Track per-account quota/usage state and use it to choose the account for a new task.

Concretely:

1. Store, per configured account, the last-known usage signal remaining quota, reset time, and the last rate-limit/quota error seen. Rate-limit response headers and quota errors already carry most of this, cache what the app observes rather than adding new polling.
2. Add an account selection mode: manual (today's behavior) and auto: most remaining quota.
3. In auto mode, resolve the account at task start, before the prompt is sent, and show which account was chosen (and why) in the UI so it is not a black box.
4. Treat an account as unavailable until its reset timestamp once it returns a quota error, and skip it in selection.

Model-aware selection matters: quota is tracked per model tier, so "lowest usage" should be evaluated against the model the task will actually use, not a global average.

Why this matters

Anyone running more than one account benefits mostly heavy users and small teams pooling subscriptions.

The outcome is that long tasks stop dying halfway through for a reason the tool already had enough information to avoid. It also removes the manual "switch, check, switch back" loop before every task, and spreads load across accounts instead of burning one down while six sit idle.

Smallest useful scope

A single account picker that runs at task start and selects the account with the most remaining quota for the target model, using whatever usage data the app has already observed.

No background polling, no rebalancing mid-task, no automatic failover-and-resume. If an account has never been used and has no cached usage data, treat it as full. That alone would solve my problem.

Alternatives considered

• Manual switching: what I do now. Requires switching into each account to read its usage, so it does not scale past two or three accounts.
• Round-robin across accounts: simpler, no usage tracking needed, but it still lands on a nearly exhausted account roughly 1/N of the time.
• Failover on error: retry the task on a different account after a quota error. Useful as a complement, but reactive — the task has already been interrupted and in-flight context may be lost.
• Just watching usage myself in the Claude UI and remembering which account is fresh. Does not survive a week of use.

Risks or tradeoffs

• Usage data is only as fresh as the last request per account; a stale cache can pick a bad account. Treating each pick as best-effort (and falling back cleanly on a quota error) keeps this from being worse than today.
• Quota is per model tier and resets on rolling windows, so "most remaining" is not a single number. Getting this subtly wrong could be more confusing than manual selection if the chosen account is not surfaced.
• Auto-switching accounts mid-session could surprise users who expect a thread to stay pinned to one account selection should apply at task start only, and stay opt-in.
• Account state that spans threads/sessions needs somewhere to live; that is new persisted state to maintain.
• Anyone with a single account gets nothing, so it must not add friction to the default path.

Examples or references

Rate-limit headers from the API (remaining requests/tokens and reset timestamps) are the natural signal source. Conceptually similar to API-key rotation pools in gateway tools like LiteLLM, which route by remaining budget rather than round-robin.

Contribution

• I would be open to helping implement this.

[llewellynvz]

I think this would be a wonderful idea. Especially for the fact that we keep hitting token limits at the most in-opportune time. I would also be more than willing to help architect / design this. This would add a lot of value for long term work flows (especially seeing that GPT 6 is soon to hit the public).

[theportugueezer]

I'd like to help move this forward with a narrower, configurable version.

What's changed since this was opened:Usage ‚-> Limits now collects session/weekly windows (usedPercent, resetsAt) for every connected account, per provider instance, on the existing refresh schedule. The selector can just read that snapshot. It needs no new polling and no header scraping, which covers the "no background polling" constraint above.

Proposal: opt-in "Auto-select account" for new threads only

An off-by-default setting in Settings ‚-> Providers. When it's on, the new-thread composer resolves the account (provider instance) from the latest Limits snapshot before the first message is sent. The choice shows as a chip, e.g. "Auto ¬∑ Claude (work) ¬∑ 23% of 5h used, resets in 2h", and you can override it for that thread from the model picker as you would today.

The user can configure:

Setting	Options
Eligible accounts	Which instances auto-select may choose, in priority order
Strategy	Most headroom (lowest usage for the target model's windows) · Soonest reset (the account whose window resets first and still has room) · Priority first (stay on the top account until it crosses a threshold)
Thresholds	Skip an account above X% of its session window or Y% of its weekly window
Model	Keep the remembered/project default model; only the account changes

Rules:

• Stale or missing data: refresh first if the snapshot is older than the normal check interval. Accounts that report no limits (API key, proxy) rank last and are never auto-preferred.
• If no eligible account is under its thresholds, fall back to today's behaviour and say so in the chip.
• A project's configured model still wins over auto-select.

Out of scope (each one is a separate problem):

• Switching accounts mid-thread or after a limit is hit, which Claude provider needs a Shadow config path, matching Codex, for multi-account thread continuation #7547 already tracks
• Switching across providers or across models (Support automatically switching provider for similar or same models #9801)
• Accounts that only come from a CLIProxyAPI hub, since T3 can show their usage but can't run turns on them

Questions for maintainers

1. Is this direction acceptable, and is "new threads only, opt-in" the right scope?
2. Should account resolution live in the client (composer default) or on the server at thread start? The server would make it work the same for mobile and other clients.
3. Would you rather start with one fixed strategy (most headroom) and add the others later?

If the direction is approved, I'm happy to implement it as one focused PR with tests.

[mneves75]

I built a version of this to find the smallest shape that works, and opened it as a draft so the trade-offs are concrete: #16076. It has no maintainer approval, so treat it as a proposal for this discussion; I will close it if the direction is not wanted.

What it does. One opt-in environment setting, Rotate accounts for new threads, off by default, plus an Account rotation switch on each account in Settings → Providers, also off by default. While a thread is still a draft, the client picks its account among the selected provider's marked accounts that are signed in and offer the selected model: most usage left first, then the account whose last thread was started longest ago. Model and options stay as selected. An account picked in the model picker stands, a project's own default model stands, and a started thread never moves.

Two things I did not expect.

1. It has to happen in the client, on the draft. The obvious place is ThreadLaunchService.launch, which covers every launch path. Reading the clients, that breaks on the second turn: web and mobile keep the composer's account in draft state and send it again (removeDraftThreadReferences moves the draft to the thread key; resolveComposerProviderSelection takes the draft's account first), and the server reads that as a provider switch back to the original account. Between separate Claude config directories that is a lossy handoff. Writing the choice into the draft, like a sticky or project default, keeps the picker, the first turn and later turns on one account. It is the same shape as Auto balance for machines.

2. Usage data alone is not enough. On macOS my Claude instances report no windows (usageLimits.unavailable.reason = "probeFailed"), accounts connected with ChatGPT report unsupported, and my two Codex accounts happened to sit at the same weekly percentage. "Most remaining quota" picks nothing in all three cases. Falling back to the account started on longest ago makes it take turns there, and it also spreads threads started close together.

Guards. Only the accounts the user marks take part, and a draft on an unmarked account is left alone, so nothing moves to an API-key or proxy instance unless the user marks it. Reset times are compared against the environment's latest provider report, not the client clock. A draft that is sending or being promoted is left alone.

Left out on purpose: continuing a thread that stopped on a limit, rotating between turns, changing model or provider, and threads the server starts itself (scheduled tasks, agent-created threads).

Open questions I would like a maintainer's call on: whether the client-side draft is an acceptable home for this (the alternative is server-side with a client change to adopt the result), and whether the setting belongs next to the usage-limit rows.

Edited 2026-10-05: eligibility is now per account. The first version took in every subscription account, guessed from what each one reports about its usage.

Built and tested with Claude Code (Claude Opus 5.5) on my own accounts.

[AdEx-Partners-DE]

A different cut of the same wish, running in my fork: don't rotate, switch only when the account is actually used up.

With two subscriptions per provider, rotation is not what I want. I want to use one account's weekly allowance to the end and then move on, without thinking about it. And with Codex there is a trap: at 0% the turn does not fail, it quietly continues on ChatGPT credits. Nothing tells you.

What the fork does:

• Continue with ‹account› on the usage-limit notice: one click and the same thread carries on with another signed-in account of that provider.
• Switch to ‹account› above the composer once the selected account's window is used up, before you send.
• Settings → General → Switch account at usage limit (off by default): a new turn then starts on another account that offers the model and still has allowance. Same session home first, then most remaining quota.

Why I like this shape:

• It lives where turns are dispatched on the server, so it covers messages you send, scheduled tasks and turns that agents start. That is also most of what Scheduled tasks: optional fallback provider/model when the primary hits usage limits #16512 asks for.
• A running turn never moves. Only fresh turns are routed.
• It reads the limits snapshot that already exists. No extra polling.
• When no other account has allowance, the turn runs where it was. No surprise failure.

Evidence: a real run in a dev build (thread on an account at 100% of its weekly window, message sent, the turn ran and finished on the other account, handed over by summary), plus seven mid-thread account switches in my daily database. Honest limits: readings are periodic and can be stale, ChatGPT-connected accounts report no limits, and "every account is empty" does not yet say so.

@mneves75 your #16076 and this would fit together: rotation for new threads, exhaustion for running ones. Would one setting with two modes make sense to people here?

Code: ac0053171, 3c64dc7ad, c8b94a48d. on stark/main.

---

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

[AlexChambers]

+1 to the original idea. One rule on the server (pick the account with the most headroom for the model) is the right size.

I want to suggest a narrower first scope that I think avoids what made #16076 hard: apply it to delegated tasks (delegate_task) before new threads.

I run 5 Claude and 2 Codex subscriptions. Most of my uneven usage comes from orchestrating threads that send subagents to whichever account the parent is on. Right now, one account's 5-hour window runs out while the others sit near 100%.

For new threads, #16076 had to show the chosen account in the draft, keep it from changing while you type, and handle the clients resending the draft's account on the next turn. Delegates have none of that, because there's no draft and no picker. When a delegate names a provider and model but no account, the server can pick the account once when it creates the child thread, and the child keeps that account. If the selection rule proves itself there, new threads and scheduled tasks can use the same rule later.

Two details from this thread that I think the rule needs:

• Skip exhausted accounts, don't just rank them last. As @AdEx-Partners-DE pointed out, a Codex account at 0% keeps going on ChatGPT credits instead of failing. An account at 0% in any window that applies to the model shouldn't be picked.
• Let people choose between spreading and draining. Some of us want load spread evenly. Others want to use one account's allowance up before moving on. A per-provider setting with those two options would cover both without taking a side.

#15137 (exposing usage over MCP) fits on top of this later, for agents that want to override the pick. I'd rather the default behavior not depend on every orchestrating agent reasoning about quotas in its prompt.

Would a maintainer be open to this scope? It's opt-in, only for delegates, and reads the usage data Usage → Limits already collects.