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