codex-lb — балансировщик нескольких ChatGPT/Codex-подписок

codex-lb — open-source прокси и балансировщик для ChatGPT/Codex-аккаунтов. Он объединяет несколько подписок в единый пул, следит за доступными лимитами и предоставляет один endpoint для Codex CLI, OpenCode, OpenClaw, Python SDK и других OpenAI-совместимых клиентов.

Практический результат этого руководства: после настройки Codex обращается к codex-lb, а тот сам выбирает подходящий аккаунт для каждого нового запроса.

Что делает codex-lb

Обычный Codex CLI работает через один авторизованный аккаунт:

Codex CLI
    │
    ▼
ChatGPT Account
    │
    ▼
Codex backend

codex-lb добавляет между клиентом и OpenAI промежуточный слой:

                    ┌── Account A
                    │
Codex CLI ─→ codex-lb ── Account B
                    │
                    └── Account C

Клиент больше не работает напрямую с конкретным аккаунтом. Он обращается к одному локальному адресу, а codex-lb решает, какой аккаунт использовать.

Проект умеет:

Сам проект рекомендует Docker как основной вариант запуска.

Как устроена архитектура

В типичной локальной установке схема выглядит так:

           Mac / сервер
                │
           codex-lb :2455
                │
    ┌───────────┼───────────┐
    │           │           │
Account A   Account B   Account C
    │           │           │
    └───────────┼───────────┘
                │
           OpenAI Codex

К одному codex-lb затем можно подключить несколько клиентов:

Codex CLI ──────┐
Codex IDE ──────┤
OpenCode ───────┤
OpenClaw ───────┼──→ codex-lb
Python agent ───┤
другой Mac ─────┘

Для Codex используется endpoint:

http://127.0.0.1:2455/backend-api/codex

Для OpenAI-совместимых клиентов:

http://127.0.0.1:2455/v1

Список доступных моделей codex-lb получает от upstream Codex. Поэтому модель лучше выбирать по текущему ответу /models, а не копировать название из старого руководства.

Как выбирается аккаунт

У codex-lb несколько стратегий маршрутизации.

Capacity weighted

Предпочитает аккаунты с большим доступным запасом квоты. Хороший вариант по умолчанию для обычного пула.

Relative availability

Распределяет запросы между наиболее свободными аккаунтами с учётом их относительной доступности.

Usage weighted

Учитывает недавнее использование аккаунтов.

Round robin

Переключает аккаунты по кругу:

A → B → C → A → B → C

Это предсказуемо, но состояние квот почти не учитывается.

Fill first

Сначала активно использует один аккаунт, затем переходит к следующему.

Sequential drain

Последовательно расходует аккаунты в заданном порядке.

Reset drain

Сильнее учитывает приближение сброса квоты.

Single account

Отключает балансировку и отправляет трафик через один выбранный аккаунт. Полезно для диагностики.

Для обычного использования автор проекта рекомендует начинать с Capacity weighted или Relative availability.

Sticky threads и продолжение диалога

Здесь есть важное техническое различие.

Мягкая привязка

Sticky threads старается оставлять один поток на том же аккаунте. Это помогает сохранять locality и upstream prompt cache:

Thread A → Account 1
Thread B → Account 2
Thread C → Account 1

Если Account 1 становится неудобен для маршрутизации, обычную sticky-привязку можно изменить.

Жёсткая привязка Codex

Некоторые состояния Codex принадлежат конкретному аккаунту:

• previous_response_id;
• conversation state;
• continuation state;
• загруженные файлы.

Такой запрос нельзя произвольно перенести на другой аккаунт.

Поэтому ситуация:

Account A exhausted
Account B healthy

ещё не означает, что любой текущий thread автоматически продолжится через B.

Если продолжение зависит от состояния Account A, codex-lb может вернуть:

No available accounts

При этом новый thread сможет нормально уйти через Account B.

Что понадобится

Для простого локального сценария:

• Docker Desktop или другой Docker runtime;
• один или несколько собственных ChatGPT-аккаунтов с доступом к Codex;
• Codex CLI;
• браузер для первоначальной авторизации аккаунтов.

