Новий MiniMax M3 стрімко з’явився в інструментарії розробників як надзвичайно дешевий, але доволі сильний AI‑помічник для коду. Блогер Tech With Tim, який регулярно працює з різними моделями в IDE Cursor, вирішив порівняти MiniMax M3 з Composer 2.5 — своїм звичним “робочим конем” для щоденного програмування. Він прогнав обидві моделі через три різні сценарії: створення вебдодатку з нуля, складний бекенд на Rust і доопрацювання великого продакшн‑коду.
Порівняння показало не просто різницю в швидкості та якості, а й те, чим принципово відрізняються “швидкі” моделі від тих, що заточені під довгі, контекстно насичені завдання.
Базовий розклад сил: швидкий Composer проти “довгого” MiniMax
У Cursor автор зазвичай використовує Composer 2.5. Причина проста: ця модель дуже швидка, має хорошу продуктивність і не така дорога, як топові флагмани. Саме її він узяв як реалістичний бенчмарк для щоденної роботи: невисока ціна, звичні промпти, інтеграція в IDE.
MiniMax M3, навпаки, одразу показує інший характер. Вбудований у Cursor через сумісний з OpenAI API інтерфейс, він працює помітно повільніше, зате агресивно використовує величезне контекстне вікно, постійно викликає інструменти, аналізує результати й переписує власний код. Це не просто “модель для автодоповнення”, а щось ближче до автономного агента, який спочатку думає, потім багато разів перевіряє, а вже після цього завершує задачу.
Щоб побачити, як це відчувається в реальній розробці, автор “прогнав це через три різні типи промптів… побудова з нуля, системний код і великий рефактор”.
Вебдодаток з нуля: структура проти мінімуму
Перший тест — класика для AI‑кодера: побудувати URL‑shortener з нуля в одному проєкті на Node.js з API‑ендпоінтами, дашбордом і чистим сучасним UI.
Обидві моделі впоралися із завданням: вебдодаток запускається, посилання скорочуються, кліки рахуються, є світла та темна теми, базова валідація URL. На рівні демо обидва рішення виглядають “готовими”. Але внутрішня картина радикально різна.
MiniMax M3 “реально написав значну кількість коду… в нас тут 21 файл… воно навіть написало повні тести”. Код розбитий на конфігурацію, базу, обробку помилок, різні маршрути, сервіси, утиліти. Файли невеликі, логіка рознесена, до того ж — згенероване тестове покриття для застосунку.
Composer 2.5 підійшов до задачі інакше: “composer дав сім файлів… просто напхав усе в ці файли… не створив гарної структури, як Miniax”. Основна логіка сервера зосереджена в одному великому файлі, стилі — в одному ж великим блоком, база — без додаткової модульності. Жодних тестів, мінімум валідації. Зовні задача виконана, але всередині це радше прототип, ніж каркас продакшн‑додатку.
Ціна структурованості — час. “Miniax зайняв значно більше часу… composer відпрацював приблизно за дві хвилини, а Miniax — десь за 15”. MiniMax спочатку спроєктував код на рівні текстового чернеткового плану, лише потім почав створювати файли, активно відкривав браузер, запускав тести, багато разів викликав інструменти й самокритично правив власні рішення. При цьому він використав лише частину свого гігантського контексту.
У Composer підхід ближчий до звичного “згенерувати та забути”: один великий прохід, швидкий вивід коду, мінімум додаткових перевірок. Для прототипів або коли головне — швидко побачити щось працююче, це може бути плюсом. Але як тільки розробнику потрібна структура, тести й масштабованість, MiniMax дає якісно інший рівень.
Системний код на Rust: коли важливий не лише результат, а й шлях до нього
Другий тест вивів моделі з комфортної веб‑зони. Обидві отримали завдання написати трасувальник променів на Rust з нуля, який рендерить сцену з кількома сферами на шаховому полі в PPM‑файл, без залежностей.
Результати візуалізації розставили акценти. Composer згенерував картинку, яка формально нагадувала сцену, але мала суттєві артефакти: зображення вийшло “догори ногами”, некоректно поводилися віддзеркалення, шахівниця виглядала дивно, частина елементів ніби віддзеркалена чи зміщена.
Зображення, яке породив MiniMax M3, виявилося значно ближчим до очікуваного: правильна орієнтація сцени, логічне розміщення об’єктів, відчуття об’ємності. Воно теж не було ідеальним, але саме розподіл світла, розміщення куль і вигляд поверхні більше відповідали типовому результату трасування променів.
При цьому обсяг коду у двох моделей вийшов приблизно подібний — кілька файлів, відносно чиста структура. MiniMax додавав більше коментарів та пояснень, Composer — майже нічого не коментував. Головна відмінність знову ж таки в процесі: “було схоже, як і раніше: composer відпрацював значно швидше, але не дав нам такої хорошої віддачі, а Miniax працював набагато довше, але дав щось значно більш придатне”.
Саме тут особливо помітно, як “з тим, як MiniAAX спроєктований, він реально розрахований на довготривалі завдання… повністю використовує контекстне вікно, робить багато аналізу”. У ланцюжку повідомлень MiniMax видно довгу низку кроків, проміжних міркувань і корекцій. Composer натомість поводиться як класичний код‑генератор: бере промпт, обчислює найвірогідніший шаблон коду, виводить і зупиняється.
Для розробників це означає, що на складних алгоритмічних або системних завданнях, де помилка в математиці чи геометрії фатальна, довші розгони MiniMax можуть окупатися якістю.
Великий продакшн‑код: хто краще “вбудовується” в існуючий проєкт
Третій сценарій наближений до того, з чим розробник стикається в реальній роботі: не зелений field‑проєкт, а складний, уже існуючий продукт з бекендом на Python, великим фронтендом на TypeScript і чималою кількістю неідеального, “живого” коду.
Завданням було додати нову фічу — “daily streak” для студентського дашборду. Система мала відстежувати, скільки поспіль днів студент розв’язав хоча б одне DSA‑завдання, з відповідними бекенд‑ендпоінтами, сервісною логікою та UI‑компонентами. Тобто моделі мали спочатку розібратися в архітектурі, потім обережно увійти в наявні файли, додати нові, не поламавши те, що вже працює.
Тут тренд повторився. MiniMax довго аналізував репозиторій, робив набагато більше викликів інструментів і в певний момент ще продовжував аналіз, коли Composer уже завершив роботу. У результаті вийшло два працюючі варіанти, але з різним ступенем “вшитості” в систему.
В UI від Composer з’явився новий компонент для streak, однак змін небагато: один основний блок, прості інтеграції, менше тестів і коментарів. MiniMax, за спостереженнями автора, змінив більше частин системи, додав розлогіший код, детальніші коментарі та тести, зробивши функцію більш органічною частиною продукту. У студентському дашборді, згенерованому MiniMax, з’явився, наприклад, показник “best streak” — ознака того, що модель не просто додала лічильник, а спробувала розширити саму концепцію функції.
Сумарний висновок із цього сценарію схожий: MiniMax повільніший, але ретельніше “вростає” в наявний код, Composer — швидший, але схильний робити мінімально необхідні доповнення.
Висновок: дві філософії AI‑кодування — і коли яку обирати
Непряме порівняння MiniMax M3 і Composer 2.5 в трьох сценаріях задає зрозумілу рамку для розробників, які підбирають собі AI‑модель в IDE.
Composer 2.5 — це про швидкість та “досить добре” рішення. Він миттєво відповідає, видає робочий код, не обтяжує себе зайвою структурою, валідацією чи тестами. Для невеликих завдань, експериментів, чернеток і задач, де людина планує одразу вручну переробити код, це зручний інструмент.
MiniMax M3 будує іншу цінність. Він охоче витрачає час і токени на роздуми: проєктує структуру, пише тести, переглядає власні рішення, повноцінно використовує велике контекстне вікно й активно працює з інструментами. З відносно простої задачі URL‑shortener він робить невеликий, але вже схожий на продакшн‑додаток; на Rust‑тестах видає якісніший результат, а в реальному репозиторії поводиться як уважний колега, а не просто автогенератор.
На фінальному етапі автор підсумовує: модель “дуже продуктивна. Це не найшвидша модель у світі”, але завдяки такій архітектурі та великим лімітам вона добре працює саме на довготривалих завданнях, де треба аналізувати великі обсяги коду й не боятися лімітів. “З тим, як MiniAAX спроєктований, він реально розрахований на довготривалі завдання… повністю використовує контекстне вікно, робить багато аналізу”.
Для команд, які пишуть та підтримують складні системи, це означає простий вибір: якщо головне — миттєва віддача, Composer лишається зручним інструментом. Якщо ж важливі структура, тестованість і глибокий аналіз великого коду за прийнятні гроші, MiniMax M3 виявляється значно привабливішим варіантом.