Cursor научила рой ИИ-агентов держать 1000 коммитов в секунду и подешевела в 8 раз
Своя система контроля версий вместо Git
Год назад Cursor уже пробовала собрать десятки агентов в рой для одной масштабной задачи - написать веб-браузер с нуля. Эксперимент показал рабочий прототип, но далёкий от готового продукта, т.к. координация держалась на Git с его блокировками файлов.
Git и Cargo (менеджер пакетов для Rust) рассчитаны на одного разработчика или небольшую команду. Сотни параллельных агентов упираются в те же блокировки, что и люди, только на порядки чаще. Старый рой Cursor выходил на пик около 1000 коммитов в час. Новая версия, для которой команда написала собственную систему контроля версий, держит около 1000 коммитов в секунду.
Кодовую базу решения, собранного роем на связке Opus 4.8 (в одиночку, без исполнителя-компаньона) - реализацию SQLite на Rust, написанную с нуля по документации: github.com/anysphere/minisqlite
Планировщик придумывает, исполнитель пишет код
В новой архитектуре у агентов две роли. Планировщик получает задачу, разбивает её на куски и раздаёт исполнителям, но сам никогда не пишет код, а его контекст не забивается деталями реализации. Исполнитель, наоборот, никогда не планирует и может потратить всё окно контекста на одну узкую задачу.
Вместе с новой VCS команда залатала конкретные сбои, которые проявляются именно на такой скорости. Два планировщика независимо реализуют одну и ту же концепцию по-разному («раздвоение мозга»), агенты часами воюют за один файл правками, а «мегафайлы», в которые пишут все подряд, превращаются в узкое место для diff и merge. Для конфликтов слияния завели отдельного агента-арбитра, который решает споры от лица всех сторон, по аналогии с очередью слияний в обычных инженерных командах.
SQLite с нуля по 835-страничному мануалу
Чтобы проверить, что изменилось на практике, Cursor вернула рой к задаче, с которой он не справился в прошлый раз: написать SQLite на Rust с нуля, опираясь только на документацию. Агентам не дали ни исходники, ни тестовые наборы, ни доступ в интернет. Качество измеряли тестом sqllogictest - набором из миллионов SQL-запросов с известными правильными ответами, про который сам рой не знал.
Разница в поведении оказалась заметнее разницы в итоговых баллах. На модели Grok 4.5 новый рой дошёл до 80% пройденных тестов за четыре часа, а старый пришлось остановить до конца второго часа, поскольку он расходился, а не сходился к решению. За первые два часа старая версия наплодила 68 тысяч коммитов и больше 70 тысяч конфликтов слияния, причём число конфликтов росло, а не падало. Самый горячий файл собрал 7771 конфликт от 1173 разных агентов. У новой версии на той же задаче теперь меньше тысячи конфликтов за все четыре часа, а самый спорный файл во всём проекте увидел 47 конфликтов.
Старый рой раздробил кодовую базу на 54 пакета Rust, включая три параллельные реализации SQL-движка - прямое следствие того самого «раздвоения мозга». Новый рой с самого начала остановился на девяти пакетах и не добавил ни одного. На связке Fable 5 и Composer 2.5 старая версия дописала рабочую SQLite за 64 305 строк движка, новая - за 9908. На связке с Opus 4.8 разрыв похожий: 19 013 строк при 97% тестов против 4645 строк при 100%.
Восьмикратная разница в цене за одинаковый результат
Cursor прогнала новый рой на четырёх связках моделей:
- GPT-5.5 - и планировщик, и исполнитель;
- Grok 4.5 - и планировщик, и исполнитель;
- Opus 4.8 как планировщик, Composer 2.5 как исполнитель;
- Fable 5 как планировщик, Composer 2.5 как исполнитель.
Качество получилось сопоставимым во всех четырёх случаях. Новые прогоны прошли от 73 до 85% теста за четыре часа и в итоге все добрались до 100%. Стоимость разошлась в восемь раз: от 1339 долларов на связке Opus 4.8 и Composer 2.5 до 10565 долларов на одном GPT-5.5.
Причина в цене за токен. Исполнители в любой связке съедают минимум 69% токенов, а обычно больше 90%, но токен планировщика стоит заметно дороже. У связки Opus 4.8 и Composer 2.5 планировщик потратил маленькую долю токенов, но почти две трети всей суммы, а исполнитель обработал основной объём работы за оставшуюся треть бюджета. В прогоне с GPT-5.5 на обеих ролях сами исполнители обошлись в 9373 доллара - дорогая модель выполняла и черновую работу тоже. В связке Opus 4.8 и Composer 2.5 весь флот исполнителей стоил 411 долларов.
У двух гибридных прогонов результат разошёлся ещё заметнее. Fable 5 как планировщик стоил меньше, чем Opus 4.8 в той же роли, хотя токен у Fable 5 примерно вдвое дороже - модель просто потратила меньше токенов на планирование. Но исполнители в этом прогоне съели токенов в несколько раз больше, и по сумме связка с Fable 5 вышла заметно дороже связки с Opus 4.8. Экономия на дорогой модели не гарантирована, она зависит от того, насколько чётко планировщик формулирует задачу для дешёвого исполнителя.
Логика вывода Cursor простая: почти всё в большом проекте не требует топовой модели, код по готовой спецификации способна писать модель подешевле. Дефицитный ресурс здесь - качество самой спецификации, которую планировщик передаёт вниз по цепочке. Кодовую базу с прогона на одном Opus 4.8 команда выложила в открытый доступ на GitHub (anysphere/minisqlite) - без глубокого ручного аудита, но, по словам авторов, на вид она получилась достойной.
