How Revolut Cut AI Coding Costs With a Self-Hosted GLM Model

Revolut says it cut its AI coding bill to about a tenth by self-hosting an open-weight GLM model on 56 Nvidia B200 GPUs for around 2,000 engineers. The figures come from the company's own conference talk, not from an audit. They describe one deployment at high, steady use, so they do not transfer to a team with lighter or spikier demand.

This post sets out what was said, why it plausibly worked, and the arithmetic that tells you whether it would work for you. Every Revolut figure below is the company's own. Our arithmetic is labelled as such.

How did Revolut cut its AI coding costs?

David Abitbol, who says he leads AI operations at Revolut, gave the talk on 13 October 2026 at AI Engineer NYC. Its title was "Shipping like a startup, regulated like a bank". Revolut started self-hosting in late April, on GLM-5.1, and now serves GLM-5.3, both open-weight models from Z.ai. The transcript says "around April 26"; it does not give the year, so we read it as April 2026.

The headline numbers, as the talk page records them:

• Scale: "to serve 2,000 engineers, we roughly need 56 B200."
• Cost per token: a blended cost "is 30 cents per million", which the page summarises as near $0.30 per million tokens.
• Invoice: "our invoice is one-tenth of what we were spending on Anthropic and OpenAI."
• Latency: time to first token (TTFT) fell "from 14.26 seconds during migration to 1.68 seconds in the stable setup", with "76% higher requests per second".

Frontier models did not disappear. The talk calls the frontier "the exception", and Revolut keeps Codex and similar tools for the hardest work. It routes image recognition to other models, because GLM here is used as a text model.

The talk never states a percentage saving. "About 90%" is how headlines translated "one-tenth", and it is our arithmetic on the company's wording, not a number Revolut gave.

What are the talk's own caveats?

The talk page carries its caveats, and any retelling should too. We fetched the page on 9 November 2026 and read these lines:

• "The internal comparison does not isolate the model change from other causes."
• "Those figures describe Revolut's deployment and utilization, not a portable price for any self-hosted model."
• The page also notes that machine transcription may contain recognition errors.

Three further points come from our own reading, not from Revolut.

First, the figures are unaudited company claims. No Revolut blog post or press release repeats them, and we found none.

Second, the productivity numbers are loose. The talk reports a 60% improvement in coding time and a 70% improvement in lead time after the GLM-5.1 rollout, across a sample of 2,000 engineers over a year. The same talk says the comparison does not separate the model from other changes. It also reports smaller gains from earlier tools. Treat these as the company's impression, not a measured effect of the model.

Third, the spoken request rates do not match the slide. The slide says 76% higher requests per second. The speaker also says rates of "around 3" and "over 7", which would be a larger rise. We quote the slide and flag the mismatch.

Several summaries name a different GPU provider or a different model version. The talk page itself names no GPU vendor beyond the B200 and says weights run "on a US-based service" from a GPU provider. One press report attributes the hosting to a named provider. We could not confirm that, so we leave it out. One summary also gives an "around 800B" parameter count for GLM-5.3. The transcript figure is garbled, so that is not confirmed either.

Why did it work for Revolut?

The talk gives enough to see the shape of the answer. Three things stand out.

High, steady utilisation. A GPU costs the same per hour whether it serves one request or a hundred. Two thousand engineers using a default coding assistant keep a cluster busy through the working day. The talk mentions about 200 tokens per second at a typical rate and up to 800 after hours, when the load drops. That is the pattern where owning capacity pays: constant demand, predictable peaks.

A 256K context cap. Abitbol's line is "long context is a scam". He says that although you can serve a million tokens, "256 is really what you need". We read this as an operating policy: cap the window and the KV cache stays small enough to serve more users per GPU. Use the quote carefully. It is one engineer's view of one coding workload, and it will not hold for document analysis.

Tuning for time to first token. The talk sets a target of under 3 seconds and treats anything over 5 as a failure. The speaker discusses separating prefill from decode and recommends a cache-hit rate above 90% for coding workloads. He also says that although GLM fits on four-way tensor parallelism, "you don't have enough KV cache", so eight-way "maybe" works better. It favours FP4 weights: "you don't want to run anything higher than FP4." The fall from 14.26 to 1.68 seconds is about 88% (our arithmetic), and the slide agrees.

