[Feature]: Claude account pool — parity with ChatGPT/Codex multi-account routing

[str0203]

Problem to solve

opencodex has a mature ChatGPT/Codex account pool with quota-aware auto-routing, affinity, cooldown, and failover. Claude support exists only as a single account — one OAuth login or one API key.

This is a serious asymmetry for users who rely on Claude for heavy coding workloads:

• Claude Pro/Teams/Enterprise users often have multiple subscriptions across different organizations
• A single Claude account has rate limits that can be exhausted during long agentic coding sessions
• Unlike ChatGPT where the pool automatically picks the lowest-usage account, Claude users must manually switch accounts in the dashboard when they hit a rate limit
• ocx claude sessions that run for hours (SSH, tmux, overnight) have no fallback — they just fail when the single account is throttled

The ChatGPT pool is a first-class feature. Claude deserves the same treatment.

Proposed solution

A Claude account pool that mirrors the existing ChatGPT/Codex pool behavior:

1. Add multiple Claude accounts via OAuth (sk-ant-*) or API key, just like the "Codex Auth" page does for ChatGPT
2. Quota-aware routing — opencodex polls each account's usage/quota and routes new sessions to the lowest-usage healthy account
3. Session affinity — existing threads stay pinned to their account so long-running sessions don't jump mid-conversation
4. Cooldown + failover — 429 responses put the account in cooldown; future work fails over to another eligible pool account
5. Non-PII labels in the request log, matching the ChatGPT pool's account ordinal display
6. Dashboard integration — a new "Claude Auth" page (or a Claude section in the existing auth/dashboard) showing account status, quota, and pool controls

Alternatives considered

• Manual account switching (current state): Works but defeats the purpose of a proxy that should manage routing transparently
• External load balancer: Overkill and defeats the point of having opencodex manage pool state with quota awareness
• Using API key rotation only: Doesn't solve the subscription-based rate limit problem; most Claude users have subscription accounts, not just API keys

Additional context

The ChatGPT pool is a headline feature in the README and a major reason users adopt opencodex. Extending this to Claude would:

• Make ocx claude viable for heavy/production use
• Eliminate the anxiety of "will my Claude session die mid-task?"
• Give Claude parity with ChatGPT in the proxy's feature matrix
• Likely increase adoption among Claude-heavy teams and enterprises

This is not asking for new infrastructure — the pool engine already exists for ChatGPT. It needs to be extended to the Anthropic adapter with Claude-specific quota semantics (RPM/TPM limits, organization-level rate limits).

[HaydernCenterpoint]

@str0203 not like ChatGPT, if you using a claude account pool, most of your account will get banned because he sercurity of Claude is better than ChatGPT so i don't think it a good idea to made a account pool for Claude. You can move to ChatGPT or using a third party provider to use Claude (with cheaper price).

[lidge-jun]

This is a well-structured feature request. The parity argument is sound — the ChatGPT/Codex account pool is a first-class feature, and Claude users doing heavy agentic work face the same multi-account needs.

That said, there are meaningful differences that make a Claude pool more complex than extending the existing engine:

1. Account security model. As @HaydernCenterpoint noted, Claude/Anthropic has stricter session and account policies than ChatGPT. Pool rotation patterns that work for ChatGPT may trigger account-level restrictions with Claude. This needs careful design and testing before shipping.

2. Rate limit semantics. Claude's rate limits (RPM/TPM per organization, per tier) work differently from ChatGPT's per-account quota model. The pool engine's quota-aware routing would need a different health-check and cooldown strategy.

3. OAuth flow differences. Claude OAuth (when available) and API key management have different lifecycle characteristics than the ChatGPT OAuth flow the pool currently uses.

Current status: This is tracked on the roadmap but not prioritized for near-term implementation. The pool engine infrastructure exists and is extensible, but the Claude-specific adaptations need dedicated design work.

We'll keep this open as a feature tracking issue.

[songwunil]

+1 from another real opencodex user who relies on multiple paid Claude subscriptions.

One scope clarification that may make the implementation path narrower: current main already has a generic OAuth multiauth store for stable-identity providers. It persists { activeAccountId, accounts: [...] } (src/oauth/store.ts), but request credential resolution always returns the active account (lines 283-288), and switching is an explicit operation (lines 385-391, management API).

By contrast, the Codex pool already selects the lowest-usage eligible account and applies the configured auto-switch threshold (src/codex/routing.ts), while excluding cooldown and soft-avoid accounts (lines 442-458).

So the requested gap is primarily automatic routing/health selection, not multi-account storage: Anthropic first, and ideally reusable for other stable-identity providers backed by the generic OAuth account set. The practical goal is transparent load balancing across legitimate paid accounts instead of manual PUT /api/oauth/accounts/active switching. This is only a request for account-pool routing parity within opencodex.

[github-actions]