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, а на час завершення задачі, частоту відкатів і дефекти після злиття.
Реакція розробників теж може бути негативною, навіть якщо фінансова модель працює. Інженер одразу відчуває гіршу відповідь, а компанія бачить сукупну економію пізніше. Головне невирішене питання просте: де проходить межа, після якої дешевий токен починає створювати надто дорогий код?