Revolut runs GLM 5.3 for 2,000 engineers on 56 B200s: what David Abitbol's talk actually says

Revolut gives about 2,000 engineers a self-hosted GLM 5.3 as their default coding model, served from 56 Nvidia B200 GPUs at a blended cost of about $0.30 per million tokens, and keeps Claude Code and Codex for the exceptions. That is the version of the story that has been all over X since Monday. It comes from a 12-minute talk David Abitbol, who leads AI operations at Revolut, gave at AI Engineer NYC on October 13, "Shipping like a startup, regulated like a bank". The conference has published a write-up and a full transcript, and they are worth reading, because the headline numbers are the least technical part of what he said.

What the numbers are, and what they aren't

Abitbol opens with a chart of two internal measures for a sample of about 2,000 engineers: coding time, in hours, and lead time, in days, from picking up a feature to having it merged and ready to deploy. Gemini, introduced at the start of 2025, brought about 10% on lead time and 20% on coding time, he says. Claude Code, "not so much impact at the time". Some engineers were spending "a thousand a month, 10,000 a month with not so much ROI", so Revolut rolled it out with strict budget limits.

Self-hosting started in April 2026 with GLM 5.1, and the chart then shows about 60% better coding time and 70% better lead time. That is the figure going viral as "coding time down 60%". The conference's own write-up adds a caveat the reposts drop: the internal comparison "does not isolate the model change from other causes".

There is also a confound built into the setup. The Claude Code that had little effect was the budget-capped one; the GLM that coincided with the jump came without one, so engineers, in his words, "no longer have to save your tokens for the end of the quarter or the most difficult task". His own explanation is about the cap, not the model: with tokens no longer rationed, engineers hand the agent the inbox, Jira and Confluence work around the code, which is why lead time improved more than coding time. That may well be right, but it means the chart says more about removing a spending limit than about GLM versus Claude.

The money works the same way. $0.30 per million tokens is a blended figure for Revolut's own fleet at Revolut's utilization, and "our invoice is one-tenth of what we were spending on Anthropic and OpenAI" compares total bills, during a period when usage went up. The talk doesn't give a per-token comparison, and the write-up says the figures are "not a portable price for any self-hosted model". Some reposts also say Revolut rents its GPUs from a particular cloud; the talk doesn't name a provider. Abitbol only says the weights run on "a US-based service" and that the GPUs can sit anywhere in the US, EU, UK or Israel.

The part about serving

The more useful half of the talk is about what it takes to make 56 B200s feel fast to 2,000 people. Abitbol's targets are blunt: time to first token under three seconds, because "as soon as you exceed 5 seconds, my Slack inbox starts to blow up". Throughput matters less. Around 200 tokens per second is fine, he says, because engineers no longer watch the stream; they run tasks in parallel and come back when they finish. (After 5 p.m., he says, an engineer can get 800.)

Loading the weights was not enough. "If you just get GPUs and upload weights on a GPU and you start doing some inference, you're going to get terrible performance." The slide he shows holds the GPU count at 56 from April to August while requests per second rise 76% and time to first token falls from 14.26 seconds during the migration to 1.68 seconds, an 88% drop. His advice is to "resist scaling" until the configuration is tuned. The levers he lists:

• Context length. "Long context is a scam": even if you can serve a million tokens, 256K is what coding work needs, and every reserved token of context is KV-cache memory taken from concurrent requests. It's a pointed remark after Cloudflare's GLM-5.3 data leak, which began with a 1,048,576-token window on a KV cache pool that held only 681,280 tokens.
• Quantization. On Blackwell, nothing above FP4. Going from FP8 to FP4 saves about 40% of the GPU footprint "for zero loss in precision", he says; the talk shows no evaluation behind the "zero loss".
• Tensor parallelism. GLM fits on four GPUs, but TP4 leaves too little room for KV cache, so TP8 can serve the workload better.
• Cache hits. For coding, the prefix-cache hit rate should be above 90%. After that: speculative decoding, sequential prefill, and prefill/decode disaggregation.

GLM is text-only, and Abitbol would rather keep the stronger coding model and route images elsewhere, to Gemini or another model, through a local router than switch to a weaker multimodal one. The endpoints speak an OpenAI-compatible API, including the Responses API, so engineers keep their harness: he names OpenCode, Codex and the Codex app.

The bank part

The last two minutes are for the CIO. On the worry about Chinese open models, Abitbol's point is that downloading weights and running them on your own GPUs is not the same data path as calling a hosted API in China. For the regulator, Revolut frames coding agents as human-in-the-loop rather than autonomous, and backs that with sandbox rules instead of promises: "you can allow grep but not gradle". The same sandbox is meant to contain insiders with bad intentions and prompt injection, and everything goes into OpenTelemetry so an incident can be traced afterwards. The write-up is careful to call these his reading of Revolut's situation, not a ruling that applies to anyone else.

What the talk shows, then, is less "open models beat Claude" than a large company finding that a flat, uncapped bill changes how people use agents, and that getting there took months of serving work on a fixed fleet. The productivity chart is Revolut's own, uncontrolled, and the $0.30 belongs to Revolut. The latency numbers and the tuning list are the parts another team can actually use.