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

В 2026 году Continue был приобретён Cursor, официальный репозиторий прекратил активную поддержку, а облачные Hub и сервис входа отключены. Управление ключами вернулось на локальный уровень: один config.yaml, один .env и несколько ключей шлюза, разделённых по людям и назначению. Статья описывает создание, хранение, несколько моделей, ротацию, политики и диагностику.

Статус: в июне 2026 года Continue был приобретён Cursor, официальный репозиторий переведён в режим только для чтения и прекратил активную поддержку; облачный Hub и сервис входа отключены. Расширение и CLI ещё можно использовать, но активной поддержки нет, и исправления безопасности нужно оценивать самостоятельно.

Товарные знаки: Continue — товарный знак Continue Dev, Inc.; Cursor — товарный знак Anysphere, Inc. Статья носит технический характер и не подразумевает аффилированности или агентских отношений с указанными компаниями; состояние продукта и поля конфигурации определяются официальными страницами и текущей установленной версией.

1. Сначала разберитесь, какие ключи есть в Continue

Выражение «Continue API Key» часто используют в разных смыслах. При настройке встречаются как минимум четыре типа учётных данных с разным происхождением и назначением:

Тип Кто выдаёт Назначение Актуален ли сейчас
Ключ шлюза ZSQH AI Gateway и другие совместимые сервисы Вызов нескольких моделей по OpenAI-совместимому протоколу Да, основная тема статьи
Ключ провайдера OpenAI, Anthropic, Google и другие Прямое подключение к официальному API вендора Да, но поля и адреса отличаются
Локальная модель Без ключа, например Ollama, LM Studio Инференс на своей машине или в локальной сети Да, ключ не нужен
Аккаунт Continue или учётные данные Hub Прежняя платформа Continue Вход, общие ассистенты, синхронизация командных настроек Нет, отключено вместе с Hub

Поэтому «Continue API Key» обычно означает учётные данные модели, которые вы вписываете в поле apiKey, а не универсальный ключ редактора. Статья посвящена ключу шлюза; он часто начинается с sk-, но по нему нельзя войти в Continue и нельзя вызвать интерфейсы прежней платформы.

2. Создание ключа шлюза: сначала границы, потом копирование

До создания определите: кому ключ, в каком проекте используется и какой максимум расхода допустим.

  1. Откройте страницу регистрации ZSQH AI Gateway, зарегистрируйтесь и войдите в консоль.
  2. Перейдите в раздел «API-ключи» и создайте ключ.
  3. В названии укажите пользователя и устройство, например continue-zhang-macbook, а не просто test.
  4. Задайте лимит и срок действия; если консоль поддерживает ограничение по моделям, разрешите только нужные проекту.
  5. Проверьте баланс или статус пополнения, чтобы не обнаружить проблему после настройки.
  6. Скопируйте ключ в менеджер паролей, не отправляя его сначала в мессенджер, тикет или общий чат.

Рекомендуется один ключ на человека и одно устройство на ключ. Общий ключ кажется удобным, но при аномальном расходе не позволяет найти виновника, а после ухода сотрудника непонятно, можно ли отключать его целиком. Модели и цены меняются — ориентируйтесь на страницу «Модели и цены».

3. Храните ключ в .env, а не в config.yaml

Continue поддерживает ссылки на секреты в config.yaml через синтаксис Mustache:

apiKey: ${{ secrets.ZSQH_API_KEY }}

Затем значение переменной задаётся в файле .env:

# ~/.continue/.env
ZSQH_API_KEY=sk-ваш-ключ-шлюза

Несколько деталей:

  • Значение в .env не заключайте в кавычки; следуйте формату официального FAQ KEY=value.
  • Не коммитьте .env в Git, добавьте его в .gitignore.
  • В macOS/Linux можно выполнить chmod 600 ~/.continue/.env, чтобы ограничить права на файл.
  • После изменения .env перезапустите IDE, чтобы расширение перечитало значения.
  • Если config.yaml попадает в репозиторий, оставляйте только ${{ secrets.имя }}, без открытого ключа.

