Внутренний прокси-сервер Node.js для OpenAI, Claude и Gemini: сопоставление моделей и повторные попытки

Используйте внутренний прокси с псевдонимами моделей на уровне приложения, когда для одного продукта требуется OpenAI, Claude и Gemini за одним ключом API; в противном случае сохраните прямую интеграцию с поставщиком, если в продукте важны функции, специфичные для поставщика. Краткий ответ: централизуйте выбор модели, повторные попытки, ограничения токенов и проверку стоимости на сервере, а затем позвольте клиенту запрашивать логические возможности, а не идентификатор поставщика. Я проектирую объектное хранилище и слои данных, поэтому не начинаю это решение с демонстрационной подсказки. Я начну с инвариантов: учетные данные остаются за пределами клиента, псевдоним разрешается предсказуемо, повторные попытки не дублируют записи, а правило бюджета оценивается до того, как трафик разветвляется. Унифицированная среда выполнения полезна, поскольку она превращает изменение поставщика в изменение внутренней политики. Он не превращает разные модели в одну и ту же систему. Это запись архитектурного решения для приложения, работающего с Node.js, хотя примером службы является Python, потому что именно его я использую, чтобы сделать поведение HTTP крайне явным. Браузер по-прежнему может вызывать маршрут Node.js, который перенаправляет эту службу; граница имеет большее значение, чем язык. Храните ключ на стороне сервера. Всегда. Каким должен быть внутренний прокси Node.js