Под «Qoder API» обычно прячутся три разные сущности, и Qoder API: доступ, подключение и ограничения зависят от того, какой ключ вам нужен. Внешний ключ провайдера модели (BYOK) подключает DeepSeek или другого поставщика внутрь Qoder. Personal Access Token аутентифицирует Qoder CLI в автоматизированной среде. Организационный OpenAPI-key даёт доступ к административным endpoints организации. Ниже — разводка по назначению, пошаговое подключение и диагностика ошибок.
Три ключа и их назначение
Разные задачи требуют разных ключей, и путаница между ними — источник большинства ошибок. Сведём их в одну таблицу.
| Ключ | Что делает | Куда вводится | Что тарифицируется |
|---|---|---|---|
| API key провайдера модели (BYOK) | Вызов внешней модели внутри Qoder | Qoder Settings → Models либо CLI /model → Custom |
Условия провайдера; Qoder Credits не расходуются |
QODER_PERSONAL_ACCESS_TOKEN |
Аутентификация Qoder CLI в неинтерактивной среде | Переменная окружения | Подписка Qoder |
| Organization OpenAPI key | Доступ к документированным OpenAPI endpoints организации | Заголовок запроса к API | Права организации |
Внешний ключ провайдера — это ключ, полученный у DeepSeek, Alibaba Cloud Model Studio, Z.ai, Kimi, MiniMax, Xiaomi MIMO, OpenAI, Google или OpenRouter. Документация Qoder перечисляет их как предустановленных провайдеров, а OpenAI Compatible и Anthropic Compatible — как кастомные. Ключ вводится в поле API key при добавлении модели. Расходы идут по условиям провайдера.
Personal Access Token — отдельная сущность. Он аутентифицирует Qoder CLI. Для внешней модели используется отдельный ключ её провайдера. Организационный OpenAPI-key — третий, административный контур. Он действует с правами создателя в рамках модели разрешений продукта, поэтому документация советует создавать такие ключи экономно и ограничивать круг лиц, которые их видят.
QODER_PERSONAL_ACCESS_TOKEN
Переменная окружения QODER_PERSONAL_ACCESS_TOKEN хранит Personal Access Token для неинтерактивных сессий и автоматизированных сред вроде CI/CD. Согласно документации Qoder CLI, токен создаётся и управляется на странице https://qoder.com/account/integrations.
Установка различается по платформе. В Linux и macOS: export QODER_PERSONAL_ACCESS_TOKEN="ваш_токен". В Windows через Command Prompt: set QODER_PERSONAL_ACCESS_TOKEN=ваш_токен — кавычки не использовать, CMD включит их в значение. В PowerShell: $env:QODER_PERSONAL_ACCESS_TOKEN="ваш_токен".
После установки Qoder CLI автоматически использует PAT для аутентификации. Если заданы и переменная, и вход через /login, приоритет у токена из переменной окружения. Чтобы вернуться к учётным данным /login, переменную нужно сначала очистить.
Для выхода из сессии служит /logout (алиас /signout). При аутентификации через QODER_PERSONAL_ACCESS_TOKEN переменную требуется очистить до запуска /logout, иначе следующий старт снова войдёт по этому токену. Проверить состояние помогает /status: панель показывает вкладки Usage и Status с квотой, длительностью сессии и статусом CLI.
Organization OpenAPI key
Организационный OpenAPI-key создаётся из веб-консоли Qoder. Войдите под аккаунтом с правами orgadmin и откройте https://qoder.com/organizations/{orgid}/settings. В левой навигации выберите Settings → Advanced → API keys, нажмите Create API key, укажите имя и срок действия, затем создайте ключ. Документация описывает выбор срока примерно до одного года; истёкший ключ перестаёт работать. Скопируйте ключ сразу и подтвердите I have saved this API key.
Ключ действует с правами, близкими к правам создателя, в рамках модели разрешений продукта. Документация прямо советует создавать ключи экономно и ограничивать тех, кто может их видеть. Метка (label) служит для идентификации ключа в списке, её длина ограничена консолью.
Документация Organization OpenAPI сообщает: ключ показывается один раз. Повторно получить его нельзя: при утрате нужно отозвать ключ и создать новый. Храните его в secret manager и передавайте приложению через предусмотренный механизм секретов. Документация рекомендует заводить отдельный ключ на систему или окружение, чтобы отзыв одного не затрагивал остальные.
Этот ключ относится к административному контуру организации. Он не является универсальным endpoint генерации chat/completions — это разные вещи, и подменять одно другим не стоит.
BYOK в документированном Qoder-клиенте
Официальная документация Qoder описывает добавление собственной модели через Qoder Settings. Порядок такой.
Откройте Settings, затем выберите Models в левой навигации. Нажмите Add model и выберите способ конфигурации. Для предустановленного провайдера выберите провайдера и модель, затем введите API key. Для кастомного endpoint откройте Provider и выберите OpenAI Compatible или Anthropic Compatible в разделе Custom.
Согласно инструкции Custom Models, для OpenAI Compatible выберите Chat Completions API или Responses API. Введите Base URL, API key и хотя бы один Model ID. Чтобы добавить несколько моделей для одного endpoint, нажмите Add Model ID. Для предустановленного провайдера кнопка Get API key открывает страницу управления ключами провайдера. Для кастомного провайдера вводится точный Base URL от сервиса модели; Qoder показывает https://api.example.com/v1 как пример формата.
Далее настройте возможности модели: Display name (Model ID здесь не меняется), Context window с выбором поддерживаемых значений и Default context window, Vision при поддержке изображений, Thinking при поддержке рассуждений с выбором уровней reasoning effort. Нажмите Validate and add model — Qoder проверит соединение и сохранит модель после успешной проверки. После конфигурации модель выбирается в интерфейсе чата.
BYOK в Qoder CLI
Согласно документации Qoder CLI, собственные модели подключаются через BYOK-мастер. Введите /model и переключитесь на вкладку Custom. Выберите Add custom model… и следуйте мастеру: Provider → тип модели → конкретная модель.
Введите API key и прочие данные, которые запросит мастер. После успешной проверки конфигурация сохраняется автоматически, и модель сразу доступна для выбора. Переключившись, вы можете использовать модель в текущей сессии.
Настраивайте BYOK через мастер Custom в /model. Редактировать settings.json вручную не следует. Доступные провайдеры, модели и поля учётных данных определяет BYOK-каталог, доступный текущему аккаунту, — живой каталог мастера Custom служит источником истины.
Документы расходятся в имени CLI: установочные команды используют qodercli, а интерактивные шаги — qoder. Это разные точки входа, и объявлять их взаимозаменяемыми без указания конкретной установки и версии не стоит. Шаги /model и /login относятся к уже запущенному документированному клиенту.
Ограничения и тарификация
Собственные модели тарифицируются напрямую по вашему API-аккаунту у провайдера и не расходуют Qoder Credits. Это ключевое отличие от встроенных моделей, которые списываются единообразно с Qoder Credits.
Согласно странице Custom Models, Repo Wiki использует фиксированную модель и расходует Qoder Credits. При генерации появляется предупреждение о дополнительном списании. Это ограничение действует в клиенте, описанном в документации Qoder.
В том же документированном клиенте генерация изображений и видео недоступна при использовании моделей, подключённых собственным API-ключом (BYOK). Это ограничение относится к описанному клиенту; переносить его на другие поверхности без их собственной документации не следует.
Управление моделями в панели Models включает Edit (обновить API key модели) и Delete (удалить модель, после чего её нельзя использовать). При выполнении управляемых SSH-задач Qoder синхронизирует нужную конфигурацию кастомной модели перед запуском: проверьте модель локально, затем подтвердите нужную модель в удалённой задаче. Если учётные данные не читаются или синхронизация не удалась, следуйте подсказке и переконфигурируйте ключ.
Диагностика ошибок подключения
Если добавление модели не удаётся, документация Qoder перечисляет возможные причины. Проверьте, полон ли Base URL и совпадают ли выбранный совместимый протокол и тип API с endpoint. Убедитесь, что API key корректен, без лишних пробелов, не истёк и не отключён. Проверьте, что Model ID верен и доступен аккаунту провайдера. Убедитесь, что на аккаунте провайдера достаточно средств и сетевое соединение работает.
В Qoder CLI отдельные симптомы имеют свои причины. Если вкладка Custom или пункт добавления отсутствуют, подтвердите, что BYOK доступен для текущего аккаунта и плана. Если провайдер или модель отсутствуют, источник истины — живой каталог мастера Custom. Если проверка ключа не проходит, проверьте, что ключ действителен и что его подписка даёт доступ к выбранной модели.
Секрет не выводите в терминал и логи. Ключ вставляйте только в предназначенное поле, не в чат и не в репозиторий.
Карточка проверки подключения
Готовый артефакт для самопроверки. Заполните его перед подключением и после.
Карточка проверки:
— Клиент: точное название и версия; отдельно укажите клиент Settings → Models или CLI.
— Провайдер: точное имя.
— API protocol: Chat Completions API или Responses API.
— Base URL: из документации провайдера.
— Model ID: из документации провайдера.
— Ключ: вставлен в предназначенное поле, не в чат и не в репозиторий.
— Проверка: клиент Settings → Models — Validate and add model; CLI — /model → Custom → Add custom model → мастер.
— После проверки: выберите модель в текущем чате и дайте маленькую задачу чтения кода без правок.
— Ошибка проверки: пробелы, срок, баланс, совпадение protocol/Base URL/Model ID — без вывода секрета.
Безопасный пробный промпт (чтение файла без правок):
Прочитай открытый файл и перечисли имена его функций и входные параметры. Файлы не изменяй, команды не запускай. Если файл недоступен, назови, какого контекста не хватает.
Это учебный пример для самостоятельной проверки подключения. Редакция не выполняла такой прогон.
Частые вопросы
Что такое Qoder API и какие ключи за ним стоят?
Под этим запросом обычно понимают три разные сущности: внешний ключ провайдера модели (BYOK), Personal Access Token для Qoder CLI и организационный OpenAPI-key. Каждый решает свою задачу и вводится в своё место. Путаница между ними — частая причина ошибок подключения.
Как подключить свою модель по API-ключу в Qoder?
Откройте Settings → Models → Add model. Для предустановленного провайдера выберите его и модель, введите API key. Для кастомного endpoint выберите OpenAI Compatible или Anthropic Compatible, укажите Base URL, API key и Model ID. Нажмите Validate and add model.
Расходует ли BYOK Qoder Credits?
Собственные модели тарифицируются напрямую по вашему API-аккаунту у провайдера и не расходуют Qoder Credits. Отдельно Repo Wiki использует фиксированную модель и расходует Qoder Credits, о чём появляется предупреждение при генерации.
Как аутентифицировать Qoder CLI в CI?
Создайте Personal Access Token на странице https://qoder.com/account/integrations и задайте переменную окружения QODER_PERSONAL_ACCESS_TOKEN. Если заданы и переменная, и вход через /login, приоритет у токена из переменной. Для выхода очистите переменную до запуска /logout.
Почему не проходит проверка ключа при добавлении модели?
Проверьте полноту Base URL и совпадение протокола с endpoint, корректность ключа без лишних пробелов, срок действия, доступность Model ID аккаунту провайдера, баланс и сетевое соединение. В CLI дополнительно подтвердите доступность BYOK для текущего аккаунта и плана.