Ключ в YAML тоже будет работать, но как только конфигурацию скопируют, сфотографируют или закоммитят, ключ распространится вместе с ней. С .env и подстановкой конфигурацию можно передавать, а секрет остаётся в личном окружении.

4. Несколько моделей: один ключ на несколько ролей

models в Continue — это список, в который можно добавить несколько записей. У каждой свои name, model и roles, а ключ может быть общим:

name: zsqh-continue
version: 0.0.1
schema: v1

models:
  - name: Основной чат и редактирование
    provider: openai
    model: YOUR_MODEL_ID
    apiBase: https://ai.zhongshangqihang.com/v1
    apiKey: ${{ secrets.ZSQH_API_KEY }}
    roles: [chat, edit, apply]
    capabilities: [tool_use]

  - name: Автодополнение
    provider: openai
    model: YOUR_FIM_MODEL_ID
    apiBase: https://ai.zhongshangqihang.com/v1
    apiKey: ${{ secrets.ZSQH_AUTOCOMPLETE_KEY }}
    roles: [autocomplete]

Два подхода к разделению ключей решают разные задачи:

  • Один ключ на несколько моделей: подходит индивидуальному разработчику — простое управление и централизованный счёт.
  • Ключи по ролям: подходит команде. Чат, дополнение и эмбеддинги используют разные ключи, и при аномалии лимита сразу видно, какой тип запросов виноват.

Разделение ключей — не обязательное требование, а способ отнести затраты. Небольшая команда сначала делит ключи по людям, а когда расход на дополнение вырастает, выносит autocomplete отдельно.

Модель автодополнения должна поддерживать FIM; нельзя брать чат-модель только потому, что она «тоже умеет писать код». Если на шлюзе нет подходящей FIM-модели, можно оставить шлюзу chat, edit и apply, а дополнение перевести на локальную небольшую модель.

5. Переменные окружения и порядок разрешения секретов

При встрече ${{ secrets.X }} Continue ищет значение в следующем порядке:

  1. .env в корне рабочего пространства.
  2. .env в .continue/ рабочего пространства.
  3. Глобальный ~/.continue/.env.
  4. Переменные окружения процесса.

Здесь есть две частые ловушки.

Первая: расширение IDE обычно не видит переменные, экспортированные в терминале. Официальный FAQ прямо указывает, что export OPENAI_API_KEY=... в оболочке не сделает переменную доступной для Continue в VS Code или JetBrains; переменные процесса в основном действуют для Continue CLI. Поэтому «я задал это в терминале» не является результатом диагностики — всё равно нужен .env.

Вторая: .env рабочего пространства имеет приоритет над глобальным. Открывая недоверенный репозиторий, проверьте, нет ли в нём .env; команда должна добавить .env в правила игнорирования.

6. Ротация, отзыв и уход сотрудников

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

  1. Создайте в консоли шлюза новый ключ с теми же правами и лимитом.
  2. Запишите новый ключ в нужный .env, старый некоторое время сохраняйте.
  3. Перезапустите IDE и проверьте Chat, Edit и автодополнение по отдельности.
  4. Убедитесь по журналу шлюза, что новый ключ уже отправляет нормальные запросы.
  5. Понаблюдайте один-два дня и проверьте, не осталось ли забытых клиентов.
  6. Отключите или удалите старый ключ в консоли.
  7. Зафиксируйте дату ротации, ответственного и область влияния.

Если есть подозрение на утечку, порядок обратный: сначала отключите, потом разбирайтесь. Не продолжайте пользоваться ключом «пока наблюдаете» — аномальный расход не будет ждать подтверждения. После отключения проверьте журнал запросов, кривую расхода и записи вызовов моделей, убедитесь в отсутствии неожиданных обращений, затем решайте, менять ли лимиты или правила оповещения.

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

