// the find
Soju06/codex-lb
Codex/ChatGPT multiple account load balancer & proxy with usage tracking, dashboard, and OpenCode-compatible endpoints
A load balancer and reverse proxy that pools multiple ChatGPT/Codex consumer accounts behind an OpenAI-compatible API, with a web dashboard, per-key rate limits, and usage tracking. It's aimed at developers who want to use Codex CLI or OpenCode against their personal ChatGPT accounts without hitting per-account rate limits. The practical use case is pooling free or Plus accounts to get more throughput — which puts it squarely in ToS-gray territory with OpenAI.
The WebSocket transport handling is genuinely careful: it auto-detects native WebSocket vs. SSE per request, respects standard proxy env vars (wss_proxy, https_proxy, all_proxy), and logs enough detail to diagnose fallback behavior without guessing. Per-key rate limiting by tokens, cost, and time window — not just request count — is the right abstraction for LLM usage control and most proxies don't do it. The three-tier dashboard auth (built-in password+TOTP, trusted reverse-proxy header with CIDR lock, or disabled) covers real deployment scenarios without forcing one approach on everyone. The Helm chart with multi-replica session affinity via headless-service DNS is a legitimate operational concern that's actually been solved rather than left as an exercise.
The repo has 70+ Alembic migrations in roughly four months of history — that's a schema that kept changing its mind, and anyone upgrading through a gap will hit merge migrations and multiple branch-point heads. There's no documented strategy for what happens when a pooled account gets banned or suspended mid-request beyond logging the rate-limit; account health is treated as a binary rate-limited/not state rather than a degraded one. The .agents/ directory with OpenSpec skills, skill guards, and post-edit tracker hooks suggests the codebase is substantially AI-agent-maintained, which isn't inherently bad but does mean the consistency and reasoning in less-exercised code paths may be uneven. The configuration surface is large enough to be genuinely confusing — CODEX_LB_UPSTREAM_STREAM_TRANSPORT, session bridge advertise URLs, firewall CIDR lists, bootstrap tokens, and sticky session kinds all interact in non-obvious ways, and the docs don't give you a decision tree for which settings actually matter for a given deployment shape.