Revolut перевёл разработчиков с Claude на GLM
RevolutGLMopen-weight модели
Что именно Revolut поменял в AI-стеке
Для меня главный факт здесь не китайское происхождение модели, а масштаб переключения: Revolut, по сообщениям, сделал open-weight GLM стандартной coding-моделью примерно для 2 000 инженеров. В публикации Dealroom говорится о замене Claude Code, однако другие материалы уточняют, что дорогие инструменты сохранились для сложных и мультимодальных задач.
С точным чекпойнтом есть путаница. В одних сообщениях фигурирует GLM 5.3 от Z.ai, в других GLM-4.5, поэтому уверенно приписывать результат конкретной версии нельзя. Для инженерного разбора это не мелочь: разные версии означают разные качество, требования к инфраструктуре и воспроизводимость результата.
Заявленная экономика выглядит агрессивно: около 56 Nvidia B200 для самостоятельного хостинга, примерно $0,30 за миллион токенов в смешанном расчёте и сокращение прежних расходов на Anthropic и OpenAI примерно на 90%. Но $0,30 здесь является внутренней инфраструктурной оценкой, а не публичным API-тарифом. Сравнивать её напрямую с раздельной ценой входных и выходных токенов коммерческой модели некорректно.
И с качеством всё менее эффектно, чем с экономией. В обсуждаемом бенчмарке GDPx модель GLM получила 2,7% против 12,0% у Claude Opus 5.5. Artificial Analysis Intelligence Index v5 не подтверждает отдельное сравнение, проведённое Revolut: опубликованные там результаты относятся к другим условиям и моделям.
Также сообщалось об улучшении engineering lead time на 70%, но эта цифра подтверждена слабее оценки затрат. Я бы не связывал её с одной заменой модели без данных о типах задач, доле принятых подсказок и количестве последующих исправлений.
Экономия реальна, эквивалентность моделей нет
Это не история о том, что дешёвая GLM внезапно стала умнее Claude. Это история о маршрутизации качества: рутинный поток уходит на собственную дешёвую модель, а frontier-инструменты остаются для исключений, где ошибка обходится дороже токенов.
Такой подход выигрывает на большом объёме однотипных задач. При этом слабая модель способна незаметно перенести расходы из счёта за inference в ревью, повторные запросы и исправление кода. Первым я бы смотрел не на усреднённый benchmark, а на время завершения задачи, частоту откатов и дефекты после слияния.
Реакция разработчиков тоже может быть негативной, даже если финансовая модель сходится. Инженер ощущает худший ответ сразу, а компания видит агрегированную экономию позже. Главный нерешённый вопрос этого кейса простой: где проходит граница, после которой дешёвый токен начинает производить слишком дорогой код.