Feature request: multi-account load balancing to reduce rate limit interruptions

Problem

Power users with multiple Claude Code subscriptions (e.g., 4 Max accounts) currently have no way to automatically distribute workload across accounts. When one account hits its 5-hour session limit or 7-day weekly limit, the user must manually switch accounts by re-authenticating (/login), which breaks flow and wastes time.

Proposed Solution

Add a multi-account rotation/load-balancing feature that automatically routes requests to the least-utilized account. Two possible approaches:

Option A: Built-in account rotation

• Allow registering multiple OAuth sessions or API keys in Claude Code config
• Track per-account utilization via existing anthropic-ratelimit-unified-* response headers (5h and 7d windows)
• On 429, automatically failover to the next account with available quota
• Show which account is active in the status line

Option B: Upstream proxy with key rotation

• Extend the existing upstreamproxy architecture to support multiple API key backends
• Round-robin or least-utilized routing strategy
• Could be a standalone proxy that multiple Claude Code instances share

Context from source analysis

The current architecture is single-account throughout:

• getAnthropicApiKey() returns one key
• getClaudeAIOAuthTokens() manages one OAuth session
• withRetry.ts handles 429/529 with backoff but cannot try alternate credentials
• claudeAiLimits.ts already tracks per-window utilization (five_hour, seven_day) — this data could inform rotation decisions

The anthropic-ratelimit-unified-5h-utilization and 7d-utilization response headers already provide the signal needed for smart routing.

Use Case

Running multiple parallel Claude Code sessions (main REPL + subagents + background loops) quickly exhausts a single account's limits. With 4 accounts, the theoretical capacity is 4x, but manual switching is impractical during automated workflows.

Alternatives Considered

• LiteLLM proxy: Can rotate API keys but doesn't understand Claude Code's OAuth flow or the unified rate limit headers
• Manual /login switching: Works but is disruptive and can't be automated
• Reducing parallel sessions: Defeats the purpose of agent-heavy workflows

Would love to hear if this is on the roadmap or if there's a recommended workaround.