Що саме зламалося на практиці
Я люблю такі кейси не за хайп, а за зіткнення з реальністю. У публічному відгуку про GLM Coding Pro людина оплатила підписку, запустила модель у CC-обгортці й майже одразу зіткнулася з набором проблем, який для продуктивної роботи звучить як червоний прапор.
Список простий і неприємний: все гальмує, чати іноді зникають із помилкою на кшталт «chat not found», власні тулзи та MCP відвалюються, а іноді система просто висить без результату. Вишенька на торті: окремі запити можуть «думати» по 10 хвилин і не зробити взагалі нічого.
І тут цікавий контраст. За публічними оглядами та бенчмарками картина у GLM зовсім інша: хороші результати в coding-завданнях, сильний tool calling, нормальні оцінки в agentic workflow. Тобто на папері модель виглядає бадьоро.
Але папір не дебажить пайплайн. Якщо в мене агент втрачає стан посеред сесії, забуває чат або не може стабільно викликати інструмент, мені вже не так важливо, який у нього відсоток успіху в красивому тесті на 52 завданнях.
Де могла сховатися проблема
Я б не робив поспішний висновок, що сам GLM «поганий». Тут занадто багато шарів: модель, провайдер, план підписки, вебклієнт, CC-обгортка, MCP-сервери, мережа, ліміти та черги на боці сервісу. Будь-який із цих вузлів може влаштувати вам свято.
Власне, в тому ж обговоренні людині одразу запропонували прогнати це не в CC, а в іншій обгортці, наприклад через pi/opencode. І це слушна думка. Я сам багато разів бачив, як одна й та сама модель у різних клієнтах відчувається як два зовсім різні продукти.
Але для користувача це слабка втіха. Коли людина купує Coding Pro, вона купує не «потенційно сильну модель за вдалого збігу інтеграційних обставин», а робочий інструмент.
Що це змінює для бізнесу та автоматизації
Якщо ви обираєте стек під розробку, сапорт або внутрішнього агента, такий відгук не можна списувати як одиничну істерику. В ШІ-автоматизації вбиває не середня якість відповіді, а нестабільність у довгому ланцюжку: агент узяв завдання, сходив у тулзу, зберіг контекст, повернувся, продовжив. Коли цей цикл рветься, економіка розвалюється.
Особливо боляче це б'є по сценаріях, де потрібен stateful-процес (процес зі збереженням стану): кодинг-агенти, розбір тікетів, багатокрокові асистенти, інтеграції через MCP, n8n та внутрішні API. Одне «вічне зависання» може з'їсти не тільки час, а й довіру команди до системи загалом.
Тому я зазвичай дивлюся не на гасло «дешевше за Claude/OpenAI». Я дивлюся на три речі: як поводиться контекст після 20-30 повідомлень, як стабільно викликаються інструменти, і наскільки передбачувана латентність у години навантаження. Ось там і проявляється справжня AI-архітектура, а не маркетинг.
Хто виграє на тлі такого відгуку? Ті, у кого є запасний маршрут і нормальна архітектура маршрутизації моделей. Хто програє? Команди, які будують впровадження штучного інтелекту навколо одного провайдера без фолбеків, логування та контролю стану сесій.
Як би я це перевіряв перед впровадженням
Я б не ховав GLM з одного відгуку, але і в прод без стрес-тесту не пустив би. Мінімальний тест для бізнесу тут очевидний: довга сесія, кілька tool calls поспіль, MCP, зміна контексту, пікове навантаження і замір реальної затримки, а не рекламної.
Ми в Nahornyi AI Lab якраз так і підходимо до відбору моделей під ШІ-рішення для бізнесу. Не сперечаємося в повітрі, а збираємо конкретний сценарій, ганяємо його в бою і дивимося, де модель сиплеться: у ціні, у швидкості, у пам'яті чи в інтеграції.
Цей розбір зробив я, Вадим Нагорний з Nahornyi AI Lab. Я руками збираю ШІ-інтеграції, агентні пайплайни та автоматизацію за допомогою ШІ, тому мені цікаві не обіцянки, а те, що реально живе в продакшені.
Якщо хочете перевірити ваш кейс, зробити ШІ-автоматизацію, замовити ШІ-агента на замовлення або n8n-автоматизацію без ворожіння на бенчмарках, пишіть мені. Я допоможу швидко зрозуміти, де тут робочий стек, а де красива демка.