one-api: свой шлюз к ИИ-моделям, ключи, лимиты и журнал расходов

Один ключ в десяти местах

Типичная картина в студии на восемь человек. У дизайнера свой аккаунт в нейросети, у менеджера свой, у программиста ключ лежит в .env на ноутбуке, а два бота в Telegram работают на ключе, который когда-то вставили в чат. Расходы приходят одной суммой с карты директора, кто потратил, не видно. Сотрудник уходит, ключ остаётся в его конфигах.

Шлюз лечит это скучно. Все ходят на один адрес, у каждого свой токен, настоящий ключ знает только шлюз. Токен отзывается за секунду, лимит ставится на человека, расход виден в журнале. Идею одной точки входа я разбирал в статье про magpie, но там шлюз живёт на одном ноутбуке, а здесь на общем сервере компании.

Что я прочитал в коде

one-api написан на Go, интерфейс собирается в тот же бинарник, образ называется justsong/one-api, порт 3000. README предупреждает, что свежий образ может быть alpha, версию надо закреплять. Репозиторий создан 22.04.2023, около 37 тысяч звёзд. Адаптеры есть для OpenAI, Anthropic, Gemini, DeepSeek, Mistral, Groq, xAI, OpenRouter, Ollama и десятка китайских провайдеров.

Лицензия MIT, файл LICENSE в корне. В README добавлена приписка: на странице должна остаться подпись со ссылкой на проект, иначе нужно разрешение автора. Силу этого поверх MIT я не оцениваю, подвал лучше не вырезать.

Ключи провайдеров лежат в таблице каналов, в текстовом поле key. Шифрования я не нашёл. Список каналов в панели отдаётся без ключа, но файл SQLite или дамп базы раскрывает все ключи сразу, значит бэкапы защищаются как сами ключи. Пароли хранятся хешем bcrypt, токены сотрудников по схеме лежат как есть. Первый вход: root с паролем 123456, README просит сменить его сразу.

По умолчанию работает SQLite в каталоге /data. Через SQL_DSN подключается MySQL (README называет версию 8.0) или PostgreSQL, его я нашёл в коде по префиксу postgres://. Журнал выносится в отдельную базу.

Квота считается так: коэффициент группы на коэффициент модели на число токенов запроса и ответа. Лимит ставится на пользователя и отдельно на токен, у токена есть срок, список моделей и разрешённая подсеть. У каналов есть вес и приоритет: основной ключ первый, резервный подхватывает. Автоотключение сломавшегося канала по умолчанию выключено.

Журнал хранит пользователя, имя токена, модель, число токенов, списанную квоту, канал и время ответа. В трёх местах кода, где пишется строка расхода, текста запросов нет, в content лежат коэффициенты. Режим отладки я не смотрел. Оповещение одно: письмо самому пользователю, когда остаток ниже порога (по умолчанию 1000 единиц), нужен SMTP. Сигнала владельцу «ушло втрое больше обычного» я не нашёл, это скрипт поверх API.

Релизы, форк и уязвимости

Последний релиз v0.6.10 вышел 02.02.2025, теги до v0.6.11-alpha.22 датированы 16.02.2025, последний коммит в основной ветке от 21.02.2025 правит ссылку в README. Двадцать месяцев тишины, а обращения в трекере в 2026 году появляются.

Параллельно живёт форк QuantumNous/new-api, в его README прямо сказано, что он сделан на базе One API. На 31.10.2026 там около 51 тысячи звёзд, релиз v1.0.0-rc.47 от 25.10.2026, коммиты от 30.10.2026, четыре последних релиза с пометкой rc. Заявлены SQLite, MySQL, PostgreSQL и ClickHouse для журнала. Лицензия AGPL-3.0 с дополнительными условиями об атрибуции, для тех, кому AGPL не подходит, авторы предлагают отдельное соглашение. Если вы дорабатываете код и даёте доступ к нему по сети, у вас появляются обязанности, это вопрос к юристу. Уязвимости new-api я не изучал и форк не запускал.

На one-api в NVD три CVE. CVE-2025-3801 это XSS в настройках, нужен администратор, оценки низкие. CVE-2026-11465 про погашение кодов пополнения в версиях 0.6.11-preview, тоже низкая. Серьёзная одна, CVE-2026-81027: владелец любого действующего токена может отправить запрос через любой канал, то есть пользоваться ключом провайдера мимо ограничений группы и списка моделей. Оценка 8.5 по CVSS 3.1 от VulnCheck, версии до 0.6.10 включительно.

Я сверил это с кодом основной ветки. У токена с указанием канала есть проверка на администратора, у маршрута /v1/oneapi/proxy/:channelid/ её нет, параметр просто записывается. Обращение #2410 открыто с 12.06.2026. Для нашего сценария это главная дыра: сотрудник с обычным токеном может пойти через дорогой канал. Закрывается на обратном прокси запретом пути /oneapi/proxy, параметр channelid в коде встречается только на нём. Блокировку я не проверял. Ещё в трекере открыты SSRF через image_url (#2387, #2388) и гонка при списании квоты (#2440): по описанию, при одновременных запросах лимит можно превысить. Я их не воспроизводил. Записей в Security Advisories нет.

Что важно учесть

Доступ к API зарубежных провайдеров из России шлюз не решает, он посредник. Дотянется ли ваш сервер до провайдера и на каком основании вы им пользуетесь, вопрос заказчика, инструкций я не даю. Адаптеров GigaChat и YandexGPT в коде нет, через общий OpenAI-совместимый канал их подключение я не проверял.

Если сотрудники присылают в запросах персональные данные клиентов, шлюз входит в обработку. По ч. 5 ст. 18 закона 152-ФЗ при сборе данных граждан России базы должны быть в России, а по ч. 3 ст. 12 до начала трансграничной передачи нужно уведомить Роскомнадзор. Попадает ли ваш поток под эти нормы, решает юрист. Основы я собрал в статье про 152-ФЗ для чат-ботов.

Что можно сделать уже сейчас

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

Второе: поднимите тестовый шлюз отдельно. Docker, закреплённая версия, новый пароль root, HTTPS, доступ по VPN или белому списку, закрытый /oneapi/proxy, PostgreSQL вместо SQLite.

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

Четвёртое: назначьте того, кто смотрит расход, и сделайте скриптом дневной отчёт в Telegram.

Частые вопросы

Нужен ли шлюз, если ИИ пользуются двое?

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

One-api или new-api?

У one-api проще лицензия, но нет релизов с февраля 2025 и висят открытые дыры. У new-api свежий код, зато AGPL и версии rc. Решает то, будете ли вы дорабатывать код.

Можно ли подключить своего Telegram-бота?

README заявляет единый API ко всем провайдерам, бот с OpenAI-совместимым клиентом должен работать с адресом шлюза и своим токеном. Я это не проверял.

Коротко о главном

one-api собирает ключи в одном месте и даёт каждому сотруднику и боту токен, лимит и строку в журнале. Взамен придётся жить с обходом ограничений канала, ключами в базе без шифрования, паролем по умолчанию и проектом без релизов с февраля 2025. Часть лечится настройкой сервера, часть выбором между оригиналом и форком.

Если ИИ у вас уже в работе у нескольких человек и ключи расползаются, я ставлю такой шлюз на вашем сервере, выдаю ключи сотрудникам и ботам, ставлю лимиты, закрываю известные дыры и настраиваю оповещения о расходе. Посмотрите разработку ИИ-агентов и напишите мне в Telegram слово «ПОВОДОК».