Cursor модели разных вендоров выбирает сам редактор (автовыбор) или вы вручную для каждого чата и запроса агента, а решать, какая подходит команде, лучше прогоном нескольких моделей на одном наборе задач своего репозитория. Рейтинги в интернете служат лишь подсказкой, с чего начать. Подход подходит командам, у которых есть тесты и человек, готовый читать результаты.
Что выбирают
По документации Cursor, модели приходят от разных вендоров (среди них OpenAI, Anthropic и Google) плюс собственные модели редактора, выбор возможен автоматический и ручной, а расход доступа зависит от выбранной модели. Лучший способ сравнить их на практике — одинаковый набор задач вашего репозитория.
В редакторе одновременно доступно много моделей, и перечень растёт. Выбирать между ними по названию и свежести анонса бессмысленно: сильная на общих тестах модель способна спотыкаться на вашем стеке, а скромная неплохо справляться с вашей рутиной. Единственная надёжная проверка — собственные задачи с проверяемым результатом.
Прежде чем сравнивать, определите, что для вас хорошо. Для одной команды это точность исправлений на старом коде, для другой скорость черновика, для третьей аккуратный маленький diff. Без такого определения любое сравнение превращается в спор вкусов: каждый видит победителя по своему критерию.
Вопросы доступа и оплаты из России мы разбирали отдельно в статье про Cursor в России для команды разработки, подключение внешних инструментов — в материале про Cursor MCP. Здесь один сюжет: как команде выбрать модель по качеству diff, скорости и расходу и записать решение, чтобы его можно было пересмотреть.
Перечень моделей, режимы автовыбора и условия учёта меняются часто, поэтому перед работой откройте раздел о моделях в документации Cursor. Ниже описана логика сравнения, которая переживает смену названий.
Авто или вручную
Редактор предлагает два пути. В автоматическом режиме выбор берёт на себя маршрутизатор Cursor, а вручную вы называете модель для конкретного чата или запроса агента.
| Путь | Как работает | Когда подходит |
|---|---|---|
| Автовыбор | Cursor сам направляет запрос к подходящей модели; режимов автовыбора три: стоимость, баланс и интеллект, а маршрутизатор Cursor, по документации, работает на тарифах для команд и предприятий | Рутинные задачи, быстрый старт, когда нет времени сравнивать |
| Ручной выбор | Вы называете конкретную модель для чата или запроса агента | Критичные изменения и повторяемые результаты |
| Модели Cursor | Собственные модели редактора со своим пулом использования | Частые мелкие запросы с большим числом итераций |
| Сторонние модели | Модели вендоров, расход идёт по их тарифам | Сложные задачи, где нужна конкретная сильная модель |
По справке Cursor, у разных групп моделей расход считается отдельно: собственные модели редактора и сторонние имеют свои пулы использования. Для автовыбора справедливо то же: расход зависит от модели, которая обработала запрос, а пока неизвестно, что выбрала система, ориентироваться на стоимость запроса сложно.
Тариф и политика организации определяют, какие режимы и модели доступны (на части тарифов, по документации, нельзя менять уровень усилия модели), поэтому проверьте, что выбранная модель включена для всех участников эксперимента. Разные права у разных сотрудников дадут разные результаты на одном наборе и испортят вывод.
Для воспроизводимости эксперимента фиксируйте выбор вручную. Автовыбор хорош в работе, но на тестовом наборе он добавляет переменную: два прогона могут пройти через разные модели, и сравнение теряет смысл. Включайте его в сравнение отдельной строкой, как ещё один вариант.
Набор задач
Набор для сравнения собирают из реальной работы репозитория вместо учебных примеров. Он должен отражать вашу сложность: старый код, внутренние соглашения, тесты, которые капризничают.
- Выберите десять-пятнадцать закрытых задач из истории проекта: исправления ошибок, небольшие функции, тесты, рефакторинг, обновление документации.
- Для каждой подготовьте стартовую ветку, текст задачи и признак готовности, например конкретный тест или проверку сборки.
- Зафиксируйте одинаковые условия: те же файлы в контексте, та же формулировка, тот же режим агента.
- Прогоните набор на каждой модели из короткого списка, а результат каждой задачи сохраняйте в отдельной ветке.
- Сравните результаты с эталонным решением из истории и между собой, записывая причины провалов.
Короткий список моделей собирайте из тех, что реально доступны вашей команде по условиям и бюджету. Две-три сильные и одна экономная дают достаточно для вывода. Лишний перебор отнимает время и дробит внимание, а выигрыш от четвёртой модели редко окупает усилия.
Заранее договоритесь, кто и как оценивает результаты, иначе оценки поплывут: лучше, чтобы два человека читали каждый diff независимо, а расхождения разбирали вместе. Это дольше, зато выводы получаются устойчивыми.
Какие задачи вашего репозитория стоило бы взять для сравнения?
Сравнение результатов
Оценивайте результат по нескольким осям сразу. Одной цифры мало: модель, которая решает больше задач, иногда платит за это огромным diff, который читать тяжело.
- Верность: прошёл ли тест и совпадает ли поведение с эталоном.
- Размер diff: сколько файлов и строк затронуто и нет ли побочных правок вне задачи.
- Время: сколько заняла работа агента и сколько потребовалось попыток.
- Подгонка: менялись ли тесты и ослаблялись ли проверки ради зелёного результата.
- Расход: сколько доступа потребовала модель по сравнению с другими на том же наборе.
- Стабильность: повторяется ли результат при втором прогоне той же задачи.
Записывайте ошибки модели словами: «пропустила граничный случай», «изменила соседний модуль», «выдумала функцию». Через десяток задач сложится портрет сильных и слабых сторон каждой, и по нему выбирать удобнее, чем по итоговому числу.
Повторите хотя бы часть набора дважды. Ответы моделей изменчивы, и одна удачная попытка служит слабым доказательством. Если результат прыгает между прогонами, такая модель годится для черновиков, а для задач, где вы рассчитываете принять правку после беглого взгляда, непригодна.
Отдельно отметьте контекст. Модели различаются размером окна, а расширенный контекст у ряда моделей тарифицируется отдельно, и на крупных файлах это решает исход: часть заданий проваливается лишь потому, что нужный фрагмент остался за пределами окна. Что значит этот параметр, объясняет термин контекстное окно.
Решение для команды
По итогам прогона у вас складывается карта: какие модели годятся для каких задач. Её превращают в короткое правило вместо догмы.
Рутинное и повторяемое отдавайте экономной модели или автовыбору. Сложное, рискованное и крупное решайте сильной моделью вручную. Любой результат, который уходит в основную ветку, читает человек.
Добавьте в регламент правило смены модели в середине задачи: переключаться можно, но результат после смены перечитывается заново, потому что стиль и допущения у моделей разные.
Записывайте решение с датой: версии моделей, набор задач, итоговая таблица. Через пару месяцев состав моделей изменится, и вы повторите прогон на том же наборе. Без записи разговор о качестве превращается в обмен впечатлениями, а выбор — в моду.
Сравнение инструментов целиком, помимо моделей внутри одного редактора, полезно смотреть в статье Cursor или Claude Code. Встроить такой отбор моделей и приёмку результата в рабочий процесс команды можно с помощью автоматизации бизнес-процессов с ИИ.