Как собрать зоопарк нейросетей в одном API при помощи CCX
Представьте: вы пишете приложение, которое использует Claude для текстов и DALL-E для картинок. Завтра выходит новая Gemini, и вы хотите потестить её. Послезавтра OpenAI меняет формат ответов или у вас просто заканчиваются деньги на одном из аккаунтов. В итоге код обрастает кучей разных SDK, обработчиков ошибок и логикой переключения между ключами. Ситуация, честно говоря, так себе.
Я наткнулся на проект BenedictKing/ccx, который пытается решить эту проблему радикально. Это прокси-шлюз, написанный на Go. Он берет на себя всю грязную работу по трансляции протоколов и управлению ключами. Вы общаетесь с ним по единому стандарту, а он уже договаривается с Claude, Gemini или OpenAI.
Что умеет этот шлюз
Основная фишка CCX — унификация. По сути, это "переводчик", который позволяет использовать один и тот же формат запросов для совершенно разных моделей.
Проект закрывает несколько критичных задач:
- Организация каналов. Вы можете добавить несколько API-ключей для одного провайдера или распределить нагрузку между разными сервисами.
- Умная маршрутизация. Система умеет следить за здоровьем каналов. Если один провайдер "прилег" или выдает ошибки, CCX перекинет запрос на следующий живой ключ.
- Встроенная админка. Разработчик добавил полноценный веб-интерфейс, где можно мышкой настраивать приоритеты, смотреть логи и статистику трафика.
Техническая начинка
Автор выбрал Go, и это оправдано: шлюз должен быть быстрым и потреблять минимум ресурсов. Архитектура проекта монолитная в хорошем смысле слова — фронтенд на React (судя по bun install в инструкции) вшит прямо в бинарник. Это значит, что для деплоя вам не нужно поднимать связку из Nginx, Node.js и базы данных.
CCX работает на одном порту и распределяет запросы по эндпоинтам:
/v1/chat/completions— для чатов в стиле OpenAI./v1/messages— для работы с Claude./v1/images/*— для генерации и правки изображений через DALL-E./v1beta/models/*— для Gemini.
Интересно, что проект поддерживает даже Codex Responses и умеет отслеживать сессии, что полезно для многошаговых диалогов.
Кому и зачем это нужно
В первую очередь, это спасение для команд, которые хотят построить отказоустойчивую систему. Если ваш бизнес завязан на одну LLM, вы рискуете. CCX позволяет настроить схему failover: если Claude не отвечает, запрос автоматически уходит в GPT-4 или Gemini.
Другой сценарий — экономия и лимиты. Можно закинуть десяток бесплатных или дешевых ключей, выставить им приоритеты и лимиты, а CCX будет ротировать их, чтобы вы не упирались в Rate Limits провайдеров.
Как запустить
Развернуть систему можно тремя способами. Самый быстрый — Docker.
docker run -d \
--name ccx \
-p 3000:3000 \
-e PROXY_ACCESS_KEY=ваш-секретный-ключ \
-e APP_UI_LANGUAGE=en \
-v $(pwd)/.config:/app/.config \
crpi-i19l8zl0ugidq97v.cn-hangzhou.personal.cr.aliyuncs.com/bene/ccx:latest
После запуска идете на localhost:3000, заходите в админку и начинаете добавлять каналы. Для каждого канала можно задать свои заголовки, прокси-серверы и маппинг моделей. Например, можно сказать шлюзу: "когда я прошу модель super-ai, на самом деле отправляй запрос в Claude 3.5 Sonnet".
Если вы предпочитаете "голый" металл, в релизах лежат готовые бинарники под разные ОС. Нужно только создать рядом файл .env с настройками доступа.
Мои впечатления
Проект выглядит добротно, особенно радует наличие визуального контроля. Часто такие прокси — это просто конфиг-файл на три тысячи строк, в котором невозможно разобраться. Здесь же графики, статус-коды и наглядное управление приоритетами.
Из минусов — документация пока не самая подробная, некоторые детали приходится выуживать из исходников на Go. Также стоит учитывать, что проект активно развивается, так что перед обновлением лучше делать бэкап конфигов.
Стоит ли пробовать? Если вы устали переписывать интеграции под каждую новую нейронку или хотите централизованно управлять ключами всей команды — однозначно да. Это хороший промежуточный слой, который развязывает руки и избавляет от вендор-лока.
Для тех, кто хочет покопаться в коде или внести свой вклад, проект открыт под лицензией MIT. Можно заглянуть в Makefile — там все стандартно: make build для сборки и make dev для быстрой разработки.
