Как я настроил Codex-LB для Codex: работа без ручного переключения аккаунтов

Как я настроил Codex-LB для работы с Codex без постоянного переключения аккаунтов

29/05/2026 7 Минут чтения

Личный опыт настройки Codex-LB: как я подключил несколько аккаунтов, убрал ручное переключение в IDE, настроил Codex через локальный endpoint и какие риски нужно учитывать перед использованием такого инструмента.

Когда начинаешь активно работать с Codex, AI-агентами и генерацией кода прямо в IDE, лимиты быстро перестают быть мелкой технической неприятностью. Они ломают рабочий поток: задача ещё не закончена, контекст в голове есть, а инструмент уже просит подождать или переключиться на другой аккаунт. Я долго терпел ручное переключение, пока не попробовал Codex-LB — open-source прокси и load balancer для ChatGPT/Codex-аккаунтов.

Table of Contents

Почему я вообще начал искать такое решение

Я активно использую Codex в разработке: прошу его разбирать код, находить ошибки, готовить миграции, писать тесты, проверять UI-логику, собирать промпты для доработок и проходить большие куски проекта.

В таком режиме лимиты ощущаются не как абстрактное ограничение, а как прямой удар по рабочему процессу.

Типичная ситуация:

работаешь в VS Code;
держишь в голове контекст задачи;
Codex уже разобрал проект;
ты идёшь итерациями: исправление → проверка → уточнение → новая правка;
в какой-то момент упираешься в лимит;
приходится выходить из потока, переключать аккаунт, заново настраивать окружение или ждать.

Вроде бы мелочь. Но на практике это ломает темп.

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

Именно эту боль я и хотел закрыть.

Что такое Codex-LB

Codex-LB — это open-source инструмент, который работает как промежуточный proxy/load balancer между AI-клиентами и ChatGPT/Codex-аккаунтами.

Если объяснять проще, он становится единой точкой входа для клиентов вроде Codex CLI, OpenCode или других OpenAI-compatible клиентов.

Схема выглядит так:

Codex CLI / VS Code / OpenCode / SDK
        ↓
     Codex-LB
        ↓
несколько подключённых ChatGPT/Codex-аккаунтов

Вместо того чтобы каждый раз вручную думать, через какой аккаунт сейчас работать, я направляю клиент на Codex-LB. Дальше сервис сам маршрутизирует запросы между добавленными аккаунтами.

Важно: Codex-LB не создаёт новые лимиты из воздуха. Он не взламывает платформу и не отменяет ограничения. Он просто распределяет нагрузку между теми аккаунтами, которые ты сам подключил.

Что умеет Codex-LB

По возможностям это не просто маленький скрипт, а полноценный сервис вокруг работы с AI-клиентами.

Ключевые функции:

подключение нескольких ChatGPT/Codex-аккаунтов;
балансировка запросов между аккаунтами;
dashboard для управления;
учёт использования;
статистика по токенам и расходу;
API-ключи для клиентов;
лимиты по ключам;
поддержка Codex CLI;
поддержка OpenCode;
OpenAI-compatible endpoint;
синхронизация доступных моделей;
запуск через Docker;
локальное хранение данных;
поддержка SQLite по умолчанию;
возможность более серьёзной установки с PostgreSQL.

Для меня главным было не всё это сразу, а три вещи:

убрать ручное переключение аккаунтов;
подключить Codex в VS Code через один endpoint;
видеть более предсказуемую рабочую схему вместо хаоса.

Как я это развернул

Я запускал Codex-LB через Docker. Это самый простой и понятный вариант.

Команды запуска:

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

После запуска dashboard доступен на локальном порту:

http://localhost:2455

Если сервис запускается не строго локально, а на отдельной машине в локальной сети, при первом входе может понадобиться bootstrap token. Его можно посмотреть в логах контейнера:

docker logs codex-lb

В логах будет строка с first-run token для первичной настройки dashboard.

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

Дальше логика такая:

