Codex-lb: когда один аккаунт ChatGPT — это слишком мало, а платить за Enterprise — слишком много

Проблема, которую все игнорируют, пока не упрутся в лимит

Представьте: вы запустили автоматизацию в n8n, которая использует ChatGPT для обработки сотен писем в день. Или у вас команда из пяти человек, которые активно работают с API. Или вы просто разрабатываете приложение, которое шлет десятки запросов в час.

В какой-то момент приходит это письмо. Или ошибка в логах. "Rate limit exceeded". Вы уперлись в потолок.

OpenAI в 2026 году все еще держит жесткие лимиты на аккаунты ChatGPT Plus: 40 запросов в час для GPT-4o (да, они все еще так называют свою флагманскую модель, хотя уже есть слухи о GPT-5). Для бизнеса это смешно. Для разработчика — больно.

Codex-lb: простой хак, который работает

Codex-lb — это не корпоративное решение с SLA и поддержкой 24/7. Это open-source инструмент на FastAPI, который делает одну простую вещь: распределяет ваши запросы к ChatGPT между несколькими аккаунтами.

У вас три аккаунта ChatGPT Plus? Codex-lb будет по очереди отправлять запросы через каждый из них. Закончились лимиты на первом — переключится на второй. Все прозрачно для вашего приложения.

Технически это обратный прокси с OpenAI-совместимым API. Вы отправляете запрос на localhost:8000, а Codex-lb решает, через какой аккаунт его пропустить. Поддерживает все основные эндпоинты: /v1/chat/completions, /v1/completions, даже /v1/embeddings.

Установка: пять минут, если у вас уже стоит Docker

Самый быстрый способ — через Docker Compose. Клонируете репозиторий, правите конфиг, запускаете.

git clone https://github.com/yourusername/codex-lb.git
cd codex-lb

Создаете файл accounts.json. Вот как он выглядит для двух аккаунтов:

[
  {
    "name": "account1",
    "api_key": "sk-...",
    "base_url": "https://api.openai.com/v1",
    "weight": 1
  },
  {
    "name": "account2",
    "api_key": "sk-...",
    "base_url": "https://api.openai.com/v1",
    "weight": 1
  }
]

Weight — это вес для балансировки. Если у одного аккаунта больше лимитов, можно поставить weight: 2, чтобы через него шло больше запросов.

Запускаем:

docker-compose up -d

Прокси работает на порту 8000. Теперь вместо прямого вызова OpenAI API ваш код обращается к localhost.

1 Старый код (бьется об лимиты)

import openai
openai.api_key = "sk-ваш-единственный-ключ"
response = openai.ChatCompletion.create(
    model="gpt-4o",
    messages=[{"role": "user", "content": "Привет"}]
)

2 Новый код (работает через прокси)

import openai
openai.api_base = "http://localhost:8000/v1"  # Вот и вся магия
openai.api_key = "any-key-works-here"  # Любой ключ, Codex-lb его проигнорирует
response = openai.ChatCompletion.create(
    model="gpt-4o",
    messages=[{"role": "user", "content": "Привет"}]
)

Видите разницу? Вы меняете только base_url. Ваше приложение даже не знает, что работает через прокси. Это главное преимущество Codex-lb перед костыльными решениями вроде ручного переключения ключей в коде.

А что с альтернативами? Lynkr, OpenClaw и самописные скрипты

Главный конкурент Codex-lb — это, как ни странно, Lynkr. Но Lynkr решает более широкую задачу: работа с разными провайдерами (OpenAI, Anthropic, Google, даже российские GigaChat и YandexGPT). Codex-lb заточен только под OpenAI. Зато делает это лучше.

Если же вам нужно интегрировать AI с бизнес-системами, смотрите в сторону OpenClaw. Особенно его российскую версию с поддержкой GigaChat.

Где Codex-lb сломается (и что делать)

Не все так радужно. Есть сценарии, где Codex-lb бесполезен или даже опасен.

• Длинные диалоги с контекстом. Codex-lb stateless. Следующий запрос в диалоге может пойти через другой аккаунт, который "не помнит" предыдущие сообщения. Решение: использовать встроенные механизмы контекста (отправлять всю историю) или выбрать другой инструмент.
• Высокие требования к безопасности. Все ключи лежат в одном файле. Если сервер скомпрометирован — прощай, все аккаунты. Решение: хранить ключи в HashiCorp Vault или аналогичном хранилище секретов.
• Работа с потоковыми ответами (streaming). Поддерживается, но могут быть проблемы с балансировкой во время стрима.
• Когда нужна не просто балансировка, а интеллектуальная маршрутизация. Codex-lb не умеет отправлять сложные запросы на GPT-4o, а простые — на GPT-3.5 Turbo для экономии. Для этого нужен что-то вроде Lynkr.

Кому подойдет Codex-lb (а кому нет)

Берите Codex-lb, если:

• Вы разработчик, который тестирует приложение с интенсивным использованием ChatGPT API
• У вас небольшая команда (3-5 человек), и вы не хотите платить за Enterprise
• Вы запускаете автоматизации в n8n или аналогичных системах, которые упираются в лимиты
• Вам нужен быстрый и простой способ увеличить пропускную способность без переписывания кода

Смотрите в сторону других решений, если:

• У вас корпоративный проект с требованиями к безопасности и SLA
• Вы работаете с конфиденциальными данными (помните про риски утечек)
• Нужна работа с несколькими провайдерами AI одновременно
• Требуется сложная логика маршрутизации (отправлять разные типы запросов разным моделям)

Что будет дальше? (Спойлер: облачные провайдеры уже догоняют)

Интересно наблюдать, как рынок реагирует на такие инструменты. Уже в 2025 году появились облачные прокси-сервисы, которые предлагают "объединенный пул" аккаунтов ChatGPT за фиксированную плату. По сути — SaaS-версия Codex-lb.

Но open-source решения вроде Codex-lb остаются популярными по одной причине: контроль. Вы не зависите от очередного стартапа, который может закрыться. Ваши ключи не уходят на чужие серверы. Это важно в эпоху, когда атаки на AI-агентов становятся все изощреннее.

Мой прогноз: к концу 2026 года либо OpenAI смягчит лимиты для обычных пользователей (маловероятно), либо появятся десятки аналогов Codex-lb с расширенной функциональностью. Уже сейчас видно движение в сторону "интеллектуальных балансировщиков", которые учитывают не только доступность аккаунтов, но и стоимость токенов, задержку ответа, даже качество генерации.

А пока что Codex-lb — это самый простой способ сказать "rate limit exceeded": "Подожди, у меня есть еще четыре аккаунта".