Revolut Cut Its AI Coding Bill by 90 Percent by Running Its Own Models

November 05 2026 05:39
Every engineering leader has had the same uneasy moment in the past two years. You hand your developers a powerful AI coding tool, the usage numbers climb, and then the invoice arrives. That was the situation at Revolut, the digital bank that now serves 80 million customers across 45 markets. At a talk at AI Engineer NYC on October 13, David Abitbol, who leads AI operations at the company, walked through what happened next. Revolut moved roughly 2,000 engineers off metered AI APIs and onto open source models it hosts itself. Coverage of the talk reports that the move cut AI coding costs by 90 percent, running on 56 Nvidia B200 GPUs.



Revolut is Europe's largest private company, as Abitbol pointed out in his talk, and one report put its private valuation at 115 billion dollars in October. Its culture is built around shipping product constantly.


That culture is why the company watches engineering performance so closely. Abitbol showed a chart tracking a sample of 2,000 engineers over the past year, with two lines. One was coding time, measured in hours. The other was lead time, which runs from the moment an engineer picks up a feature until it is merged and ready to deploy, measured in days.


The timeline on that chart is worth walking through, because the early results were underwhelming.

• Early in the rollout, Revolut introduced Gemini, the first time people could use private company data inside an AI tool. Lead time improved by about 10 percent and coding time by about 20 percent. Abitbol's read was that engineers no longer needed to dig through Stack Overflow and documentation.
• Later, the company launched Claude Code at scale. The impact on the chart was small, and the costs were not. Abitbol said some engineers were spending $1,000 to $10,000 a month with little visible return, so Revolut launched the tool with strict budget limits.
• In April 2026, Revolut began self hosting open source models, with a strong preference for GLM from Z.ai for coding work. The first model was GLM 5.1. After that switch, coding time improved by about 60 percent and lead time by about 70 percent.

The model was not necessarily better than the frontier tools the company had already tried. What changed was that engineers stopped rationing.



Abitbol drew a lesson from the gap between those two numbers. Lead time improved more than coding time, which suggests that writing code is not the main thing slowing engineers down.

A lot of an engineer's week goes to digging through an inbox, hunting through Jira and Confluence, and stitching together context from five places. An AI agent can do much of that tedious work. But when every token costs real money and you have a budget, you save your tokens for the end of the quarter or the hardest problem. Nobody spends them on tidying up a ticket.


A flat, predictable cost changes behavior. Engineers use the tool for the boring jobs too, and the boring jobs are where the hours hide. It is a bit like the difference between a taxi and a car you own. When the meter is running you take fewer trips, even the useful ones.

Abitbol also said Revolut has no bill shock now, because the cost is flat. Frontier tools like Codex and Claude Code have not gone away. The company keeps them, along with Gemini, as the exception for harder problems.



The model Revolut hosts today is GLM 5.3, and its design explains a lot about the hardware choices that follow.

Z.ai released GLM 5.3 in August 2026. It is not a brand new network. It is post trained on the same 744 billion parameter mixture of experts base as GLM 5.2. Z.ai attributes the gains to a much larger post training effort rather than a bigger model, and that claim has not been independently audited.

Here is what the published details say about the architecture.

• Size: about 744 billion parameters in Z.ai's rounded label. The exact count in the Hugging Face safetensors metadata is 753,329,940,480. You will see both numbers quoted, and they describe the same model.
• Mixture of experts design: 256 routed experts and one shared expert, with eight routed experts chosen for each token.
• Depth: 78 layers, the first three of them dense.
• Active parameters: roughly 40 billion per token. That is the figure that sets how much compute each token needs.
• Context: a 1 million token window with 128,000 tokens of maximum output.
• Download size: near 1.5 terabytes at BF16, roughly half that at FP8, before any KV cache is allocated.

That last point is the one people miss. Only a fraction of the experts fire for any single token, which cuts compute. It does not cut storage. Later tokens may pick other experts, so the deployment still needs the entire checkpoint in memory. That is why a model that sounds manageable at 40 billion active parameters still needs serious hardware.

