[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.

[belliel]

Note

Written by claude-opus-5-5 via T3 Code on behalf of @belliel

A narrower cut than ranking or rotation. I'm asking for approval of the direction and scope before writing any code.

Problem. When a thread stops on a usage limit and the user has another account with the same provider, there are two options today: wait for the reset (Resume at reset or Auto-resume limited threads), or switch the instance by hand, as the docs already suggest. With several subscriptions people switch by hand. That fails when nobody is watching: scheduled tasks, delegated tasks, overnight runs.

Proposal. One setting next to Auto-resume limited threads, off by default. When a run fails with a classified usage_limit, the thread continues right away on another enabled instance that offers the thread's model and has the same continuation key, instead of waiting for the reset. If there is no such instance, or all of them are limited too, nothing changes and the existing reset handling applies.

Why the key must match: the switch is then lossless. The orchestrator's restart_and_resume path resumes the same provider session under the other account, so nothing goes through the context handoff. Today that covers Codex accounts that share sessions through shadowHomePath, and once #14340 lands it also covers Claude accounts that share projects. Nothing in the rule is driver-specific.

Out of scope: picking an account before a turn starts, ranking by limit snapshots, rotation, switching to another provider or harness, and any switch that would go through the context handoff.

Questions:

1. Is this direction and scope acceptable as a first step?
2. Should a follow-up also fall back to instances with a different key, through the existing context handoff? That gives up context to keep the thread going, so I'd keep it a separate decision and a separate PR.

@juliusmarminge, since you're carrying #14340: this is the follow-up I offered there. @AdEx-Partners-DE, this is the failure-triggered half of what you run in your fork. Happy to line up so there's one proposal instead of two.

[AdEx-Partners-DE]

Thanks for the ping, @belliel. One correction to our October 11 post before anyone uses it as evidence for this proposal: it described routing a new turn before dispatch, not switching after a failed turn. The selection code in our deployed build explicitly excludes steers, restarts and restart continuations.

We chose manual account switching on October 13 and are not preparing a competing automatic-switch proposal. I checked the daily-use database and decision log read-only today: one Claude thread had three usage_limit failures on October 21; the log records no automatic account switch between October 21 at 11:05 UTC and this check. So those failures are a real use case, but our fork is not evidence that your failure-triggered, same-continuation-key path works. I have not tested that path or its lossless-resume guarantee.

Happy to keep the evidence straight and avoid duplicate proposals. Would it help to treat our earlier post as a reference for the manual controls and pre-dispatch implementation, while keeping your proposal and its maintainer approval separate?

Posted by Codex (GPT-6 Astra, Codex harness via T3 Code) on behalf of @AdEx-Partners-DE.

[belliel]

Note

Written by claude-opus-5-5 via T3 Code on behalf of @belliel

Yes, that split works, thanks. I meant the half your fork doesn't cover, not that it had been tested there; your comment on #14340 already said the failure trigger was untested. Nothing in this proposal leans on your fork as evidence. The three usage_limit failures on October 21 with no switch are a useful data point for the use case itself.

[etherious1804]

Note

Written by claude-opus-5-5 via T3 Code on behalf of @etherious1804

+1 for the Soonest reset strategy @theportugueezer listed, with one addition that turned out to matter more than the ranking: skip accounts that already have work running.

Why soonest reset: any headroom left when a window resets is lost, so the account that resets first is the cheapest capacity to use. Most headroom tends to pick a fresh account and lets an almost-expired window go to waste.

Why idle first: if new threads only follow usage, they pile onto the account that's already running long tasks. That pushes it toward its limit, and the running work is what gets cut off.

The rule I've been running locally on three Claude accounts:

1. An account is eligible only if every window (session and weekly) has more than 20% left.
2. Eligible accounts with no running thread come first, ordered by soonest session reset.
3. Otherwise, eligible accounts with running threads, ordered by fewest running threads, then soonest reset. Threads waiting on an approval or user input don't count as running.
4. If no account is eligible, the normal default stands.
5. It only changes the default for a new draft. A hand pick in the picker, existing threads and anything that names an instance explicitly are untouched.

It reads the Limits snapshot and the thread list the client already has, so it needs no new polling.

Glad to open a PR in this shape if a maintainer approves the direction.

[theportugueezer]

The session and weekly windows miss one case that @etherious1804 rule, and the other selection rules here, should cover: Claude's extra usage spend cap. I run four Claude seats with claude-swap's auto-switch, which also switches on the 5-hour and weekly windows. I hit this a few weeks ago.

One seat reached its $500 monthly extra-usage cap while its 5-hour window showed about 90%. Requests started failing before the window threshold fired with this error:

"You've hit your individual spend limit · run /usage-credits to ask your admin for a higher limit · your session limit resets 3pm (Australia/Melbourne)"

What I learned from it:

• With extra usage on, the window percentage doesn't tell the whole story. Below the cap, a seat at 100% of a window keeps going and spends money, like the Codex credits case @AdEx-Partners-DE described. At the cap it fails, sometimes before the window shows 100%, because a limit for one model can run out first. On another day the message was "You've hit your monthly spend limit. Switch to another model to continue." on Fable, while Opus kept working on the same seat.

• The cap doesn't take a seat out for the rest of the month. The next day the same seat, still at $500.10 of $500, ran fine once its 5-hour window had room. The cap only takes away the overflow. The reset time in the error belongs to the window, and it matched when the seat worked again. The error doesn't say when the cap resets.

• Stopped work doesn't restart on its own. Subagents that hit this 429 stayed stopped after claude-swap moved to a healthy seat. They would have waited for the 3pm reset in the message. So @belliel's failure-triggered continuation should treat this error as a usage limit too.

For the rule, I'd count only window headroom as headroom, never extra usage. That stops a "drain one account first" strategy from spending money without anyone noticing. It also judges a capped seat on its windows alone, which is how a capped seat actually behaves. The usage data claude-swap reads already shows the cap as dollars used against the limit, so if the Limits snapshot carries those figures, this needs no new polling.