7. Хранение секретов и командные политики

  • Ключ хранится только в менеджере паролей и .env; он не должен попадать в код, скриншоты, тикеты, переписку и запись экрана.
  • Один ключ на человека, лимиты и срок действия по проектам; для общих сервисных аккаунтов создавайте отдельные ключи и ограничивайте круг распространения.
  • Шаблон конфигурации может находиться в репозитории, но только с ${{ secrets.имя }}; каждый участник заполняет значение в своём .env.
  • Раз в месяц сверяйте расход по ключам, моделям и сотрудникам; при аномалии сначала отключайте, потом разбирайтесь.
  • Ведите для команды таблицу соответствия моделей и ключей: назначение, ответственный, лимит, дата ротации.
  • Continue больше не поддерживается, поэтому не полагайтесь на встроенные командные функции плагина; права, аудит и отзыв выполняются на стороне шлюза.
  • Журналы шлюза могут содержать метаданные запросов. Если в коде есть чувствительные данные, сначала уточните политику хранения и логирования шлюза, затем решайте, какие проекты можно подключать.

Ключевой вопрос политики безопасности: чей это ключ, сколько он может потратить и как его остановить при проблеме.

8. Диагностика: 401 и неработающая конфигурация

При 401 проверяйте в таком порядке:

  1. Существует ли .env и где он находится — ~/.continue/.env или в рабочем пространстве.
  2. Совпадает ли имя переменной с ${{ secrets.имя }} в config.yaml, включая регистр.
  3. Нет ли вокруг значения пробелов, кавычек или перевода строки; при копировании из чата чаще всего попадают скрытые символы.
  4. Перезапускали ли IDE после изменения .env.
  5. Не отключён ли ключ, не истёк ли срок, есть ли на аккаунте доступный баланс.
  6. Что загружается фактически — config.yaml или старый config.json.
  7. Указывает ли apiBase на среду, к которой относится ключ; тестовый ключ на продакшен-адресе тоже может дать 401.

Другие частые симптомы:

  • 404: в apiBase лишний или пропущенный /v1, либо ID модели не существует.
  • 429: превышен лимит, скорость или параллельность; сначала изучите тело ошибки и расход, не повторяйте вслепую.
  • Дополнение падает отдельно: проверьте, является ли модель autocomplete моделью FIM и не используется ли другой ключ.
  • Ошибка разбора uses:: Hub отключён; замените удалённую ссылку локальными provider, model, apiKey.
  • Новая модель не видна в селекторе: проверьте отступы YAML, roles и перезагрузку после сохранения.

При диагностике меняйте только одну переменную за раз. Если одновременно менять ключ, адрес и модель, даже восстановление не покажет причину.

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

API-ключ Continue выдаёт сама Continue?

Нет. Continue не выпускает универсальные ключи моделей; вы указываете учётные данные провайдера или шлюза. Прежние вход и облачные сервисы Continue отключены и тем более не могут быть источником ключа.

Почему после export в терминале IDE всё равно возвращает 401?

Continue в VS Code и JetBrains обычно не видит переменные оболочки. Запишите ключ в ~/.continue/.env или .env рабочего пространства и перезапустите IDE. Переменные процесса в основном действуют для CLI.

Можно ли писать ключ прямо в config.yaml?

Работать будет, но не рекомендуется. Конфигурация легко попадает в репозиторий, копируется или фотографируется. Лучше использовать ${{ secrets.имя }}, а открытое значение хранить в .env и менеджере паролей.

Нужны ли разные ключи для разных моделей?

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

Что делать первым делом при утечке ключа?

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

Что дальше

Создайте тестовый ключ в ZSQH AI Gateway, пройдите путь «хранение в .env — ссылка в конфигурации — проверка после перезапуска», затем превратите его в командный шаблон. Доступность моделей и актуальные цены смотрите на странице «Модели и цены».

Читайте также: