Cursor Composer 2: зачем IDE создаёт собственный coding model stack
Почему модель, agent harness, context engine, tools и evaluation выгодно оптимизировать как одну инженерную систему.

Зачем Cursor ещё одна модель

19 марта 2026 года Cursor выпустила Composer 2 — второе поколение собственной модели для agentic coding. В анонсе компания называет её frontier-level, показывает 61,3 балла на CursorBench и обещает работу над задачами, которым нужны сотни действий.

Цифры заметно выше прежних версий: Composer 1.5 получила 44,2, первая Composer — 38,0. Но это всё ещё результаты Cursor в её же eval-наборе, а «frontier-level» — позиционирование производителя, не независимый вердикт. Для меня релиз интересен по другой причине: Cursor начала обучать собственную модель под свой execution loop.

model
  + agent harness
  + context engine
  + tools
  + IDE
  = developer experience

Если смотреть только на строку Composer 2 в model picker, решение кажется избыточным. В Cursor уже доступны сильные внешние модели. Если смотреть на весь маршрут от задачи до проверенного diff, собственная модель становится логичным следующим слоем продукта.

Обычному AI-ассистенту своей модели не требовалось

Первая волна AI-функций в редакторах была тонкой оболочкой над API. Разработчик выделял метод, задавал вопрос и получал объяснение либо продолжение кода. IDE отвечала за интерфейс и сбор контекста, provider — за модель.

выделенный код → API модели → ответ → разработчик

В такой архитектуре выгоднее выбирать между OpenAI, Anthropic, Google и другими поставщиками, чем обучать собственную LLM. Качество продукта в основном определялось тем, насколько удобно отправить запрос и применить ответ.

Coding agent меняет единицу работы. Он получает не фрагмент, а задачу: исследует repository, выбирает файлы, вызывает terminal, вносит несколько правок, запускает tests и возвращается к гипотезе после failure. Между prompt и результатом появляется система исполнения.

task
  ↓
model → tool → observation
  ↑                 ↓
  └──── next action ┘
  ↓
verified result

На коротком запросе лишний search почти незаметен. На сто шагов он превращается в минуты ожидания и большой счёт за токены. Ошибка при выборе файла уводит весь последующий rollout. Поэтому поведение модели внутри loop становится таким же важным, как способность написать корректную функцию.

Harness меняет результат той же модели

Две IDE могут подключить одну LLM и получить разных агентов. Первая точно находит связанные классы, возвращает структурированный terminal output и удерживает план после compaction. Вторая подсовывает шумный контекст, заставляет модель повторять поиск и теряет исходное ограничение после нескольких итераций.

Model X + точный retrieval + ясные tools + test loop
Model X + шумный context + хрупкие tools + ранний stop

одна модель, два разных результата

Даже таблица Composer 2 косвенно это признаёт. В примечании к Terminal-Bench 2.0 Cursor указывает разные среды для сторонних моделей: Claude Code для Anthropic, Simple Codex для OpenAI и официальный Harbor harness для собственного запуска. Сравниваются пары model-agent, а не веса в вакууме.

Я уже разбирал этот эффект в статье о Claude Opus 4.6 и GPT-5.3-Codex. Composer 2 делает следующий шаг: Cursor не просто настраивает оболочку вокруг чужой модели, а получает возможность менять обучение под наблюдаемое поведение своего агента.

Модель учится в том loop, где будет работать

За два дня до релиза Cursor описала обучение Composer на длинном горизонте. Модель тренируют reinforcement learning внутри Cursor agent harness, включая compaction-in-the-loop. Когда контекст подходит к лимиту, Composer сама выделяет состояние задачи, план и незавершённые пункты, после чего продолжает rollout по сжатой истории.

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

В эксперименте Cursor self-summary занимала около 1000 токенов против примерно 5000 у тщательно настроенного prompt-based compaction. Компания сообщает о снижении compaction error на 50%. В отдельном кейсе ранний checkpoint Composer прошёл 170 turns и несколько раз сжимал историю, чтобы решить задачу Terminal-Bench.

Такой подход даёт Cursor рычаг, недоступный при чистой интеграции API. Если агент слишком долго исследует repository, рано объявляет задачу завершённой или сохраняет не те факты при сжатии, проблему можно атаковать через tool design, instructions, orchestration и training data одновременно.

Вертикальная интеграция работает в обе стороны

Свою модель можно адаптировать к продукту: учить моменту перехода от research к implementation, выбору инструмента и привычке проверять итог. Обратная связь не менее ценна — продукт можно перестраивать под известное поведение модели.

Если Composer надёжнее работает с короткими структурированными результатами поиска, context engine может отдавать именно их. Если определённый формат patch снижает ошибки, IDE меняет интерфейс редактирования. Если self-summary хорошо удерживает явный plan state, harness хранит это состояние в форме, которую модель уже видела при обучении.

training data ↔ model behavior
       ↕             ↕
evaluation  ↔ agent harness
       ↕             ↕