Сам codex-lb можно запускать и непосредственно через Python/uvx, но Docker проще обновлять, переносить и держать постоянно работающим.

Установка через Docker

Создайте постоянный volume:

docker volume create codex-lb-data

Запустите контейнер:

docker run -d \
  --name codex-lb \
  -p 2455:2455 \
  -p 1455:1455 \
  -v codex-lb-data:/var/lib/codex-lb \
  ghcr.io/soju06/codex-lb:latest

Проверьте контейнер:

docker ps

В списке должен появиться codex-lb.

После запуска откройте:

http://localhost:2455

Это dashboard codex-lb.

Вариант без Docker

Если установлен uv, сервис можно запустить командой:

uvx codex-lb

Локальные данные в этом режиме находятся в:

~/.codex-lb/

Docker хранит их внутри подключённого volume в:

/var/lib/codex-lb/

Эту директорию или volume нужно сохранять при резервном копировании.

Добавление ChatGPT-аккаунтов

Откройте dashboard:

http://localhost:2455

Нажмите Add account и пройдите авторизацию.

После успешного подключения аккаунт появится в пуле. Для каждого аккаунта dashboard показывает состояние и usage. Можно последовательно добавить второй, третий и последующие аккаунты.

Подключение Codex CLI

Основной конфиг Codex находится здесь:

~/.codex/config.toml

Добавьте провайдера:

model = "gpt-5.6-sol"
model_reasoning_effort = "xhigh"
model_provider = "codex-lb"

[model_providers.codex-lb]
name = "openai"
base_url = "http://127.0.0.1:2455/backend-api/codex"
wire_api = "responses"
supports_websockets = true
requires_openai_auth = true

name = "openai" здесь имеет значение: текущая документация codex-lb отдельно требует это написание для корректной работы современного Codex.

Теперь запустите:

codex

Codex будет обращаться к 127.0.0.1:2455 вместо прямого backend-подключения.

Проверка результата

Сначала проверьте API моделей:

curl http://127.0.0.1:2455/v1/models

Сервис должен вернуть JSON со списком доступных моделей.

Затем выполните простой запрос через Codex:

codex exec "Reply with OK only."

Ожидаемый результат:

OK

Теперь откройте dashboard codex-lb. В статистике должен появиться запрос и аккаунт, через который он был выполнен.

Это главный проверяемый результат установки:

Codex
  ↓
codex-lb
  ↓
выбранный аккаунт
  ↓
OpenAI
  ↓
ответ

Проверка WebSocket

Codex может использовать WebSocket transport.

Для диагностического запуска:

RUST_LOG=debug codex exec "Reply with OK only."

При нормальном WebSocket-соединении в логах Codex должны появляться сообщения о подключении к websocket, а в логах codex-lb — запрос:

WebSocket /backend-api/codex/responses

Современные версии Codex могут автоматически откатываться с WebSocket на HTTP, поэтому сам параметр supports_websockets = true не означает принудительный WebSocket-only режим.

API-ключи и удалённый доступ

Если всё работает только на одном компьютере через localhost, дополнительная авторизация proxy по умолчанию не нужна.

Для доступа с других машин лучше включить API Key Auth:

Dashboard
→ API Keys
→ Create

Созданный ключ выглядит примерно так:

sk-clb-...

Полное значение показывается один раз.

Ключ передаётся стандартным заголовком:

Authorization: Bearer sk-clb-...

codex-lb позволяет ограничивать ключи сроком действия, моделями, аккаунтами, токенами, стоимостью, дневными, недельными или месячными лимитами и разрешёнными reasoning effort.

Это позволяет, например, дать отдельному агенту доступ только к части пула:

Agent A ─ API key A ─→ Account 1 + Account 2
Agent B ─ API key B ─→ Account 3

API-key authentication для proxy отключена по умолчанию, а удалённые неаутентифицированные запросы блокируются.

Защита dashboard

Для панели управления существуют три режима:

По умолчанию используется:

CODEX_LB_DASHBOARD_AUTH_MODE=standard

