Revolut says self-hosting an open model cut its AI coding bill by 90%: what that figure actually counts

A story has been going round this week that a major fintech has cut its AI costs by 90% by abandoning frontier models for its own servers. The real version is more specific, and more useful, than the headline. Revolut has said that for one workload, its internal coding assistant, it moved from paying for Claude Code and OpenAI’s Codex to running an open-weight model on its own GPUs, and that this cut the per-token cost by roughly 90%. That is a genuine, large-scale example of exactly the thing this site is about, self-hosting open weights. It is worth getting right rather than cheering, because the interesting part is what the 90% does and does not count.

What Revolut actually said

The source is a roughly twelve-minute talk by David Abitbol, described as Revolut’s operations and infrastructure lead, at the AI Engineer conference, posted on 29 October 2026, written up by The Register on 3 November. We have not watched the talk in full, so every figure here is Revolut’s own, as relayed from that talk, and none of it has been independently measured. A separate Revolut conference session, on an in-house model-serving system the company calls PRAGMA, independently supports that Revolut runs its own inference, but it is a different talk.

The specifics, as reported:

• The workload is the internal coding assistant used by about 2,000 Revolut engineers. This is developer tooling, not Revolut’s customer-facing product, and not fraud, anti-money-laundering or risk systems. Headlines implying Revolut “dropped OpenAI and Anthropic” across the board overstate it.
• The model is Z.ai’s open-weight GLM, first the 5.1 release and later migrated to 5.3. (Some write-ups say GLM-4.5; given the timeframe, 5.1 then 5.3 is the more credible reading, and we are flagging the discrepancy rather than smoothing it over.) It is served on 56 Nvidia B200 GPUs, which is seven eight-GPU nodes.
• The cost claim is a blended serving cost of about $0.30 per million tokens, which Revolut puts at roughly one tenth of the per-token price of Codex or Claude Code. Hence “90% cheaper”, or ten times cheaper, “in less than a year”.
• It is a hybrid setup, not a clean break. GLM is text-only, so a model router sends vision and interface-image tasks to frontier models such as Gemini or GPT, and the frontier coding tools remain available for harder problems.

What the 90% counts, and what it leaves out

This is the part worth slowing down on. The 90% is a per-token price comparison: about $0.30 per million tokens served from their own GPUs, against roughly ten times that to rent the equivalent from a frontier coding API. As a production per-token result at Revolut’s scale, it is believable. What it is not is a fully-loaded cost of the capability.

The figure does not include the hardware. Fifty-six B200s is serious capital: industry estimates put a complete eight-B200 server somewhere around $450,000 to $500,000, and Revolut runs seven nodes’ worth. It does not include the infrastructure engineers who build and run the serving stack, or the months of tuning that got the per-token cost down. A token-price line that looks ten times cheaper is not the same as a total cost of ownership that is ten times cheaper.

It also depends on keeping those GPUs busy. Self-hosted inference economics are a function of utilisation: the same hardware that serves tokens cheaply when saturated serves them expensively when idle. One analysis of self-hosted coding costs puts the swing at roughly $10 per million output tokens at full utilisation against around $200 per million at 5% utilisation. Revolut can stay near the cheap end precisely because 2,000 engineers generate steady demand, and because it can shape that demand, with sandbox rules and by leaning on the working day, so the cluster rarely sits idle. A ten-person team cannot, which is why this result does not port directly down in scale.

Revolut also reported large productivity gains, in the region of 60% on coding time and 70% on lead time. These are the softest numbers in the story: self-reported, on their own 2,000-engineer sample, with no methodology given. We would not lean on them.

The parts that are genuinely interesting

Two things here are more than a cost table.

The first is the data-governance argument, which lands squarely in the case for keeping AI in-house. Abitbol’s framing, as reported, is that the risk with a Chinese-developed model like GLM is in calling a China-hosted API, not in the open weights themselves. Running the weights on infrastructure you control removes the data-transfer question entirely. That is the sovereignty argument for local AI made by a regulated financial company, not a hobbyist, and it arrives in the same month as China’s draft rules on exporting frontier models, which make the provenance and hosting of open weights a live question rather than an abstract one.

The second is the engineering, which shows what “cheap” actually requires. The reported stack leans on NVFP4 quantisation on the Blackwell GPUs, which Abitbol credited with roughly a 40% cut in GPU footprint over FP8 with no meaningful quality loss for this use, along with disaggregated prefill and decode and a good deal of context-length and hyperparameter tuning. Holding a 256,000-token context reportedly needs eight-way tensor parallelism rather than four, to fit the KV cache. Time-to-first-token is said to have fallen from over ten seconds to about 1.6. None of that is free, and all of it is the work the 90% headline quietly assumes. GLM is a large mixture-of-experts model, so this is firmly server-class serving with vLLM or SGLang-style infrastructure, not a workstation.

Does this mean you should self-host?

For most people and most teams, not for cost alone, and the honest way to find out is to run your own numbers rather than borrow Revolut’s. Our cost calculator exists for exactly this: it compares the upfront hardware cost and the electricity to run it against the per-token price of an API, and it counts the things the 90% figure leaves out. Put in your own usage and it will tell you plainly when the API is the cheaper option, which at low volumes it usually is. Revolut’s result is what the far end of the curve looks like when the volume is enormous and someone can keep the hardware saturated.

Where self-hosting an open model does make sense, the reasons tend to stack up together, as they do for Revolut: high and steady volume, a workload a strong open model handles well, the engineering to serve it efficiently, and a genuine reason to keep the data in-house. On a single one of those, the API usually wins. This is a real and welcome data point for the case that capable local AI is viable at scale. It is not a reason to assume it is cheaper for you.