Что именно сломалось на практике
Я люблю такие кейсы не за хайп, а за трение с реальностью. В публичном фидбеке по 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-автоматизацию без гадания на бенчмарках, пишите мне. Я помогу быстро понять, где тут рабочий стек, а где красивая демка.