Для удалённой первоначальной настройки создаётся одноразовый bootstrap token.

Посмотреть его при Docker-запуске можно так:

docker logs codex-lb

После установки пароля bootstrap token больше не нужен.

Подключение OpenCode

Для OpenCode используется OpenAI-compatible endpoint:

http://127.0.0.1:2455/v1

Автор codex-lb рекомендует использовать встроенный OpenAI provider OpenCode с заменённым baseURL. Не стоит создавать generic openai-compatible provider: в таком режиме OpenCode может перейти на Chat Completions API и потерять reasoning state.

Минимальная идея конфигурации:

{
  "provider": {
    "openai": {
      "options": {
        "baseURL": "http://127.0.0.1:2455/v1",
        "apiKey": "{env:CODEX_LB_API_KEY}"
      }
    }
  }
}

Так один и тот же пул аккаунтов можно использовать одновременно из Codex и OpenCode.

Один gateway для нескольких агентов

Наиболее интересный сценарий codex-lb появляется, когда он работает как постоянная инфраструктура:

                 codex-lb
                    │
      ┌─────────────┼─────────────┐
      │             │             │
    Pro 1         Pro 2         Pro 3
      │             │             │
      └─────────────┼─────────────┘
                    │
    ┌───────────────┼───────────────┐
    │               │               │
Codex #1        Codex #2        OpenCode
Project A       Project B       Agent C

Клиентам уже не требуется знать, какой ChatGPT-аккаунт сейчас имеет свободную квоту. Они знают один endpoint: codex-lb. Управление аккаунтами переносится на инфраструктурный уровень.

Полезные сценарии

Работа без остановки при исчерпании квоты

Задача: основной аккаунт упёрся в лимит посреди рабочего дня, а задачу нужно закончить.

Условие: в пул добавлены два или больше аккаунтов.

Что делать: оставить стратегию Capacity weighted и начать новый thread. codex-lb сам отправит запрос через аккаунт с наибольшим свободным запасом квоты.

Результат: в dashboard видно, что запрос выполнен через другой аккаунт. Ручное переключение логина в Codex не потребовалось.

Ограничение: продолжение старого thread с состоянием, привязанным к исчерпанному аккаунту, не перенесётся. Начинайте новый.

Один пул для Codex и OpenCode одновременно

Задача: работать в двух инструментах параллельно, не деля лимиты вручную.

Условие: оба клиента настроены по разделам выше: Codex на /backend-api/codex, OpenCode на /v1.

Что делать: просто пользоваться обоими. Запросы обоих клиентов попадают в один пул аккаунтов.

Результат: статистика по всем клиентам собирается в одном dashboard, а список моделей синхронизируется автоматически.

Ограничение: OpenCode нужно подключать через встроенный OpenAI provider с заменённым baseURL. Generic-провайдер переведёт клиент на Chat Completions API и потеряет reasoning state.

Доступ для второго компьютера или коллеги

Задача: дать доступ к пулу с другой машины, не передавая логины ChatGPT-аккаунтов.

Условие: codex-lb доступен по сети, в dashboard включён API Key Auth.

Что делать: создать отдельный ключ в Dashboard → API Keys, при необходимости ограничить его моделями, аккаунтами и дневным лимитом токенов или стоимости. Наружу передаётся только ключ.

Результат: удалённый клиент работает через заголовок Authorization: Bearer sk-clb-..., его расход виден отдельно и ограничен политикой ключа.

Ограничение: без аутентификации запросы с других машин блокируются. Сервис нельзя выставлять в открытый интернет без ключей и закрытой сети.

Где хранятся данные

Для локальной установки через uvx:

~/.codex-lb/

Для Docker:

/var/lib/codex-lb/

По умолчанию используется SQLite. При более сложном развёртывании можно подключить PostgreSQL.

Если codex-lb становится постоянным инфраструктурным узлом, директорию данных нужно включить в резервное копирование.

Ограничения и риски

Это не официальный компонент OpenAI

codex-lb развивается независимо от OpenAI. Изменения Codex backend, механизма авторизации или API могут сломать отдельные функции проекта.