None of this is secret. The speaker's own words are "there's no secret recipe". It is operations work: capacity planning, serving configuration, and watching queues. That work has a cost the talk does not price, namely the engineers who do it.

How many GPUs does a self-hosted coding model need?

Revolut's number is 56 B200 GPUs for about 2,000 engineers. That is roughly 36 engineers per GPU (our arithmetic: 2,000 divided by 56). It is a result for that workload, with a 256K cap and FP4 weights. It is not a rule.

NVIDIA's DGX B200 page lists 1,440 GB of total GPU memory for an eight-GPU system. NVIDIA does not give a per-GPU figure there, so 180 GB per GPU is our division. On that basis 56 GPUs hold about 10,080 GB (our arithmetic). Revolut does not say how that is divided between weights and cache. The talk does say that although GLM "fits on TP4", there is not enough KV cache, so an eight-way split can work better. Our inference: the cluster likely runs as several eight-GPU replicas, 56 divided by 8 being 7, but the talk does not state this.

The practical lesson is that weights are not the binding constraint for a model like this at FP4. Cache for concurrent sessions is. If you size only for weights, you will undersize. Our post on why the cluster is rarely the bottleneck covers the usual mistakes, and our trillion-parameter GPU requirements guide shows the same method for much larger models.

Is self-hosting an LLM cheaper than an API?

Sometimes. It depends on one ratio: tokens served per GPU-hour against the price of a GPU-hour. Here is the formula, with the inputs shown.

Monthly cluster cost = GPUs x price per GPU-hour x 730 hours. Cost per million tokens = monthly cost divided by monthly tokens in millions.

We do not have Revolut's GPU price, so we vary it. The three prices below are assumptions for illustration, not quotes from any provider. Use your own contract price.

Our arithmetic throughout. The $1 and $3 API prices are placeholders for a blended input and output price, not any vendor's rate card. Replace them with your measured blend.

Read the table by row. At an assumed $3 per GPU-hour, 56 GPUs cost $122,640 a month. To land at Revolut's $0.30 per million, that cluster must serve about 408.8 billion tokens a month, which is roughly 204 million tokens per engineer for 2,000 engineers. That is an inference from our assumed price, not a Revolut figure. It is plausible for agentic coding, where cached context is re-read on every step, but it is not a light load.

Now run the other direction. A smaller team might rent one eight-GPU node. At the same assumed $3, that is 8 x $3 x 730 = $17,520 a month. Against an API at $1 per million blended, the node breaks even at about 17.5 billion tokens a month. Below that, the API is cheaper before you count any engineering time. Above it, the node starts to win, provided the open model is good enough for the work.

Two corrections matter in practice. First, API prices for cached input are far lower than the blended figure, so use your real cache-hit mix. Second, add staff time. One platform engineer at, say, a fifth of their week is a real line item that the cluster cost above does not include.

Our rule from this arithmetic: self-hosting pays when demand is high and steady, the quality gap is acceptable, and someone owns operations. It does not pay for spiky or low-volume use.

What do other companies show?

Revolut is one data point. Other public cases provide less detail.

Cursor. TechCrunch reported on 22 March 2026 that Cursor's Composer 2 started from Moonshot's open-source Kimi K2.5. Cursor's Lee Robinson confirmed it, saying "only ~1/4 of the compute spent on the final model came from the base". Co-founder Aman Sanger said it was "a miss to not mention the Kimi base in our blog from the start". This is about choosing an open base to train from. It gives no cost saving, and we found no before-and-after comparison.

Airbnb. Chief executive Brian Chesky was reported in October 2025 as saying Airbnb relies heavily on Alibaba's Qwen for customer service, calling it "fast and cheap". We could not open the SCMP page, which returned an error, so this is reported through a secondary source. It also gives no saving figure.

That is the honest state of public evidence. One company has published a cost ratio, in a talk, with caveats. Others show that open models are used in production, not what they saved. If you read a claim like "10x cheaper after fine-tuning Mistral", ask for the source. We searched for one attributed to Shopify and found none, so we do not repeat it.

For a view across the models themselves, see our comparison of the best open-weight LLMs in 2026.

How can a regulated company self-host an LLM?

Revolut is a regulated bank, and the talk is partly about that. It is also a good place to be careful, because the talk page is explicit about its limits. It says the remarks "describe his view of Revolut's circumstances" and "should not be read as a general determination that a model, region, or sandbox automatically satisfies" a regulator's requirements.