открыть dashboard;
пройти первичную настройку;
добавить аккаунт;
пройти авторизацию через ссылку;
после редиректа скопировать URL обратно в wizard;
повторить для каждого аккаунта;
создать API key для клиента;
включить API Key Auth в настройках.

Сам процесс несложный, но здесь нужно быть аккуратным. Это не тот инструмент, который стоит настраивать на бегу и открывать наружу без понимания, что именно ты делаешь.

Настройка Codex в VS Code

Я использую Codex через VS Code и SSH-сценарий, поэтому мне было важно, чтобы IDE могла ходить к Codex-LB по локальному сетевому адресу.

Пример конфигурации:

model = "gpt-5.5"
model_reasoning_effort = "medium"
model_provider = "codex-lb"

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

[projects."/srv/healthpad"]
trust_level = "trusted"

Здесь важно заменить IP-адрес на свой.

Если Codex-LB стоит на той же машине, можно использовать:

base_url = "http://127.0.0.1:2455/backend-api/codex"

Если включена авторизация по API-ключу, ключ лучше передавать через переменную окружения:

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

А сам ключ задать отдельно:

export CODEX_LB_API_KEY="sk-clb-..."

После этого Codex можно запускать как обычно, а запросы будут идти через Codex-LB.

Что изменилось в работе

Главное изменение — я перестал думать о переключении аккаунтов во время задачи.

Раньше процесс выглядел так:

работаю → упёрся в лимит → переключаюсь → теряю темп → возвращаюсь к задаче

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

работаю → Codex-LB сам маршрутизирует запросы → продолжаю задачу

Это не делает Codex безлимитным. Если все подключённые аккаунты исчерпаны, лимит всё равно догонит. Но при нормальной нагрузке поток становится заметно ровнее.

Для меня основная польза не в красивой формулировке «увеличить лимиты», а в другом: меньше ручных действий, меньше переключений, меньше потери контекста.

Почему это важно именно для разработки

В обычном чате с ИИ пауза не всегда критична. Можно вернуться позже.

В разработке всё иначе. Когда ты работаешь с кодовой базой, у тебя в голове держится сразу несколько слоёв:

что именно сломано;
какие файлы уже менялись;
какие тесты падали;
какую гипотезу проверяешь;
какие ограничения нельзя нарушать;
что уже пробовал Codex;
что нужно проверить следующим шагом.

Когда в этот момент инструмент упирается в лимит и требует ручного переключения, ломается не только сессия. Ломается рабочее состояние.

Поэтому такие инструменты, как Codex-LB, важны не потому, что они «экономят пару кликов». Они уменьшают трение между мыслью и действием.

Где Codex-LB действительно полезен

Я вижу несколько сценариев, где инструмент оправдан.

1. Личная разработческая среда

Если ты регулярно используешь Codex, работаешь с большими проектами и делаешь много итераций в день, Codex-LB может стать нормальной частью локального AI-стека.

2. Несколько собственных аккаунтов

Если у тебя есть несколько личных аккаунтов и ты не хочешь вручную прыгать между ними, балансировщик делает схему удобнее.

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

3. Единая точка входа для разных клиентов

Codex-LB можно использовать не только с Codex CLI. Он даёт OpenAI-compatible endpoint, поэтому его можно подключать к другим клиентам, которые умеют работать с таким API.

4. Учёт расхода

Отдельная полезная функция — dashboard и usage tracking. Когда AI-инструменты становятся частью ежедневной работы, полезно видеть не только результат, но и расход: токены, стоимость, нагрузку, активность аккаунтов.

Где начинается серая зона

Здесь нужно быть честным. Codex-LB — удобный инструмент, но использовать его бездумно нельзя.

Главный риск — условия использования платформы.

Если применять такой proxy как способ нарушать правила, передавать доступ третьим лицам, продавать доступ к аккаунтам или обходить ограничения, это уже не «оптимизация рабочего процесса», а потенциальное нарушение.

Я не рассматриваю Codex-LB как инструмент для перепродажи доступа, шаринга аккаунтов или массового обхода ограничений. Для меня это локальная техническая утилита, которая помогает убрать ручную рутину в собственной рабочей среде.

