Дешевші моделі беруть рутинний код
Cursor перевірила новий swarm агентів на задачі: відтворити SQLite на Rust лише за 835-сторінковим мануалом, без коду, тестів, бінарника й інтернету. У новій схемі frontier-моделі планують, а швидші дешевші моделі виконують підзадачі. Через 4 години нові запуски набрали 73–85% у sqllogictest проти 11–77% у старих, а згодом усі конфігурації дійшли до 100%.
Ключ не в більшій кількості агентів, а в розподілі ролей і контролі конфліктів: стара система на Grok 4.5 зробила 68 тис. комітів за 2 години й понад 70 тис. merge conflicts, нова трималася нижче 1 тис.
Що це означає для бізнесу: для великих coding-задач варто тестувати гібрид: дорогі моделі — для декомпозиції й дизайну, дешевші — для виконання. Це може знизити витрати, але якість планувальника лишається критичною.
Що саме змінила Cursor у swarm-підході
У новій схемі Cursor розділила агентів на дві ролі. Planner-агенти на сильніших frontier-моделях не пишуть код, а розбивають ціль на менші задачі й ухвалюють ключові дизайн-рішення. Worker-агенти на швидших і дешевших моделях виконують ці підзадачі. Cursor пояснює це як спосіб зменшити проблему контексту: одному агенту важко одночасно тримати в голові всю мету й локальну задачу, через що довгі роботи збиваються з курсу.
Для координації Cursor додала спільні дизайн-документи: агенти фіксували в них рішення, а код, пов'язаний із рішенням, посилався назад на документ через перевірку на етапі компіляції. Коли виникали merge conflicts, їх розв'язував нейтральний агент. Окремі агенти також позначали занадто великі файли, щоб їх розбивали на менші модулі.
Компанія описує такі swarm-системи як імовірнісний компілятор, який крок за кроком перетворює намір на виконувану роботу. У цьому експерименті, за словами Cursor, головним обмеженням було не саме кодування, а точність опису наміру.
Як проходив тест і що показали цифри
Cursor дала swarm-системі 835-сторінковий мануал SQLite і поставила задачу зібрати реалізацію на Rust. Вихідний код, тестові набори, бінарник SQLite та доступ до інтернету були недоступні. Оцінювання відбувалося через sqllogictest — тестовий набір із мільйонами SQL-запитів і відомими відповідями, про який swarm не знав.
- Тестували чотири конфігурації: GPT-5.5 solo, Grok 4.5 solo, Opus 4.8 як planner із Composer 2.5 як worker, Fable 5 як planner із Composer 2.5 як worker.
- Через 4 години нові запуски набрали 73–85%, старі — 11–77%.
- Згодом кожна конфігурація нової системи дійшла до 100%.
- Cursor опублікувала кодову базу з Opus solo run як
minisqliteна GitHub.
Найпомітніша різниця була не лише в результаті, а в кількості зайвої роботи. У запуску на Grok 4.5 стара система створила 68 000 комітів за дві години, приблизно у 70 разів більше, ніж нова. Вона накопичила понад 70 000 merge conflicts, тоді як нова весь час залишалася нижче 1 000.
Чому старий підхід ламався на координації
Попередній browser swarm Cursor мав worker-агентів, judge-агента та integrator-агента для розв'язання конфліктів. Але integrator став вузьким місцем. Нова система сягнула 1 000 комітів на секунду, і Cursor довелося створити власну систему контролю версій, бо Git не був розрахований на такі режими роботи.
Одна з проблем отримала назву split-brain design: два planner-и могли незалежно будувати одну й ту саму ідею в різних місцях і реалізовувати її по-різному. У старому запуску найбільш конфліктний файл мав 7 771 конфлікт від 1 173 агентів, у новому — 47. У структурі проєкту стара система розбила його на 54 Rust crates із трьома окремими SQL-пакетами, тоді як нова рано зійшлася на дев'яти crates.
- У конфігурації Fable 5 стара система потребувала 64 305 рядків engine-коду, нова — 9 908.
- В Opus-конфігурації стара система дала 19 013 рядків і 97%, нова — 4 645 рядків і 100%.
- Cursor також тестувала різні види рев'ю: за повним transcript worker-а, лише за output і лише за codebase. Жоден погляд не ловив усе, але комбінація незалежних поглядів була надійнішою.
Економіка: де саме дешевші моделі дають ефект
Загальна вартість запусків у джерелі коливалася від $1 339 для Opus hybrid до $10 565 для GPT-5.5 solo. Worker-и споживали щонайменше 69% токенів у кожному запуску, а зазвичай понад 90%. Але planner-токени дорожчі, тому частка витрат виглядала інакше: в Opus hybrid planner дав лише малу частку токенів, але дві третини загального рахунку.
Найбільша різниця була саме у worker-моделі. У GPT-5.5 run лише worker-и коштували $9 373. У запуску Opus + Composer весь worker fleet коштував $411 за порівнюваної якості. Cursor пояснює це ціноутворенням: Composer 2.5, за даними джерела, коштує $0.50 за мільйон input-токенів і $2.50 за мільйон output-токенів. За словами засновника Cursor Michael Truell, модель базується на Kimi K2.5.
Практичний висновок для бізнесу обмежений саме великими coding-задачами, де роботу можна розбити на багато підзадач. Джерело не дає готового сценарію для фінансистів, юристів чи HR уже сьогодні. Також не відомо, як стабільно така схема працює на типових production-проєктах: у джерелі наведено дослідження кінця 2025 року, де 68% production-агентів завершували не більше десяти кроків до втручання людини, а для 47% межа була меншою за п'ять.