Repository navigation
[Feature]: Claude account pool — parity with ChatGPT/Codex multi-account routing #294
Description
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 claudesessions 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:
- Add multiple Claude accounts via OAuth (sk-ant-*) or API key, just like the "Codex Auth" page does for ChatGPT
- Quota-aware routing — opencodex polls each account's usage/quota and routes new sessions to the lowest-usage healthy account
- Session affinity — existing threads stay pinned to their account so long-running sessions don't jump mid-conversation
- Cooldown + failover — 429 responses put the account in cooldown; future work fails over to another eligible pool account
- Non-PII labels in the request log, matching the ChatGPT pool's account ordinal display
- 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 claudeviable 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).
Activity
HaydernCenterpoint commentedon Jul 23, 2026
@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 commentedon Jul 23, 2026
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:
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.
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.
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.
docs: add roadmap for untouched issue sweep (WP0)
songwunil commentedon Jul 27, 2026
+1 from another real opencodex user who relies on multiple paid Claude subscriptions.
One scope clarification that may make the implementation path narrower: current
mainalready 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/activeswitching. This is only a request for account-pool routing parity within opencodex.github-actions commentedon Jul 27, 2026
feat(anthropic): opt-in Claude OAuth account pool (#294) (#578)
docs: add roadmap for untouched issue sweep (WP0)
feat(anthropic): opt-in Claude OAuth account pool (lidge-jun#294) (li…