Технічний контекст
Я люблю такі порівняння набагато більше, ніж стерильні бенчмарки. Cline взяв реальний баг зі свого репозиторію і прогнав через дві моделі: Opus 4.8 закінчив швидше, а GLM-5.2, за їхніми словами, вийшов дешевшим і акуратнішим. Для мене це вже не просто новина, а нормальний сигнал для практичного впровадження ШІ в інженерні пайплайни.
Що мене зачепило: GLM не просто видав патч, а дочистив мертвий код і прогнав компіляцію перед фінішем. Ось на таких дрібницях і видно, наскільки модель придатна для автоматизації розробки, а не лише для красивих скріншотів.
Тут, звісно, не треба фантазувати зайвого. За підтвердженими метриками GLM-5.2 не обганяє Opus 4.8 у важких coding-бенчмарках: на SWE-Marathon відстає приблизно на 13%, а на Terminal-Bench 2.1 йде близько, але все ще позаду. Зате це, схоже, найсильніша відкрита модель у своєму класі.
І ось де починається найцікавіше. У GLM-5.2 MIT-ліцензія, відкриті ваги на Hugging Face, контекст 1M токенів і ціна API приблизно $1.40 за вхід і $4.40 за вихід на мільйон токенів. Якщо порівнювати з Opus 4.8, різниця у вартості виходить дуже помітною, а для великих репозиторіїв і агентних сценаріїв це вже впливає на архітектуру, а не лише на рахунок наприкінці місяця.
Я б ще додав ложку тверезості: один кейс від Cline не перетворює GLM на вбивцю Opus. Але він добре показує інше: open weights модель уже вміє поводитися як адекватний інженерний агент, а не як іграшка для локального ентузіазму.
Вплив на бізнес та автоматизацію
Якщо я збираю AI automation для команди розробки, тут одразу бачу три практичні висновки. Перший: дешевий довгий контекст дозволяє завантажувати майже весь репозиторій без агресивної нарізки, а це менше втрат стану і менше дивних регресій.
Другий: MIT і self-hosting різко спрощують AI integration там, де код не можна ганяти через закриті зовнішні API. Особливо в enterprise і в продуктах із жорсткими вимогами до даних.
Третій: програш Opus за швидкістю або якістю на частині завдань не завжди критичний, якщо GLM дає нормальний результат за значно менші гроші. На масштабі це вже різниця між “цікаво погратися” і “можна впроваджувати в прод”.
Але тут легко наступити на граблі: без нормальної оркестрації, перевірок, sandbox і правил завершення навіть сильна модель почне плодити сміття. Ми в Nahornyi AI Lab якраз такі речі й збираємо для клієнтів: не чатик заради чатика, а робочий AI solution development під реальні обмеження команди.
Якщо у вас розробка тоне в рутинних фіксах, рев’ю і рефакторингу, я б не сперечався у вакуумі, хто “кращий на бенчі”. Краще подивитися на ваш стек і потоки задач: у Nahornyi AI Lab ми з Vadym Nahornyi можемо зібрати AI automation так, щоб модель реально знімала навантаження з команди, а не додавала ще одне джерело хаосу.