Cursor и китайские модели: как настроить и что проверить
Редактор остаётся прежним, модель становится сменной деталью

Cursor удобен, пока не упираешься в лимиты и в оплату. Модель на длинном рефакторинге уходит в throttling, карта не проходит, а редактор нужен сегодня. В этот момент появляется мысль подключить к нему китайскую модель: DeepSeek, Qwen, GLM или Kimi. Технически это возможно, но работает не совсем так, как ждёшь. Ниже разбор без обещаний: что реально переключается, что остаётся за Cursor и где связка ломается.

Зачем менять модель в Cursor

Причин обычно две. Первая связана с деньгами и доступом: китайские модели дешевле на длинных контекстах, а оплата идёт через российский шлюз в рублях. Вторая связана с характером модели. Одной лучше даётся код на Python и SQL, другой разбор чужого легаси на сорок тысяч строк, третья аккуратнее держит формат ответа.

Есть и третья причина, менее очевидная. В Cursor вы выбираете модель не «вообще», а под конкретный режим работы: автодополнение по Tab, чат по открытому файлу, агент с правками в нескольких файлах. Это три разных сценария, и подменяются они по-разному.

Что переключается, а что остаётся у Cursor

Разделим честно, иначе ожидания не сойдутся.

  • Чат и агент — сюда можно подставить свой ключ и свой базовый адрес. Это основной сценарий, ради которого всё делается.
  • Автодополнение по Tab — работает на моделях Cursor и на вашем ключе не едет. Ждать, что Tab начнёт думать китайской моделью, не стоит.
  • Индексация проекта — эмбеддинги считает сервис Cursor, ваш ключ в это не вмешивается.
  • Служебные функции — быстрые правки, названия коммитов и подобное остаются внутренними.

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

Подключение по шагам

В настройках Cursor есть раздел с моделями, а в нём блок для своего ключа OpenAI и поле для замены базового адреса. Логика такая: вы даёте ключ, даёте адрес и вписываете идентификаторы моделей, которые этот адрес отдаёт.

  1. Получите ключ и базовый адрес у шлюза. Нужен адрес, который заканчивается на /v1 и отвечает на /chat/completions.
  2. Включите свой ключ в настройках и вставьте его в поле API key.
  3. В поле замены базового адреса укажите адрес шлюза.
  4. Добавьте модели вручную. Идентификатор нужно скопировать из списка шлюза: deepseek-chat, deepseek-reasoner, кодерные варианты Qwen, GLM, Kimi. Конкретные имена меняются, поэтому сверяйтесь с актуальным списком.
  5. Нажмите проверку и дождитесь зелёного ответа. Если проверка не проходит, дело почти всегда в адресе или в имени модели.
Base URL: https://<адрес шлюза>/v1
Model: deepseek-chat
Проверка: GET /v1/models — в ответе есть нужный идентификатор. Затем короткий POST /v1/chat/completions с вопросом «ответь одним словом». Оба ответа пришли, ключ живой.

Почему агент ведёт себя иначе

Чат прощает многое. Агент нет. В агентском режиме модель получает инструменты: прочитать файл, заменить диапазон строк, запустить команду. Если модель плохо держит формат вызова инструментов, начинается знакомое: правка не применяется, агент повторяет один и тот же шаг, диффы приходят пустыми.

Отсюда практическое правило. Для агента берите модели с крепким function calling и не ставьте reasoning-вариант на каждодневную рутину. Рассуждающая модель полезна, когда надо разобрать причину падения теста. На переименовании переменной в десяти файлах она просто дороже и медленнее.

Где ломается чаще всего

  • Адрес без /v1. Симптом: 404 на проверке.
  • Чужое имя модели. Симптом: 400 или «model not found». Копируйте из списка шлюза.
  • Параметры запроса. Часть моделей не принимает temperature вместе с режимом рассуждений. Если запрос падает на параметрах, начните с минимального набора полей.
  • Размер контекста. Длинный файл плюс история чата упираются в лимит, ответ обрезается. Дробите задачу.
  • Тишина вместо ошибки. Бывает, что ключ в порядке, а модель не тянет инструменты. Проверяется одним запросом с простым tool call.

Проверка за десять минут

Не начинайте с большого рефакторинга. Порядок, который экономит вечер:

  1. Один запрос в чат по открытому файлу. Ответ пришёл, ключ и адрес живые.
  2. Один запрос с чтением файла через инструмент. Пришёл осмысленный ответ, агентская часть работает.
  3. Одна правка в одном файле с показом диффа. Дифф корректный, можно двигаться дальше.
  4. Задача на три файла. Здесь видно, держит ли модель контекст и не путает ли имена.

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

Что это даёт на практике

Главная выгода не в экономии как таковой, а в свободе экспериментов. Можно держать в редакторе две модели и переключать их по задаче: одну для генерации кода, вторую для разбора логов и объяснений. Лимиты одной не блокируют работу, потому что есть вторая.

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

Похожие разборы есть в материалах про OpenAI SDK и китайские модели и про n8n. Если модель ещё не выбрана, начните с чек-листа по выбору.

Что сделать прямо сейчас

  • Проверьте, что у вашего шлюза есть адрес /v1 и список моделей.
  • Прогоните четыре шага проверки на маленьком проекте.
  • Заведите две модели: быструю для рутины и рассуждающую для разборов.
  • Запишите в правила проекта, какие задачи отдаются какой модели. Через месяц это сэкономит больше, чем любой рефакторинг.

Cursor остаётся редактором, модель становится сменной деталью. Как только вы это разделили, выбор перестаёт быть необратимым: не подошла модель, переключили и работаете дальше.