For contrast, one hobbyist guide found that a 256GB Mac Studio running the smallest usable quant of this family managed only about 3 to 9 tokens per second. Revolut targets around 200 tokens per second per user, for 2,000 users at once. That gap is the difference between a weekend experiment and a production service.

There is also a smaller sibling worth knowing about. GLM 5.3 Flash has 320 billion total parameters and 18 billion active. It is the first GLM 5 model with image input. That fits what Abitbol said about teams that need a vision model. Revolut's UI designer has been using a lighter GLM variant and has seen product turnaround improve a lot. The transcript of the talk is garbled at that point, so I am reading his reference to a flash variant as this model, but I could not confirm the exact name.


One thing changed between GLM 5.2 and GLM 5.3 that any company should check before copying Revolut. The full GLM 5.3 weights landed on August 28 under a custom license rather than the MIT license used for GLM 5.2. The license adds a Z.ai security review for AI service companies above 10 billion dollars in revenue. The Flash model stayed under plain MIT.


That is a detail for your legal team, not a verdict on whether it applies to you. But it is a good reminder that open weights and open source are not the same thing, and the terms can change from one release to the next.


The talk was unusually concrete about the hardware and the targets, which is what makes it useful for anyone considering the same path.

• Serving 2,000 engineers takes roughly 56 Nvidia B200 GPUs to host GLM 5.3. Independent coverage worked out that this is about 36 engineers per GPU.
• The target for time to first token is under 3 seconds. Abitbol said that once it passes 5 seconds, his Slack inbox starts to blow up.
• Interactivity of about 200 tokens per second is enough. People no longer watch the stream of thinking tokens. They kick off tasks in parallel and check in when the work is done.
• The blended cost is about 30 cents per million tokens. That is where the 90 percent savings figure comes from.

For comparison, Z.ai charges 1.40 dollars per million input tokens and 4.40 dollars per million output tokens for its own hosted API. Revolut's blended 30 cents is a fraction of that, though the two are not a clean comparison.

One caveat is worth keeping in mind. A write up from AI Chat Daily noted that the 30 cent figure leaves out cloud spend, staffing and observability costs. The savings are real by Revolut's account, but a team copying this plan should budget for the people and tooling around the GPUs, not just the GPUs.

Abitbol also offered a fun aside about off hours. If an engineer connects after 5 p.m. when the GPUs are quiet, throughput can reach about 800 tokens per second, which he described as a dream.



If you think self hosting means renting some GPUs, copying the weights across and pointing your engineers at them, Abitbol would like a word. He said that approach produces terrible performance, because results depend heavily on the parameters you set.

He showed a chart that makes the point well. When the project started in April, the system handled around 3 requests per second and had a time to first token of over 10 seconds. By August, on the same number of GPUs, it handled more than 7 requests per second with a time to first token of about 1.6 seconds. That is roughly an 88 percent performance improvement while demand grew by about 76 percent.

His advice was blunt. There are many parameters to tune, and you should resist the urge to throw more hardware at the problem.


Abitbol did not claim there is a secret recipe, but he did share the settings his team considers first.

1. Cap the context window. He called long context a scam. Even though the model can serve a million tokens, 256,000 is what a coding workload really needs.
2. Choose the right quantization. On Blackwell generation GPUs, he suggested not running anything higher than FP4. By his account, moving from FP8 to FP4 saves about 40 percent of the GPU footprint with no loss in precision.
3. Think about tensor parallelism. The model fits on four GPUs, but that leaves too little KV cache for a heavy workload, so eight can work better.
4. Watch the cache hit rate. For coding tasks, it should be above 90 percent.
5. Look at the more advanced options once the basics are done, including speculative decoding, sequential prefill and prefill decode disaggregation.