context + tools ↔ Cursor IDE

Это co-design, знакомый по системам, где одна компания контролирует hardware, OS и runtime. Здесь слои другие, но механизм тот же: локальная оптимизация одного компонента уступает совместной оптимизации всего маршрута.

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

Цена и latency становятся свойствами агента

Standard-вариант Composer 2 на старте стоил $0,50 за миллион input tokens и $2,50 за миллион output. Fast — $1,50 и $7,50 соответственно; Cursor сделала его вариантом по умолчанию.

Для одиночного ответа это просто тариф. Для агента цена участвует в архитектуре. Одна задача может вызвать модель десятки раз, несколько раз передать большой repository context и повторить test loop после ошибок. Латентность тоже суммируется: лишние две секунды на одном шаге почти незаметны, на ста действиях это уже больше трёх минут чистого ожидания.

полезность coding agent ≠ максимальный benchmark score

полезность ≈ quality × speed × tool reliability
             ────────────────────────────────
                       cost × retries

Поэтому быстрая специализированная модель иногда полезнее более сильной general-purpose модели. Особенно в интерактивном режиме, где разработчик ждёт каждый search, patch и test decision. Собственная inference-экономика позволяет Cursor настраивать этот баланс под частоту действий в своём продукте, а не под средний API-запрос.

CursorBench замыкает продуктовый контур

CursorBench собран из реальных сессий инженерной команды Cursor. В нём есть неоднозначные задачи, изменения нескольких файлов и оценка не одной правильной строки, а результата работы агента. Cursor также сопоставляет offline eval с online-сигналами продукта, чтобы ловить улучшения, которые красиво выглядят у grader, но не помогают разработчикам.

Так возникает короткий цикл обратной связи:

реальные задачи
      ↓
offline + online evaluation
      ↓
training и agent changes
      ↓
новые реальные задачи

61,3 против 44,2 имеет смысл именно внутри одной версии такого eval. Это сильный сигнал прогресса собственной линейки, но не универсальная шкала качества: набор задач внутренний, harness влияет на outcome, а распределение пользовательской работы у другой команды будет отличаться.

Ценность CursorBench не в обещании окончательно ранжировать все модели. Он даёт Cursor измеритель, близкий к своему продукту, и позволяет оптимизировать то, что пользователь действительно замечает: корректность, количество лишних шагов, стоимость и поведение агента во время сессии.

Своя модель не требует модельной монокультуры

Composer 2 не отменяет GPT, Claude и другие варианты в Cursor. Я бы ожидал обратного: agent harness становится router, который выбирает исполнителя по типу этапа.

routine search и patch  → Composer
архитектурный research → frontier reasoning model
implementation         → Composer или внешняя модель
independent review     → другая модель

Это не анонсированная схема Cursor, а практический вывод из архитектуры. Собственная недорогая модель особенно полезна как базовый worker: её можно вызывать часто и обучать под локальные tools. Дорогую внешнюю модель разумно подключать там, где дополнительное reasoning оправдывает задержку и цену.

Такой routing продолжает идею, которую я разбирал на примере Claude Sonnet 4.6: выбирать стоит не одного абсолютного победителя, а подходящую комбинацию качества, горизонта и стоимости.

Почему это не противоречит движению GPT-5.4

Недавняя GPT-5.4 показала движение от отдельной coding-модели к универсальной frontier model с сильным coding и tool use. Cursor почти одновременно идёт в другую сторону — от внешних универсальных моделей к собственной специализации.

Противоречие исчезает, если развести цели. OpenAI строит модель для широкого класса профессиональных задач. Cursor оптимизирует developer experience внутри конкретной среды. Универсальность выгодна первому продукту; тесная специализация может оказаться выгоднее второму.

Разработчик в итоге оценивает не происхождение weights. Его интересует, понял ли агент repository, сделал ли разумный diff, быстро ли закончил, прошли ли tests и сколько ручных исправлений осталось. Побеждает система, которая устойчиво закрывает этот маршрут.

Cursor строит среду выполнения инженерной работы

После Composer 2 называть Cursor только IDE уже тесно. Model picker, context engine, rules, skills, MCP, subagents, cloud agents, automations и собственная модель складываются в execution environment для программной инженерии.

Это меняет и предмет конкуренции. Сравнение GPT vs Claude vs Composer остаётся полезным для отдельных задач. На длинной работе важнее другое: какая связка модели, harness, context, tools, permissions и verification доводит изменение до приемлемого результата.

Именно поэтому Composer 2 — заметный релиз даже для разработчика, который продолжит выбирать внешние модели. Cursor показывает направление: AI-инструменты начинают контролировать не только интерфейс к интеллекту, но и способ его обучения, измерения и исполнения.

Следующая сильная AI-IDE выиграет не потому, что на неделю получила модель с лучшим score. Она выиграет, если весь stack будет меньше терять контекст, реже делать лишние действия и чаще возвращать проверенный результат. Composer 2 — заявка Cursor именно на такую вертикально интегрированную систему.