[feature] Sequential Account Usage Mode (Drain One Account Before Switching)

[snake302]

Problem Statement

I have two Codex accounts with independent rolling quota windows.

Currently, requests may be distributed across both accounts. While this helps balance usage, it also causes both accounts to consume quota at roughly the same time. As a result, both accounts may enter cooldown or become unavailable around the same period.

For my workflow, a sequential strategy would be more efficient.

Example:

• Start using Account A.
• Continue using Account A until it reaches its quota limit or becomes unavailable.
• Automatically switch to Account B.
• Continue working on Account B while Account A's quota window recovers.

By the time Account B is heavily utilized, Account A may already have recovered enough quota to become available again.

This creates a staggered recovery pattern and can provide longer uninterrupted working sessions compared to consuming quota from both accounts simultaneously.

Proposed Solution

Add an optional scheduling mode such as:

• Sequential
• Drain First

Behavior:

1. Select a primary account.
2. Route all requests to that account while it remains healthy and available.
3. When the account becomes unavailable, delayed, rate limited, or reaches a configurable threshold, automatically switch to the next account.
4. Continue through the account pool sequentially.
5. Once an earlier account recovers, it becomes eligible again.

This mode should be optional and coexist with the current balancing and affinity strategies.

Alternatives Considered

Current workaround:

• Manually pin Account A.
• Use it until quota is exhausted.
• Manually switch to Account B.
• Repeat throughout the day.

This works well but requires manual intervention.

Scope

In Scope

• Sequential account usage.
• Automatic failover between accounts.
• Optional configurable switch thresholds.
• Compatibility with existing forecasting and health checks.

Validation Plan

Using two accounts:

1. Enable Sequential / Drain First mode.
2. Generate continuous workload.
3. Verify that all requests initially use Account A.
4. Verify that Account B remains mostly untouched.
5. Verify automatic failover to Account B when Account A becomes unavailable.
6. Verify that Account A can become available again after its quota window recovers.

Expected result:

Instead of both accounts reaching cooldown at roughly the same time, quota recovery becomes staggered, allowing for longer uninterrupted usage.

Compliance Confirmation

• This proposal is for legitimate personal development workflows.
• This proposal does not request bypassing OpenAI controls or policies.
• This proposal does not introduce multi-tenant resale behavior.

[coderabbitai]

🔗 Related PRs

#463 - Fix runtime skip for deactivated accounts [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[ndycode]

Looked at how routing works, this is doable and I'd take it.

Right now the app spreads requests across all your healthy accounts at once, which is exactly what you don't want. There's no "use A till it's done, then B, then back to A when it recovers" mode. Pinning gets you close but it errors out instead of rolling over to B.

I'd add an optional Sequential mode (off by default): use A while healthy, jump to B when A maxes out, back to A once its quota resets. Maybe a "switch early" option too (like at 90%) so you don't hit the wall mid-task.

Two heads-ups:

• "Drain" means stop sending new requests to A, it won't wait for in-flight ones to finish.
• Active chats stay on their account, only new requests follow the rule.

Few things to decide:

1. Switch when A is fully maxed, or a bit early?
2. When A recovers, take everything back or just new requests?
3. Pin and sequential on at once, which wins?

If that matches what you meant, I'll take a stab at it.

[snake302]

Thanks, this is exactly the kind of feature I had in mind.

A few thoughts:

• I would prefer switching when the account is fully exhausted by default (100%). Making the threshold configurable could be useful later, but I think 100% is the best default behavior.

• Regarding active chats, my expectation is actually closer to how manual switching works today. Once Account A is exhausted and the system switches to Account B, I would expect all subsequent requests to use Account B, regardless of which account originally handled the chat.

The goal is for the user not to think about account assignment at all. The system should simply keep using the currently active account until it is exhausted, then move to the next one.

• I agree that pinning should take precedence. If an account is pinned, sequential mode should be ignored until the pin is removed.

Really appreciate you taking a look at this. I think this mode would be very useful for working with multiple accounts and rolling quota windows.

[ndycode]

Shipped this in v2.3.0-beta.0. Give it a spin if you want:

npm i -g codex-multi-auth@beta

Then set schedulingStrategy=sequential (or env CODEX_AUTH_SCHEDULING_STRATEGY=sequential). It drains one account fully before moving to the next, so the quota windows stagger instead of all resetting together. Default stays hybrid, so nothing changes unless you opt in.

The routing is tested and works. What I cannot prove from my end is whether it actually stretches your sessions in practice, since that depends on your real quota timing across accounts. That is the whole reason it is a beta. Would appreciate it if you run it for a bit and report back how it feels.