Кілька днів тому популярний розробник і ютубер Tech With Tim, працюючи в AI‑IDE Cursor, випадково виявив, що його модель для кодування непомітно змінилася з Opus 4.7 на нову Composer 2.5 — і задачі раптом почали виконуватися втричі–вчетверо швидше без втрати якості. Цей досвід став приводом розібратися, що саме Cursor побудував під назвою Composer 2.5, як влаштована модель, чому вона настільки дешева в роботі й як виглядає на незалежних бенчмарках поруч із Opus 4.7 та GPT 5.5.
У цьому матеріалі — не про «магію» IDE, а про саму модель: її архітектуру, економіку та результати тестів, які вже змушують серйозно сприймати Composer 2.5 як конкурента фронтирних LLM у сфері кодування.
Новий флагман Cursor: що таке Composer 2.5
Composer 2.5 — це свіжа флагманська модель для кодування від Cursor, офіційно випущена 18 травня 2026 року. Вона прийшла на зміну Composer 2, який з’явився лише в березні, і базується на тому самому фундаменті: чекпоінті Qwen2.5 (у відео він згадується як Kimmy/QwQ 2.5). Тобто йдеться не про повністю нову архітектуру, а про еволюцію вже перевіреної бази з агресивним фокусом на продуктивність у програмуванні.
Ключовий момент — позиціонування. Cursor прямо ставить Composer 2.5 в один ряд із «фронтирними» моделями на кшталт Opus 4.7 та GPT 5.5 саме в контексті коду. У реальній роботі всередині Cursor автор відео описує ситуацію, коли кілька годин користувався Opus 4.7, вичерпав ліміт, після чого система автоматично переключилася на Composer 2.5. Перемикання він не помітив — доки не звернув увагу, що відповіді приходять у 3–4 рази швидше, а структура коду й загальна якість залишилися на рівні Opus, а подекуди навіть виглядали краще організованими.
Цей досвід добре ілюструє амбіцію Cursor: Composer 2.5 має поводитися як модель класу Opus/GPT у реальних задачах розробника, але бути суттєво ефективнішою за швидкістю та вартістю.
Архітектура під капотом: mixture‑of‑experts і «розумний» тренінг
Технічна основа Composer 2.5 — чекпоінт Qwen2.5 (QwQ 2.5), на якому вже будувався Composer 2. Але нова версія — це не просто ще один раунд донавчання. Cursor використовує архітектуру mixture‑of‑experts (MoE) з нетривіальним розподілом обчислень і тренувальних ресурсів.
MoE‑підхід означає, що модель складається з набору «експертів» — підмереж, які спеціалізуються на різних типах задач або патернів. Під час інференсу активується не весь «повний» модельний блок, а лише частина експертів, які, на думку роутера, найкраще підходять для конкретного запиту. Для кодування це особливо цікаво: окремі експерти можуть краще працювати з певними мовами програмування, шаблонами архітектури, патернами рефакторингу чи виправлення помилок.
Cursor у своїй презентації підкреслює, що для Composer 2.5 застосовано «цікавий спліт обчислень і тренінгу». Деталі не розкриваються, але з контексту зрозуміло, що йдеться про оптимізацію того, які експерти й на яких даних донавчаються, щоб максимізувати саме coding‑перформанс при мінімальних витратах. Фактично, це спроба отримати поведінку фронтирної моделі в конкретному домені (розробка ПЗ), не тягнучи за собою повну вартість універсального гіганта на кшталт GPT 5.5.
Composer 2.5 при цьому зберігає безперервність із Composer 2: спільна база означає, що попередні інвестиції в тренінг і налаштування не викидаються, а нарощуються. Для користувача це проявляється як «та ж сама модель, тільки помітно краща» — без радикальної зміни поведінки, до якої довелося б звикати.
Ціна проти якості: чому $0,50 за задачу змінюють гру
Найгучніший аргумент на користь Composer 2.5 — не бали на бенчмарках, а економіка. Cursor наводить власний внутрішній бенчмарк, де порівнює вартість виконання задачі різними моделями. На цьому тесті:
- Composer 2.5 обходиться приблизно в $0,50 за задачу.
- Opus 4.7 — майже $7 за ту саму задачу.
Різниця — у 14 разів. Сам Cursor прямо формулює це як «14x дешевше на задачу» в межах свого бенчмарку. Автор відео додає, що в його реальних сценаріях використання Composer 2.5 виходив не лише дешевшим, а й помітно швидшим, при цьому результати залишалися «настільки ж хорошими, якщо не кращими» порівняно з Opus 4.7.
Важливо розуміти обмеження: це не незалежне академічне дослідження, а внутрішній тест Cursor. Компанія не розкриває точну методологію, а значення для GPT 5.5 у цій презентації взагалі не наведено. Проте навіть у такому вигляді цифри показують ключову тенденцію: за умови близької якості коду Composer 2.5 дозволяє різко знизити маржинальні витрати на кожну задачу.
Для індивідуальних розробників це означає, що можна довше працювати в межах денних лімітів і не боятися, що кілька великих задач «з’їдять» увесь бюджет на Opus чи GPT. Для команд і компаній, які інтегрують AI‑агентів у пайплайни розробки, різниця в 14 разів на тисячах задач перетворюється на відчутну економію операційних витрат.
Ще один практичний наслідок — швидкість. У реальному проєкті всередині Cursor автор помітив, що після непомітного переходу з Opus 4.7 на Composer 2.5 час виконання тих самих типів задач скоротився в 3–4 рази. Якщо модель видає подібну якість коду, але в рази швидше й за частку вартості, для більшості повсякденних задач розробника це стає вагомішим аргументом, ніж додаткові кілька відсотків точності на синтетичних тестах.
Бенчмарки: як Composer 2.5 виглядає поруч із Opus 4.7 і GPT 5.5
Щоб вийти за межі суб’єктивних вражень, Cursor опирається на низку бенчмарків — як сторонніх, так і власних. Картина, що вимальовується, доволі послідовна: Composer 2.5 не завжди перемагає фронтирні моделі, але стабільно тримається поруч, а іноді й випереджає їх у задачах, близьких до реального кодування.
На Artificial Analysis Coding Agent Index, який оцінює саме агентів для коду, Composer 2.5 показує результат, практично ідентичний Opus 4.7 і GPT 5.5. В інтерпретації автора відео, на цьому індексі моделі «практично зрівнялися». Це важливий сигнал: у середовищі, де моделі працюють як coding‑агенти, а не просто як «чисті» LLM, Composer 2.5 вже не виглядає «молодшим братом» фронтирних систем.
На SWEBench Multilingual, який тестує здатність моделі розв’язувати реальні задачі з відкритих репозиторіїв у багатомовному середовищі, Composer 2.5 демонструє дуже схожу продуктивність із GPT 5.5, а в окремих випадках навіть перевершує його. Для практики це означає, що модель не лише добре поводиться на англомовному коді, а й адекватно працює в більш різноманітних, «брудних» умовах, де змішуються різні мови програмування, стилі й екосистеми.
На Cursor Bench v3.1, внутрішньому бенчмарку компанії, Composer 2.5 очікувано «сяє» — модель випереджає конкурентів на наборі задач, які максимально наближені до того, що користувачі роблять у Cursor щодня. Це не дивує: бенчмарк створено тими ж людьми, які будують модель і середовище, але він показує, як добре Composer 2.5 інтегрується в типові робочі сценарії IDE.
На Terminal Bench 2.0, орієнтованому на shell‑орієнтовані задачі, картина інша. Тут Composer 2.5 показує результат, близький до Opus 4.7, тоді як GPT 5.5 помітно випереджає обох. Висновок доволі прямолінійний: якщо робота сильно зав’язана на складні термінальні операції, GPT 5.5 залишається кращим вибором. Проте той факт, що Composer 2.5 тримається на рівні Opus 4.7, знову підкреслює його статус «у клубі» фронтирних моделей для коду.
Загальна картина така: на незалежних індексах, що моделюють реальних coding‑агентів, Composer 2.5 уже не виглядає компромісом. Він або йде нога в ногу з Opus 4.7 і GPT 5.5, або трохи відстає, але в межах кількох відсотків, які в реальних задачах часто губляться на фоні різниці в ціні й швидкості.
Спеціалізація проти універсальності: де Composer 2.5 виграє, а де поступається
У порівнянні з універсальними моделями на кшталт GPT 5.5 важливо розуміти межі амбіцій Composer 2.5. Cursor сам визнає, що якщо оцінювати «сирі» моделі в режимі простого текст‑ін/текст‑аут через базовий API, фронтирні системи все ще попереду. Вони тренувалися на ширшому спектрі задач, мають більше загальних знань і краще поводяться в нетипових сценаріях, далеких від коду.
Але в реальному житті розробники рідко спілкуються з моделлю як із «чистим» LLM. Вони працюють через IDE, агенти, інструменти, де модель оточена контекст‑менеджментом, тулінгом, навичками й саб‑агентами. У такому середовищі вузька спеціалізація й оптимізація під конкретну роль можуть виявитися важливішими, ніж універсальна «розумність».
Composer 2.5 якраз і спроєктовано як модель, що максимально ефективно працює в ролі coding‑агента всередині Cursor. Архітектура mixture‑of‑experts, спеціальний тренінг і тісна інтеграція з інструментами IDE дозволяють їй видавати поведінку, дуже схожу на фронтирні моделі, але з меншими витратами. На бенчмарках це проявляється як «майже паритет» із Opus 4.7 і GPT 5.5, а в гаманці — як суттєво нижча вартість кожної задачі.
Це не означає, що Composer 2.5 — універсальна заміна GPT 5.5. Якщо потрібні складні міркування за межами коду, глибокі знання в інших доменах або максимальна якість у shell‑орієнтованих сценаріях, фронтирні моделі залишаються кращим вибором. Але для повсякденної розробки, де основна мета — швидко й дешево отримати робочий код, Composer 2.5 уже виглядає як раціональний дефолт.
Чому ці бенчмарки важливі саме для розробників
У світі LLM бенчмарки часто сприймаються як «спорткарти» для ентузіастів: цікаво, але не завжди корисно в реальній роботі. У випадку Composer 2.5 ситуація інша, бо більшість згаданих тестів безпосередньо стосуються того, що розробники роблять щодня.
Artificial Analysis Coding Agent Index оцінює саме агентів, а не «голі» моделі. SWEBench Multilingual моделює реальні задачі з відкритих репозиторіїв, де треба розібратися в чужому коді, зрозуміти контекст, внести зміни й не зламати все навколо. Cursor Bench v3.1 і Terminal Bench 2.0, хоч і внутрішні, побудовані навколо типових сценаріїв роботи в IDE і терміналі.
На цьому фоні заяви Cursor про те, що Composer 2.5 «майже не поступається» Opus 4.7 і GPT 5.5, виглядають не як маркетинговий слоган, а як узагальнення досить послідовних даних. Модель не завжди перемагає, але стабільно тримається поруч, а в окремих тестах навіть виходить уперед — при цьому залишаючись у рази дешевшою на задачу.
Для розробників, які вже звикли до того, що «справжня робота» вимагає підключати найдорожчі моделі, це відкриває нову опцію: використовувати Composer 2.5 як основного «робочого коня», залишаючи Opus чи GPT 5.5 для вузьких, особливо складних кейсів, де кожен відсоток якості має значення.
Висновок: спеціалізований флагман замість універсального гіганта
Composer 2.5 — показовий приклад того, як змінюється ландшафт AI‑інструментів для розробників. Замість того, щоб намагатися побудувати ще один універсальний гігант, Cursor взяв сильну базову модель Qwen2.5, наклав на неї mixture‑of‑experts‑архітектуру, оптимізував тренінг під кодування й щільно інтегрував усе це у власну IDE.
Результат — модель, яка на ключових coding‑бенчмарках практично не відстає від Opus 4.7 і GPT 5.5, а на деяких тестах навіть виглядає краще, при цьому коштуючи приблизно $0,50 за задачу проти близько $7 у Opus на внутрішньому бенчмарку Cursor. У реальних проєктах це виливається в задачі, що виконуються в 3–4 рази швидше за подібної якості коду.
Composer 2.5 не претендує на роль «мозку для всього», але в ролі спеціалізованого інструмента для розробки ПЗ він уже зараз виглядає як один із найцікавіших варіантів на ринку. І якщо тенденція збережеться, наступні роки можуть пройти не під знаком «однієї найкращої моделі», а під знаком екосистеми спеціалізованих флагманів, оптимізованих під конкретні ролі — на кшталт того, що Cursor робить із Composer 2.5.