Канадський розробник і ютубер Tech With Tim, відомий практичними тестами інструментів для програмістів, вирішив перевірити, як нова модель Composer 2.5 від Cursor поводиться не в синтетичних бенчмарках, а в реальному завданні. У середовищі Cursor він запустив head‑to‑head тест трьох моделей — Composer 2.5, Opus 4.7 та GPT 5.5 — давши їм однаковий промпт: створити реальний застосунок — колаборативну whiteboard‑дошку в реальному часі.
Результат виявився не лише питанням швидкості й якості коду, а й дуже відчутної різниці у вартості, особливо в “швидких” режимах Cursor.
Як випадкове перемикання моделі виявило трьох‑чотирикратний приріст швидкості
Знайомство з Composer 2.5 у цього розробника почалося взагалі не з бенчмарків. Працюючи в Cursor, він, як зазвичай, обрав Opus 4.7 і кілька годин будував застосунок, поки не вичерпав ліміт використання преміальних моделей. Після цього Cursor автоматично переключився на нову Composer 2.5 — і це спочатку навіть залишилося непоміченим.
Зміни стали очевидними лише тоді, коли завдання почали виконуватися приблизно у три‑чотири рази швидше, ніж до цього з Opus 4.7, при цьому якість відповідей залишалася на тому ж рівні або здавалася навіть кращою з погляду структури виводу. Лише після цього автор звернув увагу на індикатор моделі в інтерфейсі й побачив, що працює вже не з Opus, а з Composer 2.5.
Цей досвід став відправною точкою для більш формального порівняння. Якщо модель, яка коштує значно дешевше, працює помітно швидше й не програє в якості, логічно перевірити це в контрольованому тесті. Так з’явився сценарій з колаборативною whiteboard‑дошкою, де всі три моделі отримали однаковий промпт усередині Cursor.
Whiteboard‑челендж: хто швидше й краще напише реальний застосунок
Для порівняння моделей було обрано завдання, яке добре відображає реальну роботу розробника: створити застосунок колаборативної дошки, де кілька користувачів можуть одночасно малювати в реальному часі. Це не “іграшковий” скрипт, а повноцінний стек: фронтенд, бекенд, синхронізація, мережеві події, структура проєкту.
Усі моделі запускалися всередині Cursor з однаковим промптом, але в різних режимах швидкості, які впливають і на вартість.
Composer 2.5: робоча дошка за 3–4 хвилини
У “fast mode” Composer 2.5 впорався із завданням приблизно за 3–4 хвилини. За цей час модель згенерувала робочий застосунок колаборативної дошки, який реально функціонував.
Архітектурно Composer 2.5 обрав стек, який сьогодні є де-факто стандартом для сучасних фронтенд‑проєктів: клієнт на React і TypeScript плюс окремий сервер. Такий підхід дає чітке розділення відповідальностей, кращу типобезпеку та простіший масштабований розвиток коду.
Важливий момент: це був не просто “hello world” з однією сторінкою, а саме робоча колаборативна дошка в реальному часі, яка виконувала поставлену задачу. На думку автора тесту, саме ця реалізація від Composer 2.5 виявилася найкращим стартовим варіантом серед усіх трьох моделей.
Opus 4.7: 15 хвилин очікування — і неробочий застосунок
Opus 4.7 запускали в “medium-fast mode” — тобто в режимі, де модель має більше ресурсів і, теоретично, повинна показувати сильніший результат, хоча й дорожчий. Попри це, час виконання завдання виявився приблизно 15 хвилин, що в кілька разів довше, ніж у Composer 2.5.
Кінцевий результат виявився проблемним: застосунок, який згенерував Opus 4.7, не працював. Замість сучасного стеку модель побудувала рішення на “чистому” JavaScript і CSS, без використання React чи TypeScript. Формально це теж веб‑клієнт, але з погляду підтримуваності, масштабованості та відповідності типовим робочим стек‑вимогам це крок назад.
Тобто в цьому тесті Opus 4.7 не лише програв у швидкості, а й не зміг видати робочий продукт, попри вищий режим продуктивності та значно більшу вартість обчислень.
GPT 5.5: повільніше, але з тестами й спільними типами
Третім учасником став GPT 5.5, також у “medium-fast mode”. Час виконання завдання коливався в діапазоні 10–20 хвилин — помітно довше, ніж у Composer 2.5, але трохи швидше або на рівні з Opus 4.7.
Проте тут результат був якісно іншим. GPT 5.5 згенерував робочий застосунок колаборативної дошки на React і TypeScript, доповнивши його тестами та спільними типами між клієнтом і сервером. Такий підхід ближчий до того, як будують продакшн‑системи: є типобезпека на всьому шляху даних, є базове тестове покриття, що полегшує подальшу розробку й рефакторинг.
Якщо дивитися лише на якість архітектури та “інженерну культуру” в коді, GPT 5.5 виглядає дуже переконливо. Але це досягається за рахунок часу: очікування в 10–20 хвилин проти 3–4 хвилин у Composer 2.5 — суттєва різниця, особливо коли мова йде про інтерактивну роботу розробника з інструментом.
Різні стеки — різні сценарії: чому вибір моделі важить для реального коду
Цей whiteboard‑челендж показав не лише різницю в швидкості, а й те, як моделі “мислять” щодо стеку й структури проєкту.
Composer 2.5, працюючи у швидкому режимі, одразу обрав React і TypeScript на клієнті та окремий сервер. Це дає розробнику знайому архітектуру, яку легко розширювати: можна додати авторизацію, історію змін, інтеграцію з базою даних чи аналітикою, не змінюючи фундаментальних рішень.
Opus 4.7, навпаки, пішов шляхом простішого JavaScript + CSS без фреймворку та типів. Для маленьких демо‑проєктів це може бути прийнятно, але для реальної розробки в команді та довгострокової підтримки такий стек швидко стає тягарем. Відсутність типів ускладнює рефакторинг, а відсутність React — побудову складних інтерфейсів із передбачуваним станом.
GPT 5.5 показав, що може не лише обрати сучасний стек, а й додати до нього інженерні практики: тести, спільні типи між клієнтом і сервером. Це важливо там, де якість і надійність коду критичні, навіть якщо час генерації більший.
На цьому фоні оцінка автора, що саме реалізація Composer 2.5 виглядала найкращим стартовим варіантом, виглядає логічно. Вона поєднує сучасний стек, робочий стан застосунку й дуже швидкий час отримання результату. GPT 5.5 додає “плюшки” у вигляді тестів, але коштом очікування. Opus 4.7 у цьому конкретному завданні програв і за швидкістю, і за якістю.
Швидкі режими Cursor: коли “fast” і “medium-fast” б’ють по гаманцю
Окремий вимір цього порівняння — вартість. Cursor дозволяє вмикати так званий “max mode”, який відкриває доступ до fast і medium-fast режимів для моделей. Це робить інференс значно швидшим, але й помітно дорожчим.
За словами автора тесту, увімкнення fast або medium-fast режимів у Cursor піднімає ціну за токен приблизно в шість разів. І саме тут виявляється одна з найсуттєвіших переваг Composer 2.5.
При використанні Opus 4.7 у medium-fast режимі загальна вартість виконання завдань може бути приблизно в 20–25 разів вищою, ніж при використанні Composer 2.5 для того ж самого завдання. Це корелює з офіційними даними Cursor: на їхньому внутрішньому бенчмарку середня вартість одного завдання для Composer 2.5 становить близько 0,50 долара, тоді як для Opus 4.7 — близько 7 доларів. Cursor сам підкреслює, що це приблизно 14‑разова різниця в ціні на користь Composer 2.5.
У реальному сценарії з колаборативною дошкою ця різниця посилюється ще й тим, що Opus 4.7 у підсумку не видав робочий застосунок, тоді як Composer 2.5 — так. Тобто розробник не лише платить більше за токени, а й витрачає додатковий час на виправлення або повну перегенерацію рішення.
GPT 5.5 у цьому порівнянні займає проміжну позицію. У тесті він працював у medium-fast режимі й витрачав 10–20 хвилин на завдання, але при цьому видавав робочий застосунок із тестами й спільними типами. Вартість такого запуску вища, ніж у Composer 2.5, але точних цифр у цьому фрагменті не наводиться. Автор припускає, що GPT 5.5, ймовірно, дешевший за Opus 4.7, але все одно суттєво дорожчий за Composer 2.5.
Для розробників це означає, що вибір моделі в Cursor — це не лише питання якості коду, а й прямий вплив на бюджет, особливо якщо активно використовувати швидкі режими. Composer 2.5 у цьому контексті виглядає як “робоча конячка”: швидко, дешево й достатньо якісно для більшості реальних задач.
Коли швидкість важливіша за ще кілька відсотків якості
У синтетичних бенчмарках різниця між моделями часто вимірюється кількома відсотками точності. У випадку Composer 2.5 Cursor сам визнає, що на деяких тестах Frontier‑моделі на кшталт GPT 5.5 або Opus 4.7 можуть показувати трохи кращі результати. Проте в реальних робочих сценаріях ці 2–3 відсотки часто губляться на фоні інших факторів.
Whiteboard‑челендж добре демонструє, що для розробника критично важливі три речі: чи працює застосунок, наскільки він відповідає звичному стеку й наскільки швидко можна отримати перший робочий варіант. У цьому трикутнику Composer 2.5 показав себе як модель, яка дає “достатньо хорошу” якість при значно кращих показниках швидкості й вартості.
GPT 5.5 залишається привабливим вибором там, де важливі тести, сувора типізація й додаткові інженерні практики, навіть якщо це означає довше очікування й вищу ціну. Opus 4.7 у цьому конкретному тесті виглядає найменш привабливо: повільніше, дорожче й без робочого результату.
Цей баланс між “максимальною можливою якістю” та “оптимальною для роботи комбінацією швидкості, ціни й якості” стає ключовим при виборі інструментів для щоденного кодування. І саме тут Composer 2.5, за підсумками цього експерименту, виглядає конкурентним не лише технічно, а й економічно.
Висновок: Composer 2.5 стає серйозним гравцем для щоденного кодингу
Тест із колаборативною whiteboard‑дошкою в Cursor показав, що новий Composer 2.5 — це не просто “ще одна модель” у списку. У реальному завданні він:
помітно перевершив Opus 4.7 за швидкістю,
згенерував сучасний стек на React і TypeScript з окремим сервером,
видав робочий застосунок за 3–4 хвилини в fast‑режимі,
і при цьому коштував на порядки дешевше в перерахунку на завдання.
GPT 5.5 продемонстрував сильну сторону у вигляді тестів і спільних типів, але за ціну довшого часу виконання й вищої вартості. Opus 4.7 у цьому конкретному сценарії виявився повільнішим, дорожчим і менш вдалим з точки зору результату.
Для розробників, які працюють у Cursor і регулярно запускають складні завдання в fast або medium-fast режимах, вибір моделі стає питанням не лише зручності, а й економіки. Composer 2.5 у цьому контексті виглядає як прагматичний дефолт: швидкий, дешевий і достатньо потужний, щоб конкурувати з Frontier‑моделями в реальних проєктах.