Балансировка не отменяет состояние диалога

Некоторые Codex continuation states принадлежат конкретному аккаунту. Поэтому существующий поток иногда нельзя просто перевести на другой аккаунт. В таком случае новый thread может работать, а продолжение старого — нет.

Квоты не становятся одной официальной квотой

Dashboard показывает пул как единый инфраструктурный ресурс, но на стороне OpenAI это по-прежнему отдельные аккаунты и отдельные ограничения.

Использование должно соответствовать условиям OpenAI

Сам codex-lb предупреждает, что ни одна стратегия маршрутизации не гарантирует безопасность аккаунта и рекомендует нормальные объёмы запросов и соблюдение условий OpenAI. Используйте проект как инфраструктурный инструмент для собственных рабочих аккаунтов, не как способ обхода ограничений платформы.

codex-lb и codex-subscription-router

У codex-subscription-router та же идея «несколько подписок», но другая архитектура.

codex-subscription-router подходит, если задача звучит так: «хочу несколько подписок внутри ChatGPT Desktop». Подробно о проекте мы писали в блоге: Bennett собрал маршрутизатор для нескольких подписок Codex.

codex-lb лучше подходит для сценария: «хочу единый backend для Codex и других агентов».

Для постоянно работающего Mac, домашнего сервера или небольшой агентной инфраструктуры второй вариант универсальнее.

Что делать, если Codex не подключается

Проверить контейнер

docker ps

Если контейнер остановлен:

docker start codex-lb

Посмотреть логи

docker logs codex-lb

Для наблюдения в реальном времени:

docker logs -f codex-lb

Проверить dashboard

Откройте:

http://localhost:2455

Проверить модели

curl http://127.0.0.1:2455/v1/models

Проверить Codex provider

В ~/.codex/config.toml должно быть:

model_provider = "codex-lb"

[model_providers.codex-lb]
name = "openai"
base_url = "http://127.0.0.1:2455/backend-api/codex"
wire_api = "responses"
supports_websockets = true
requires_openai_auth = true

Новый thread работает, старый нет

Вероятная причина — continuation affinity. Создайте новый Codex thread и повторите задачу. Жёстко привязанное состояние старого диалога может принадлежать временно недоступному аккаунту.

Минимальная рабочая конфигурация

Вся установка сводится к четырём действиям.

1. Запустить codex-lb

docker volume create codex-lb-data

docker run -d \
  --name codex-lb \
  -p 2455:2455 \
  -p 1455:1455 \
  -v codex-lb-data:/var/lib/codex-lb \
  ghcr.io/soju06/codex-lb:latest

2. Добавить аккаунты

http://localhost:2455
→ Add account

3. Настроить Codex

model_provider = "codex-lb"

[model_providers.codex-lb]
name = "openai"
base_url = "http://127.0.0.1:2455/backend-api/codex"
wire_api = "responses"
supports_websockets = true
requires_openai_auth = true

4. Проверить

codex exec "Reply with OK only."

Если ответ пришёл, а запрос появился в dashboard, базовая конфигурация работает.

Ссылки

• GitHub — Soju06/codex-lb
• Документация codex-lb
• Настройка клиентов
• Стратегии маршрутизации
• API-ключи
• Авторизация dashboard
• GitHub — b-nnett/codex-subscription-router

Факты, команды и конфигурации проверены по официальной документации codex-lb 20 августа 2026 года.

Следующий шаг

Codex App — единый справочник по среде от OpenAI — если нужно сначала разобраться, какие поверхности Codex существуют и как они связаны между собой.

Связанные материалы

• Статья: Как я разобрал Яндекс.Диск через Codex и официальный доступ Яндекса
• Блог: Codex за пределами кода — что умеет агент OpenAI по версии самих OpenAI
• База знаний: Как поднять свою LLM и подключить к Codex

Если вы строите собственный контур из Codex, нескольких агентов и постоянного AI-сервера, codex-lb может стать единым слоем доступа к моделям и подпискам.

Если захотите обсудить, как это применить у себя или в команде — пишите в Telegram @pimenov