Перед использованием стоит самостоятельно проверить:

условия OpenAI/ChatGPT;
правила своего тарифа;
допустимость работы через прокси;
риски блокировки;
кто имеет доступ к dashboard;
где хранятся ключи;
открыт ли сервис наружу;
включена ли авторизация;
есть ли резервная копия данных.

Если есть сомнения — лучше не использовать такую схему или ограничиться локальной тестовой установкой.

Безопасность: что я бы не игнорировал

Codex-LB нельзя воспринимать как безобидную игрушку. Через него проходят запросы, ключи и доступ к аккаунтам. Поэтому минимальная гигиена обязательна.

Что я считаю важным:

не открывать dashboard в публичный интернет;
использовать пароль для dashboard;
включить TOTP, если используешь удалённый доступ;
включить API Key Auth;
не хранить ключи в публичных репозиториях;
не вставлять ключи прямо в конфиги проекта;
использовать переменные окружения;
ограничить доступ по локальной сети или VPN;
обновлять контейнер;
следить за issues и changelog проекта;
делать backup volume;
не запускать это на случайном VPS без защиты.

Самая плохая идея — поднять Codex-LB на сервере, открыть порты наружу и оставить слабую авторизацию. Это прямой путь к утечке доступа.

Что мне понравилось

У Codex-LB есть несколько сильных сторон.

Во-первых, он решает конкретную боль. Не абстрактную, а очень практическую: несколько аккаунтов, несколько клиентов, ручное переключение, лимиты, потеря темпа.

Во-вторых, запуск через Docker действительно простой. Не нужно собирать сложную инфраструктуру.

В-третьих, есть dashboard. Это важно, потому что без интерфейса подобный инструмент быстро превращается в непонятный чёрный ящик.

В-четвёртых, поддержка OpenAI-compatible endpoints делает его гибким. Можно использовать не только один конкретный клиент.

Что не понравилось и где я бы был осторожен

Первое — сама природа инструмента. Он находится рядом с чувствительной зоной: аккаунты, лимиты, проксирование, ключи. Поэтому его нельзя советовать всем подряд как «просто поставьте и забудьте».

Второе — зависимость от изменений upstream-сервисов. Если OpenAI, Codex CLI или другой клиент меняет поведение, прокси может сломаться или потребовать обновления.

Третье — дополнительная точка отказа. Раньше клиент ходил напрямую. Теперь между ними появляется ещё один слой. Если Codex-LB упал, неправильно настроен или конфликтует с клиентом, ломается весь workflow.

Четвёртое — ложное ощущение безлимита. Его быть не должно. Инструмент распределяет нагрузку, но не отменяет ограничения.

Стоит ли использовать Codex-LB

Если ты пару раз в неделю открываешь ChatGPT в браузере, Codex-LB тебе не нужен.

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

Мой вывод такой:

Codex-LB полезен не как способ «обмануть лимиты», а как способ привести в порядок собственный AI-workflow. Он убирает ручную рутину, даёт единую точку входа, помогает с учётом расхода и делает работу в IDE более непрерывной.

Но это инструмент для тех, кто понимает, что делает. Его нужно запускать аккуратно, локально или за нормальной сетевой защитой, не шарить доступы и не превращать в публичный gateway.

Мой итог

Для меня Codex-LB оказался полезным. Он не стал волшебной кнопкой и не отменил ограничения, но решил конкретную проблему: убрал ручное переключение аккаунтов и сделал работу с Codex более ровной.

Я бы описал его так: это маленький инфраструктурный слой для тех, кто уже использует ИИ в разработке серьёзно, а не просто время от времени задаёт вопросы в чате.

Чем активнее AI-инструменты входят в рабочий процесс разработчика, тем больше появляется таких промежуточных решений: прокси, dashboard, usage tracking, локальные настройки, свои правила маршрутизации. Это нормальный этап взросления инструментов.

Главное — не путать инженерную оптимизацию с нарушением правил платформы. Использовать такие решения можно, но только осознанно: на своих аккаунтах, в своей среде, с нормальной защитой и пониманием рисков.