Лимиты Cursor Ultra: как проверить пулы, on-demand и расходы
Практическое руководство для соло-разработчиков с высокой нагрузкой: как различать два месячных пула Cursor Ultra и недельный лимит Grok Bot, оценивать on-demand и ограничивать дополнительные расходы.
Содержание
Вы платите $200 в месяц за Cursor Ultra, но всё равно видите предупреждение о приближении к лимиту. Самая дорогая ошибка — решить, что все проценты относятся к одному общему пакету, и сразу выбрать No Limit. Сначала выясните, какой именно счётчик растёт, затем оцените, стоит ли непрерывная работа дополнительных расходов, и только после этого задайте приемлемый месячный предел.
Главное: у Ultra нет одного общего счётчика
По состоянию на 27 сентября 2026 года Cursor указывает, что планы Pro, Pro Plus и Ultra включают два независимых пула, каждый из которых обновляется вместе с месячным расчётным циклом: Cursor Models и Other Models. Ultra стоит $200 в месяц и включает оба пула, но скорость расходования зависит от выбранной модели.
- Cursor Models сейчас включает Grok 4.7, Grok 4.6, Grok 4.5 и Composer 2.5. Cursor пишет, что в этом пуле доступно значительно больше включённого объёма.
- Other Models используется для явно выбранных сторонних моделей; расход рассчитывается по API-тарифу конкретной модели.
Поэтому фраза «в Ultra использовано 80%» сама по себе ничего не диагностирует. Нужно понять, заканчивается ли Cursor Models, Other Models или отдельный недельный лимит какой-либо функции.
Например, на опубликованном пользователем скриншоте из X одновременно были показаны 72% месячного расхода Cursor Models и 90% недельного лимита Grok Bot. Это разные счётчики. Предупреждение Grok Bot не доказывает, что один из двух месячных пулов Ultra уже исчерпан.
Сначала определите счётчик, потом меняйте настройки оплаты
Надёжнее всего сопоставить место предупреждения, выбранную модель и записи в биллинге, а не пытаться угадать остаток токенов.
| Что вы видите | Что это обычно означает | Следующее действие |
|---|---|---|
| Растёт процент Cursor Models | Grok или Composer расходует пул Cursor Models | Проверьте остаток Other Models и решите, подходит ли другая модель задаче |
| Растёт процент Other Models | Выбранная сторонняя модель расходует объём по своему API-тарифу | Проверьте дорогие модели, длинный контекст и частые Agent-задачи |
| Grok Bot предупреждает о недельном лимите | Заканчивается недельная квота конкретной функции | Дождитесь недельного сброса или сократите её использование; не путайте с месячным пулом Ultra |
| Included Usage и On-Demand Usage показаны отдельно | Включённый объём и дополнительное потребление учитываются разными строками | Проверьте, включён ли on-demand и задан ли лимит расходов |
Проверка за три минуты с наблюдаемым результатом
- Откройте настройки редактора Cursor или usage dashboard и запишите проценты Cursor Models и Other Models, а также дату месячного обновления. По документации оба пула видны в этих местах.
- Вернитесь к последней тяжёлой задаче и проверьте фактически выбранную модель. У моделей разные тарифы, поэтому число запросов не показывает стоимость.
- В разделе Billing & Invoices сравните Included Usage и On-Demand Usage. Если во второй строке уже есть сумма, вы расходуете деньги сверх включённого объёма подписки.
- Откройте Spending: проверьте, включён ли on-demand, какой установлен месячный предел и не выбрано ли No Limit.
- Выполните одну небольшую задачу с чёткими границами, например рефакторинг одного файла, и снова посмотрите, какой пул или строка биллинга изменились.
Если всплывающее предупреждение сформулировано неясно, ориентируйтесь на два пула и строки счёта в своём dashboard. Скриншот, ответ в чате или отдельный баннер не заменяют актуальные данные вашей учётной записи.
Когда on-demand действительно оправдан
On-demand имеет смысл, когда ценность непрерывной работы выше дополнительной суммы, которую вы готовы заплатить. В документации Cursor о usage-based charges сказано, что на индивидуальном плане on-demand нужно включить явно; запросы сверх включённого объёма оплачиваются по API-тарифам и отображаются отдельно от подписки.
Обычно on-demand подходит, если одновременно выполняются три условия:
- У вас есть релиз, исправление или миграция с конкретным сроком, а цена задержки понятна.
- Оставшаяся работа ограничена: например, два ревью или один определённый модуль, а не бесконечный цикл Agent.
- Вы готовы проверять расход после каждой тяжёлой задачи и остановиться при достижении бюджета.
Лучше пока не включать on-demand, если:
- вы ещё не определили, какой пул расходуется;
- параллельно работают несколько Agents, автоматизации или задачи с длинным контекстом, поэтому стоимость трудно предсказать;
- у вас жёсткий личный бюджет или работу можно перенести на следующий расчётный цикл;
- во втором включённом пуле ещё есть объём и подходящая для задачи модель.
On-demand не возвращает «безлимитное» использование моделей. Он разрешает продолжать работу с тарифицируемым расходом сверх включённого объёма. Это средство против остановки, а не автоматический контроль бюджета.
Как задать лимит расходов без гадания
Безопасный предел — не «рекомендация платформы», а максимальная дополнительная сумма, которую вы согласны заплатить в текущем цикле. После включения on-demand в разделе Spending можно задать месячный лимит для индивидуального плана. В документации Cursor о spend limits прямо сказано: No Limit снимает ограничение.
Для первого лимита используйте простой бюджетный расчёт:
- Посчитайте оставшиеся тяжёлые рабочие сессии, а не просто дни до конца месяца.
- Определите максимально допустимую дополнительную сумму.
- Разделите её на число тяжёлых сессий и получите порог для ручной проверки.
- Установите общий месячный предел в Cursor и после каждой сессии сравнивайте фактический расход с этим порогом.
Допустим, вы готовы доплатить максимум $40, а до сброса ожидается ещё десять тяжёлых Agent-сессий. Тогда $4 на сессию можно использовать как внутренний сигнал для проверки. Это не лимит Cursor на одну задачу и не гарантия цены — лишь способ раньше заметить аномально дорогой запуск.
Два нюанса работы лимита
Во-первых, изменение лимита применяется сразу, но блокировка расхода срабатывает не мгновенно. Cursor предупреждает, что потребление может ненадолго превысить предел до того, как система его распознает. Ограниченный перерасход до срабатывания записывается как временный spend-limit credit, а счёт выставляется не выше текущего лимита.
Во-вторых, если повысить лимит в том же расчётном цикле, Cursor может начислить часть или весь ранее зачтённый credit — до нового предела. Чтобы сохранить этот credit, не меняйте лимит или отключите on-demand.
Для соло-разработчика конечный предел обычно безопаснее, чем No Limit. Снимать ограничение стоит только тогда, когда вы осознанно принимаете неограниченный этой настройкой дополнительный расход до конца цикла и регулярно следите за счётом.
Продолжать платить или менять процесс разработки
Решение зависит от того, какой пул заканчивается, насколько срочна задача и повторяется ли такой расход каждый месяц.
| Ситуация | Что выбрать в первую очередь | Почему |
|---|---|---|
| Cursor Models почти пуст, Other Models ещё доступен | Перенесите только подходящие сложные задачи на стороннюю модель, а рутину оставьте в Cursor Models | Второй пул можно использовать, но сторонняя модель списывает объём по своему API-тарифу |
| Other Models почти пуст, Cursor Models ещё доступен | Отдайте Grok или Composer рутинный код, переписывание и исследование | Вы используете оставшийся включённый пул и сохраняете дорогую модель для задач, где она действительно нужна |
| Оба пула близки к пределу, но осталась одна срочная задача | Включите on-demand с конечным месячным лимитом | Ценность непрерывности понятна, а финансовый риск ограничен |
| Оба пула заканчиваются рано каждый месяц, часто работают параллельные Agents или автоматизация | Снизьте параллелизм, сократите контекст и выполняйте задачи партиями хотя бы один цикл | Повторяющуюся проблему процесса редко решает разовое повышение лимита |
| Основная работа — автодополнение, механические правки и локальные изменения | Используйте Tab и задачи меньшего масштаба | В Ultra включены unlimited Tab completions, поэтому Agent можно оставить для сложных решений |
На той же странице Cursor приводит ориентиры: ежедневные пользователи Tab обычно остаются в пределах включённого объёма; пользователи с ограниченным применением Agent часто тоже; ежедневная работа с Agent обычно даёт $60–$100 общего месячного использования, а несколько Agents или автоматизация — нередко $200 и больше. Это широкие категории, а не прогноз вашего счёта. Фактическая стоимость on-demand зависит от модели, числа токенов, длины контекста и процесса работы.
Оценивайте ценность задачи, а не уже уплаченные $200
Стоимость Ultra уже понесена и не должна быть единственным аргументом в пользу новых расходов. Перед тяжёлой задачей ответьте на три вопроса:
- Сколько ручного времени или потерь от задержки позволит избежать завершение прямо сейчас?
- Справится ли модель из второго включённого пула без неприемлемой потери качества?
- Если ещё одна платная попытка не завершит работу, на какой сумме вы остановитесь?
Если все ответы конкретны, on-demand с лимитом может быть разумнее внезапной остановки. Если на третий вопрос ответа нет, безопаснее сначала изменить процесс.
Порядок действий на сегодня
Действуйте в такой последовательности, чтобы оплата не опередила диагностику:
- Определите источник предупреждения: Cursor Models, Other Models, Grok Bot или страница биллинга.
- Зафиксируйте оба месячных пула: сохраните проценты и дату обновления, не сводя их к одному общему впечатлению.
- Сопоставьте модели и задачи: найдите выбранные модели, параллельные Agents и длинные контексты последних тяжёлых запусков.
- Проверьте категории счёта: убедитесь, что Included Usage и On-Demand Usage отображаются и растут раздельно.
- Сначала бюджет, потом переключатель: решите, сколько максимум готовы доплатить в этом цикле, и только затем включите on-demand с конечным пределом.
- Проведите ограниченный тест: завершите одну чётко очерченную задачу и снова проверьте оба пула и биллинг.
- Масштабируйте после проверки: увеличивайте объём задач или лимит только при приемлемом результате и расходе.
Успех — не просто исчезновение предупреждения. Вы должны уметь объяснить, какой пул расходуется, почему растёт дополнительная сумма и на каком значении работа должна остановиться.
Частые вопросы о лимитах Cursor Ultra
Если Grok Bot показывает 90%, Ultra почти исчерпан?
Не обязательно. Недельная квота Grok Bot и месячные пулы Cursor Models и Other Models — разные счётчики. Сначала проверьте оба пула на usage dashboard.
No Limit означает безлимитный Cursor?
Нет. No Limit только снимает месячный предел расходов on-demand. Запросы сверх включённого объёма остаются платными по соответствующим тарифам. Unlimited Tab completions в Ultra также не означает, что все Agent- и модельные запросы бесплатны и безграничны.
Может ли расход продолжиться после достижения лимита?
Cursor пишет, что блокировка срабатывает не мгновенно, поэтому возможно краткое превышение. Ограниченный перерасход до срабатывания учитывается как временный credit, а счёт ограничен текущим пределом. Повышение лимита в том же цикле может превратить часть или весь credit в оплачиваемый расход — до нового лимита.
Можно ли по проценту понять, на сколько работы хватит остатка?
Надёжно — нет. На расход влияют API-тариф модели, длина входного и выходного контекста и параллельность. Полезнее выполнить небольшую ограниченную задачу и посмотреть фактическое изменение в dashboard.
Правило, которое стоит запомнить
Сначала определите пул, потом включайте тарификацию; сначала задайте бюджет, потом повышайте лимит. Для соло-разработчика с высокой нагрузкой наиболее контролируемый вариант — конечный предел, распределение задач между подходящими пулами и проверка расхода после каждой дорогой сессии, а не мгновенный переход на No Limit.
