Technical Context
Я смотрю на Cursor IDE не как на «умный редактор», а как на тонкий биллинг‑слой поверх LLM API. И именно поэтому меня не удивляет кейс, когда $20 подписки улетают за ~6 часов активной работы: в Cursor стоимость агента — это не «запрос», а сумма входных/выходных токенов, умноженная на тариф конкретной модели плюс накладные расходы на агентский оркестратор.
Сейчас у Cursor гибридная модель: фиксированная подписка и кредитный пул, оценённый в долларах и привязанный к ценам провайдеров моделей. На Pro за $20 в месяц вы фактически получаете примерно $20 агентских кредитов. Pro+ за $60 даёт больше кредитов, Ultra за $200 — ещё больше. Но ключевой момент не в цифрах, а в том, что токены «дорогих» сценариев растут нелинейно.
Что мне как архитектору бросается в глаза: агентская сессия легко превращается в многомиллионный контекст. Причина простая — агент не работает «по одному файлу». Он читает дерево проекта, подхватывает логи, диффы, конфиги, часто делает несколько итераций планирования/выполнения. Если вы дебажите Terraform или AWS‑инцидент, то в контекст попадают:
- несколько модулей IaC, переменные, локалы, outputs;
- планы/стейты, куски CloudTrail/CloudWatch, иногда JSON‑политики;
- обсуждение гипотез и повторные прогоны.
Добавьте сюда переключение на премиальную модель (или режимы с большим контекстом/«max») — и один «агентский разговор» начинает стоить как десятки обычных запросов. Даже попытка спасаться автоселектором модели или Composer не гарантирует экономии: автоселектор всё равно может выбрать более дорогую модель, если считает задачу сложной, а Composer часто расширяет контекст, чтобы «держать в голове» план работ.
Отдельная зона риска — фоновые агенты и инструменты наподобие Bugbot, которые могут тарифицироваться отдельно и ближе к «чистому API‑потреблению». С архитектурной точки зрения это означает, что ваш IDE внезапно становится постоянно работающим потребителем токенов, а не интерактивным ассистентом.
Business & Automation Impact
В бизнесе меня интересует не «как круто он пишет код», а сколько стоит одна единица результата: закрытый тикет, исправленный инцидент, готовый модуль Terraform, пройденный security review. На гибридной схеме Cursor цена такой единицы может плавать в разы. И это ломает привычную экономику разработки: вы можете планировать нагрузку по человеко‑часам, но не планировать токены без дисциплины и инструментов контроля.
Кто выигрывает от модели Cursor? Команды, где агент используется дозированно: короткие сессии, ограниченный контекст, понятные правила, какие задачи отдают агенту, а какие — обычным автокомплитом. Проигрывают те, кто воспринимает агент как «поставьте на автопилот и пусть сам разрулит инфраструктуру». В IaC и облаке автопилот часто превращается в «прочитай всё, попробуй всё, объясни всё», то есть в счёт на токены.
Я вижу здесь прямую параллель с тем, как компании проваливают внедрение ИИ: покупают инструмент, но не покупают процесс. В моей практике в Nahornyi AI Lab устойчивый эффект даёт не выбор «Cursor vs Windsurf», а архитектура использования:
- Политики контекста: что агент имеет право читать/индексировать, а что запрещено (особенно в монорепах и с секретами).
- Лимиты и «стоп‑краны»: дневные/недельные бюджеты, алерты, запрет на дорогие модели по умолчанию.
- Классификация задач: генерация шаблонов и мелкие правки — одно, дебаг прод‑инцидента — другое, миграция инфраструктуры — третье.
- Наблюдаемость: метрики токенов/стоимости по репозиториям, командам, типам задач, чтобы прекращать «невидимые» утечки.
На этом фоне подход Windsurf с фиксированной ценой за пользовательский промпт выглядит психологически комфортнее: финансовый сюрприз менее вероятен. Но я не идеализирую фикс‑прайс: он часто означает скрытые ограничения по качеству модели, глубине агентности или частоте. Для руководителя разработки вопрос один: где вы хотите платить — «явно по токенам» или «неявно ограничениями».
Если ваша цель — ИИ автоматизация в разработке и DevOps, вам нужен предсказуемый операционный контур: кто запускает агентов, как измеряется стоимость, какие сценарии разрешены. Иначе получится парадокс: AI-IDE экономит время инженера, но увеличивает непредсказуемые операционные расходы, которые трудно объяснить CFO.
Strategic Vision & Deep Dive
Мой прогноз простой: рынок AI-IDE уйдёт в две крайности. Первая — «compute‑aligned» инструменты вроде Cursor, где вы платите близко к себестоимости LLM и получаете максимум мощности, но обязаны управлять потреблением как облачными ресурсами. Вторая — «fixed‑experience» продукты, где вам продают предсказуемость, но с потолком по агентности и контексту.
С точки зрения AI-архитектуры я бы уже сейчас относился к агентским режимам как к маленькому внутреннему сервису, а не функции редактора. В проектах Nahornyi AI Lab я закладываю для таких инструментов те же практики, что и для облака:
- песочницы для рискованных задач (инциденты, IAM‑политики, Terraform apply);
- разделение ролей: «читатель» vs «исполнитель», чтобы агент не превращался в неконтролируемого оператора;
- обязательный короткий контекст по умолчанию и расширение контекста только по запросу;
- пост‑анализ: какие сессии были дорогими и почему (обычно причина — лишние файлы, бесконечные итерации или неправильная постановка задачи).
Самая неприятная ловушка — иллюзия, что переключение модели на «Auto» автоматически решит экономику. Auto иногда помогает, но не чинит главную причину перерасхода: плохо ограниченный контекст и отсутствие бюджета на задачу. Когда агент «пережёвывает» лог‑файлы, планы Terraform и десятки модулей, экономия на модели даёт проценты, а не порядок.
Я предпочитаю честный подход: на сложные инфраструктурные задачи либо выделяется отдельный бюджет (и это обосновано ценой простоя/ошибки), либо мы перестраиваем процесс так, чтобы агент работал фрагментами и выдавал проверяемые артефакты. Хайп заканчивается там, где начинается контроль стоимости и ответственности. Полезность — там, где результат повторяем, измеряем и вписываем в регламенты.
Если вы хотите сделать ИИ автоматизацию без сюрпризов в счетах, я приглашаю обсудить ваш сценарий: репозитории, типы задач, бюджет, требования безопасности. Напишите мне — Vadym Nahornyi — и мы в Nahornyi AI Lab спроектируем внедрение искусственного интеллекта в разработку так, чтобы агент ускорял работу, а не выжигал лимиты.