What the talk does say is useful but narrow. The speaker's advice is that your inference or GPU provider should have zero data retention by default, and he lists the US, EU, UK and Israel as places you can get GPUs. The weights are public, so you are "just getting the weights and putting them on a US-based service". The model sees only your traffic. That removes one party from the data path, which is why regulated teams look at it.

It does not remove the work. Self-hosting moves responsibility for patching, access control, logging, incident response and model review onto you. The talk page itself notes that self-hosting leaves Revolut responsible. If you are in a regulated sector, the questions that matter are:

1. Where do prompts and outputs go, and who can read the logs?
2. Who approves a model version change, and how do you roll back?
3. Can you show a regulator which model produced which output?
4. What licence applies to the weights, and does it permit your use?
5. How do you verify the weights you downloaded are the weights that were published?

Our guide to model supply chain security covers questions 4 and 5. Nothing here is legal advice, and we make no statement about any regulator's expectations.

What is the hybrid routing pattern?

Revolut did not replace the frontier. It put a cheap open model on the default path and kept frontier models as the exception. That is a routing pattern, and it is the part most teams can copy without buying a GPU.

The pattern has four parts.

1. Default to the cheap path. Send routine coding requests to the self-hosted or low-cost model.
2. Escalate on need. Route hard tasks, or tasks where the cheap model fails a check, to a frontier model.
3. Send unsupported inputs elsewhere. Revolut routes image recognition away from its text-only model.
4. Fall back when the cheap path is down. A capacity incident on your own cluster should not stop engineers working.

The talk's cost story depends on step one carrying most of the traffic. If the frontier handles half your requests, the ratio changes. Measure the share of requests that genuinely need the expensive model before you commit to hardware. Our overview of intelligent LLM routing explains the routing side in detail.

Where Swfte sits

You can build the hybrid pattern in Swfte today, whether or not you own GPUs. Here is the path, step by step.

1. Serve your model. Run vLLM or SGLang on your own GPUs and expose its OpenAI-compatible endpoint.
2. Put it behind Connect. Swfte Connect is one OpenAI-compatible API. Models not in its catalogue are treated as bring-your-own-key with an optional base URL. Built: a custom endpoint, such as your own vLLM server, can sit behind routing, failover, usage caps, cost tracking and the audit event stream. Confirm compatibility with your serving setup before you deploy.
3. Add a hosted fallback chain. When a provider is out of funds, rate-limited or down, Connect can fall back to another provider in the chain. Chains cover those failures, not a malformed tool call inside a successful response, so keep your own validation.
4. Set usage caps. When a workspace reaches a cap, Connect can move its requests to a cheaper model. A cap downgrades the model; it does not stop all spend.
5. Keep the weights governed. Model Vault lets you bring your own weights, version them, promote them through stages and deploy them to a dedicated endpoint.

For coding agents, Swfte Nexus wraps Claude Code and Codex with a policy gate (allow, deny, ask), an audit trail and completion gates. That matters when frontier tools stay in the loop as they did at Revolut. The enterprise deployment generator produces Terraform, Helm and Docker Compose bundles. Generating one requires a licence key, and dedicated deployment is available on request.

Swfte does not publish a benchmark figure for agent runs, and we make no claim that using Swfte will reproduce Revolut's savings.

The decision rule is short. If your GPU demand is steady and high, price a cluster with the table above. If it is not, buy the default path by the token and spend your effort on routing and evaluation.

---

Related: Best open-weight LLM in 2026, Why the cluster is rarely the bottleneck, Self-hosted ChatGPT alternatives compared, GPU requirements for trillion-parameter open models.

Sources: AI Engineer NYC 2026, Revolut talk (David Abitbol, 13 October 2026) · TechCrunch, Cursor admits its new coding model was built on Moonshot AI's Kimi (22 March 2026) · NVIDIA, DGX B200 · SCMP, Airbnb picks Alibaba's Qwen (could not be opened; reported) · accessed 9 November 2026.

Method note: we re-read the Revolut talk page and the NVIDIA and TechCrunch pages on 9 November 2026. Revolut's figures are the company's own, from a conference talk, and are not audited or independently reproduced. GPU prices and API prices in the break-even table are assumptions for illustration, not quotes. Worked examples are our arithmetic, not measurements.