If those terms are new to you, the common thread is memory. Coding agents send the same large chunks of repository context again and again, so keeping that context cached and sized sensibly matters more than raw GPU count. The cache hit rate matters for cost too. Z.ai's own API charges 26 cents per million cached input tokens, against 1.40 dollars for uncached ones. Even the vendor's pricing rewards the same habit.


It is fair to ask whether a cheaper model gives up quality. The wider picture suggests the gap has narrowed a lot, with the usual warning that most numbers below come from the vendor.

On GLM 5.3, Z.ai reports Terminal Bench 3.0 rising from 4.6 to 28.3 and DeepSWE v1.1 from 46.2 to 66.9, figures that independent testers have not yet reproduced. The same report says Z.ai admits GLM 5.3 still trails the top closed models on several harder coding tests. Independent index scores also vary a lot depending on which version of the index a source used, so I would not lean on any single ranking.

Earlier in the year, GLM 5.1 claimed first place on SWE Bench Pro at 58.4 percent, edging out Claude Opus 4.6. The pattern is consistent. Open weight models are close enough on coding that cost and control start to matter more than small benchmark gaps.

Revolut is not alone in this. A Business Engineer analysis noted that Decagon described its workflows as roughly 90 percent open source and 10 percent closed source. Both companies seem to keep a frontier model for a narrow slice of hard work and move the routine, repeatable tasks to models they control.


GLM 5.3, as Abitbol described it, is a text only model, which is a real limitation for some teams. His answer was to take the smarter model every time and handle images another way.

One option is a local router that sends any image recognition work to another provider, such as Gemini, while GLM handles the main task. If you really need a vision model, a lighter GLM variant works well, as described above.

For the harness, all of Revolut's endpoints expose an OpenAI compatible API with the Responses API. That means engineers can use them inside OpenCode, Codex and the Codex app, which keeps the day to day experience familiar.


The part of the talk I found most useful for non engineers was the last one, aimed at the CIO in the room. Abitbol acknowledged a stigma around Chinese open source models, then offered a plain answer. Revolut is not sending data to an endpoint in China. It downloads the weights and runs them on infrastructure in the US and Europe.

Because Revolut is a bank regulated in the EU, it operates under one of the strictest compliance regimes there is. Here is what he said works.

• Keep a human in the loop. These coding tools are not treated as autonomous agents, because a person reviews and approves the work.
• Build a sandbox that proves it. Codex and Claude Code already have approval features. You set rules for the operations you do not want to allow, such as permitting grep but not Gradle. That gives a regulator confidence that this is not an autonomous system needing different supervision.
• Use the same sandbox against bad actors. Abitbol said you would be surprised what you find in a large company, and a sandbox limits what any rogue user can do.
• Stay alert to prompt injection. He said it matters less now that models are smarter, but it never goes away.
• Keep data in the right places. Hosting in countries covered by the data equivalency framework, including the US, EU, UK and Israel, is fine, and GPU providers typically offer zero data retention by default.
• Invest in observability. Strong OpenTelemetry means that if an incident happens, you can dig into the logs, and you get analytics as a bonus.

Revolut has 2,000 engineers and the in house skill to tune inference engines. That is not most companies. Other analysts have been careful on this point. One MindStudio guide says self hosting a model in this class makes sense in narrow scenarios, such as strict data sovereignty rules, very high and predictable volume, or air gapped environments.

A smaller team might do better with a hosted open model or a flat subscription. The break even point depends on how many tokens your engineers burn, and I would not trust any rule of thumb you read online, including the ones in this post. Measure your own traffic first.

Revolut stopped treating AI tokens as a scarce luxury and started treating them as a utility with a predictable bill. It measured the thing that matters, which is lead time from idea to deployable code, and it found that removing the fear of the meter did more good than any single model upgrade.

If you lead an engineering team, the question to ask is not which model is the smartest. Ask where your engineers hold back because of cost, and what they would do with the freedom to use AI on every boring task. For Revolut, answering that question was worth a 90 percent cut in cost and a big jump in speed.