Канал Tech With Tim протестував нову модель MiniMax M3 у реальних сценаріях розробки й порівняв її з популярною моделлю Composer 2.5. Формально це звичайний огляд інструмента для кодування, але між рядків проглядається інша, важливіша історія: як поєднання гігантського контекстного вікна і дуже дешевого токен-ліміту змінює спосіб, у який розробники можуть мислити про довгі AI-сесії, автономні агенти й роботу з великими репозиторіями.
Де грає роль контекст: 12 годин автономної роботи
Один з ключових аргументів на користь MiniMax M3 — не стільки “розумність” моделі, скільки те, як вона поводиться у довгих безперервних сесіях.
Команда MiniMax, як навели в огляді, запускала модель в автономному режимі протягом 12 годин. За цей час агент “міг продовжувати виконувати, лупитись без людського втручання”, виконуючи послідовності викликів інструментів і тримаючи весь ланцюжок міркувань у пам’яті. Демонстрація виглядає як стрес-тест саме контекстного вікна: чи не “забуде” модель, що робила годину тому, коли дійде до чергового кроку.
Ключовий висновок з цього експерименту прозвучав прямо: “це просто показує, що контекстне вікно працює і модель може робити купу tool calls перед тим, як зрештою здатися”. Іншими словами, фокус не на одному ідеальному виклику, а на десятках і сотнях кроків — аналіз, планування, правки, тести, нові спроби.
У практиці розробника це відкриває простір для сценаріїв, які ще недавно виглядали екзотикою:
- довгі автономні “рани” агента, який годинами рефакторить, тестує або збирає складну фічу;
- інструментальні ланцюжки, де модель постійно ходить у браузер, тести, build-систему;
- поступове наростання контексту замість агресивного “забуття” частини історії через ліміт.
MiniMax M3 не позиціонують як найкращу модель на ринку, але саме її здатність тримати великі діалоги та довго “думати” над задачами стає одним із центральних аргументів.
Мільйон токенів у дії: як виглядає велика сесія в IDE
Практичний тест на розробці вебзастосунку показав, як велике контекстне вікно використовується в реальній IDE. MiniMax M3 отримала завдання створити з нуля веб‑додаток для скорочення URL‑адрес. Модель писала код істотно довше за Composer 2.5 — приблизно у кілька разів — але при цьому поводилася як педантичний інженер.
Вона спершу “накидала” загальний драфт усіх файлів і архітектури, а вже потім переходила до інструментальних викликів: створення файлів, редагування, запуск тестів, відкриття браузера. Кожен крок супроводжувався додатковим аналізом та самокритикою: модель переписувала частини коду, змінювала структуру, додавала валідацію й тести.
У підсумку отриманий проект вийшов великим і добре структурованим: 21 файл, розділені конфігурація, база даних, хендлінг помилок, сервіси, утиліти, повний набір тестів та перевірки в UI. Це був не “мінімально робочий прототип”, а радше невеликий, але повноцінний застосунок.
При цьому, навіть після досить тривалої сесії, виявилося, що “ми лише на приблизно 106 000 із загального вікна в 1 мільйон токенів”. Фактично модель встигла:
- прийняти первинний промпт;
- спланувати структуру застосунку;
- згенерувати значний обсяг коду у кількох файлах;
- зробити багаторазові правки й тести;
- тримати весь цей процес у єдиному діалозі.
І все це — десь на десятій частині доступного контексту. Тобто, простору вистачає не лише на початкову генерацію, а й на подальші великі цикли “аналіз → правки → тести” у рамках тієї ж сесії.
Для робочих сценаріїв це означає, що розробник може не боятися “забити” контекст кількома сотнями кілобайт коду, історією тасок і логами проміжних спроб: місця все одно залишається достатньо, аби модель продовжувала адекватно орієнтуватися в проєкті.
Дешевий довгий контекст: ефект на інженерні звички
Окремий пласт дискусії стосувався вартості. MiniMax M3 інтегрується через токен‑плани, які дають дуже великий обсяг токенів за фіксовану суму. Після трьох повноцінних тестів — з вебдодатком, складним завданням на Rust і додаванням нової фічі у велику існуючу кодову базу — автор звернувся до дашборда й побачив, що “зараз не думаю, що я навіть використав 2% мого 5h hour limit, що просто insane”.
Це не абстрактне враження, а конкретний досвід: кілька важких сесій у IDE з численними інструментальними кроками, рендерами, тестами й тривалим аналізом великого репозиторію забрали лише невелику частину доступного ресурсу.
Звідси головний практичний висновок: “це означає, що я можу реально ганяти це і використовувати по максимуму, не хвилюючись про будь-які constraints, price тощо”. Замість постійного контролю ліміту й вимкнення agent‑режимів, щоб “не спалити бюджет”, модель можна тримати “розкрученою” годинами.
Такий ціновий профіль безпосередньо впливає на інженерні звички:
- вже не потрібно стискати промпти “до кісток”, викидаючи корисний контекст;
- не так страшно запускати довгі автономні агенти, які сотні разів сходять у файлову систему, тести чи браузер;
- можна дозволити собі підтримувати довгі історії в IDE‑чаті, не обнуляючи контекст щоразу, коли задача ускладнюється.
І в підсумку змінюється сама парадигма використання LLM: модель стає не одноразовим “запит-відповідь” сервісом, а постійним фоновим гравцем у розробницькому процесі, який не вимикається після перших 10–20 хвилин роботи.
Довгі dev‑цикли: коли повільніше, але глибше — краще
Порівняння з Composer 2.5, який у тестах стабільно працював значно швидше, додає ще один важливий штрих. MiniMax M3 програє за швидкістю, але компенсує це більш глибоким аналізом і готовністю “копатися” у задачі довше.
На тесті з трасуванням променів на Rust обидві моделі впоралися з завданням технічно: згенерували код, який компілюється й рендерить зображення. Проте детальний розбір виявив, що у виведеній Composer картинці були проблеми з орієнтацією та відображеннями — зображення довелося перевертати, а віддзеркалення об’єктів виглядали некоректно.
Версія MiniMax дала більш послідовний результат: правильну орієнтацію сцени, переконливі відображення й загалом більш “об’ємну” картинку. При цьому обсяг коду був схожим, але MiniMax знову витратила помітно більше часу, проходячи більше інструментальних кроків і проводячи детальніший аналіз.
Схожа картина повторилася на великій існуючій кодовій базі, де моделі мали додати нову фічу — “щоденний стрик” у дашборді студентів. Завдання вимагало попередньо розібратися в численних Python‑модулях бекенду та великому фронтенді на TypeScript, а потім внести зміни в різні файли та шари застосунку.
Composer завершив роботу значно швидше й додав мінімальний UI‑компонент, що відображав стрик. MiniMax витратила набагато більше часу: довше аналізувала репозиторій, робила більше змін і доповнила інтерфейс додатковими деталями, зокрема показником “best of” для серії днів. Знову спрацювала та сама логіка: модель використовує час, щоб ретельніше пропрацювати задачу в ширшому контексті, а не просто “закрити” її мінімальною функціональністю.
У підсумку сформулювали просте, але показове резюме: “для 90+% завдань ви будете в кращому становищі, використовуючи щось таке, бо це просто набагато дешевше і все одно робить роботу”. Не йдеться про абсолютну перевагу у всіх сценаріях — а саме про те, що в більшості повсякденних задач різниця в якості не виправдовує різницю в ціні з дорогими моделями, особливо коли мова про довгі, інструментально насичені dev‑цикли.
Коли обмеження відходять на другий план
Сукупність цих факторів — велетенське контекстне вікно, реальна здатність тримати довгі ланцюжки tool‑calls та наднизька вартість токенів — створює для розробників нову стартову точку.
Якщо надскладну, критичну задачу, де важлива кожна деталь, і надалі може бути сенс віддати дорожчій і потужнішій моделі, то для більшості рутинних або середньої складності робіт MiniMax M3 дозволяє просто не думати про обмеження. А коли розробник перестає постійно озиратися на ліміти, він починає користуватися моделлю інакше: довше тримає її “в курсі” про проєкт, частіше довіряє їй довгі автономні рини, не стискає промпти до рівня телеграми.
MiniMax M3 показує не стільки майбутнє “ідеальних” моделей, скільки майбутнє доступних, довгих AI‑сесій у розробці — коли ціна й контекст більше не диктують архітектуру робочого процесу.