Revolut moved developers from Claude to GLM
RevolutGLMopen-weight модели
What Revolut changed in its AI stack
The key point for me is not that the model is Chinese, but the scale of the switch: Revolut reportedly made open-weight GLM the standard coding model for roughly 2,000 engineers. Dealroom described this as a replacement for Claude Code, although other reports clarify that expensive tools remain available for complex and multimodal work.
There is confusion about the exact checkpoint. Some reports mention Z.ai's GLM 5.3, while others cite GLM-4.5, so the outcome cannot confidently be attributed to a specific version. That is not a minor detail for an engineering assessment: different versions imply different quality levels, infrastructure requirements and reproducibility.
The claimed economics are aggressive: around 56 Nvidia B200 GPUs for self-hosting, roughly $0.30 per million tokens on a blended basis, and an estimated 90% reduction in previous Anthropic and OpenAI spending. But the $0.30 figure is an internal infrastructure estimate, not a public API rate. Comparing it directly with separate input and output token prices for a commercial model would be misleading.
The quality picture is less impressive than the cost story. In the discussed GDPx benchmark, GLM scored 2.7%, compared with 12.0% for Claude Opus 5.5. Artificial Analysis Intelligence Index v5 does not validate a separate comparison conducted by Revolut: its published results cover different conditions and models.
A 70% improvement in engineering lead time was also reported, but this number is less substantiated than the cost estimate. I would not attribute it to a model swap alone without data on task types, accepted suggestion rates and the volume of subsequent fixes.
Cost savings are real; model equivalence is not
This is not a story about cheap GLM suddenly becoming smarter than Claude. It is a story about quality routing: routine work goes to an inexpensive self-hosted model, while frontier tools are reserved for exceptions where mistakes cost more than tokens.
This approach works best at high volumes of repetitive work. Yet a weaker model can quietly shift costs from the inference bill to review, repeated prompting and code fixes. Before looking at an average benchmark, I would examine task completion time, rollback frequency and post-merge defects.
Developer reaction may also be negative even when the financial model works. Engineers immediately notice a weaker response, while the company sees aggregate savings later. The central unresolved question is simple: where is the point at which a cheap token starts producing code that is too expensive?