Дизайн аутентификации OpenRouter и управления моделями

Этот документ описывает цели дизайна, стоящие за потоком аутентификации OpenRouter и сопутствующими изменениями в управлении моделями. Он намеренно фокусируется на продуктовых и архитектурных решениях, а не на истории реализации.

Цели

Позволить пользователям аутентифицироваться в OpenRouter как через CLI, так и через /auth.
Повторно использовать существующий путь провайдера, совместимого с OpenAI, вместо добавления нового типа аутентификации для OpenRouter.
Сделать первый запуск удобным, не требуя от пользователей немедленно управлять сотнями моделей.
Сохранить четкий путь к более богатому управлению моделями через /manage-models.

Аутентификация OpenRouter

OpenRouter интегрируется как провайдер, совместимый с OpenAI:

тип аутентификации: AuthType.USE_OPENAI
настройки провайдера: modelProviders.openai
переменная окружения для API-ключа: OPENROUTER_API_KEY
базовый URL: https://openrouter.ai/api/v1

Это позволяет избежать введения специфичного для OpenRouter типа AuthType, когда путь провайдера в рантайме уже совместим с OpenAI. Такой подход сохраняет согласованность статуса аутентификации, разрешения моделей, выбора провайдера и схемы настроек с существующей абстракцией провайдера.

Пользовательские потоки выглядят так:

/auth → OpenRouter для интерактивного TUI-потока.
Переменные окружения для автоматизации или прямой настройки API-ключа: OPENROUTER_API_KEY плюс OPENAI_BASE_URL=https://openrouter.ai/api/v1.
~/.qwen/settings.json для скриптовой настройки, требующей явных записей провайдера модели.

Браузерный OAuth использует PKCE-поток OpenRouter и записывает полученный API-ключ в настройки перед обновлением аутентификации как AuthType.USE_OPENAI.

Управление моделями

OpenRouter предоставляет большой динамический каталог моделей. Запись каждой обнаруженной модели в modelProviders.openai сделала бы /model загроможденным и превратила бы долгосрочное поле настроек в кеш удаленного каталога.

Ключевое архитектурное разделение:

Каталог: полный набор моделей, обнаруженных из источника, такого как OpenRouter.
Включенный набор: меньший набор моделей, которые должны отображаться в /model и сохраняться в пользовательских настройках.

В начальном потоке OpenRouter аутентификация должна завершаться полезным включенным набором по умолчанию, не отвлекая пользователя большим выбором. Рекомендуемый набор должен быть небольшим, стабильным и ориентированным на модели, которые позволят пользователям успешно опробовать продукт, включая бесплатные модели, если они доступны.

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

`/manage-models`

Более богатое управление моделями принадлежит отдельной точке входа /manage-models. Этот поток должен позволять пользователям:

просматривать обнаруженные модели;
искать по идентификатору, отображаемому имени, префиксу провайдера и производным тегам, таким как free или vision;
видеть, какие модели в данный момент включены;
включать или отключать модели пакетами.

Измерение источника должно оставаться частью этого дизайна. OpenRouter — только первый источник динамического каталога; будущие источники, такие как ModelScope и ModelStudio, должны вписываться в ту же схему. Сложность UI может быть уменьшена, но базовая абстракция источника должна оставаться доступной как точка расширения.

Текущие границы

Это изменение должно сделать минимум, необходимый для приятной аутентификации OpenRouter и настройки моделей:

OAuth или аутентификация по ключу настраивает OpenRouter через существующий путь провайдера, совместимого с OpenAI.
Начальный включенный набор моделей подбирается, а не выгружается полный каталог в настройки.
Полное хранение каталога, просмотр, фильтрация и пакетное управление откладываются до /manage-models.

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