How Revolut Cut AI Coding Costs 90% With Self-Hosted Open Models - David Abitbol, Revolut

Revolut’s early coding-agent rollout had an awkward combination: some engineers were spending a thousand or even ten thousand a month, while the delivery gains were hard to justify. David Abitbol, who leads AI operations at the European digital bank, develops the alternative through an engineering-performance chart and the infrastructure needed to make AI use less constrained by individual budgets.

Abitbol describes a sample of roughly 2,000 engineers. The chart’s date labels run from January 2025 through July 2026. The blue line measures coding time in hours on its own axis. The green line measures lead time in days, from picking up a feature until it is merged and ready to deploy. Coding can get faster while work elsewhere in the delivery process still takes days.

What changed when engineers first received AI access? The initial Gemini rollout in January 2025 let them use private company data with AI. Abitbol reports a 20% improvement in coding time and a 10% improvement in lead time, attributing the gains to less searching through Stack Overflow and documentation. The two chart lines make that distinction worth inspecting: the improvement in the coding portion was larger than the improvement across the feature’s full journey.

Experiments with Claude Code followed, then a wider rollout with strict budget limits. Its early impact was less convincing relative to the spending. That produced a concrete infrastructure question: could Revolut give engineers effectively unlimited tokens, so they could use AI “guilt-free,” at a fraction of the metered cost?

Revolut began self-hosting open models around April and favored GLM for coding. Abitbol reports a 60% improvement in coding time and 70% in lead time. The slide labels lead time as a 60% improvement. It shows how both measures changed during the rollout, but gives too little detail about the comparison periods and aggregation to reconcile the two lead-time figures. The trends are observational. They do not isolate GLM’s effect from other changes at Revolut.

Abitbol connects the lead-time improvement to work outside the editor. Searching an inbox or working through Jira and Confluence takes time between picking up a feature and merging it. Engineers who save scarce tokens for coding still do that work by hand. With a larger allowance, they can use the same tools for both.

The resulting policy makes open models the priority and frontier models the exception. Revolut still uses Codex, Claude Code and Gemini; self-hosting does not require declaring those tools obsolete. The attraction is a flat infrastructure bill without monthly usage surprises, while retaining access to other models when their capabilities justify it.

Serving those 2,000 engineers takes roughly 56 GPUs in Abitbol’s account, hosting a GLM model he describes as having 800 billion parameters. That establishes the scale of the deployment, rather than a universal sizing rule: the rest of the talk shows how strongly the same fleet’s performance depends on workload and serving configuration.

The first service target is time to first token: how long a request waits before output begins. Revolut aims for less than three seconds. Beyond five seconds, Abitbol’s Slack inbox starts filling with complaints. This is an empirical usability threshold from his engineers, not a benchmark score chosen independently of their work.

Output speed after that first token matters less in the workflow he describes. Around 200 tokens per second is sufficient because engineers increasingly launch tasks in parallel and check back when they finish, rather than watching the stream of thinking tokens. Lower contention can still produce a spectacular number: after 5 p.m., he says, an engineer can see 800 tokens per second. But that off-peak experience is not the service target for a busy shared fleet.

The cost slide quotes $0.30 per million tokens for input and output, with cached tokens free. Abitbol says the invoice was one-tenth of what Revolut had spent with Anthropic and OpenAI. The 90% figure compares bills. The slide gives neither matched usage and billing periods nor the engineering cost of running the service.

Abitbol warns that simply loading model weights onto GPUs can produce poor performance; serving settings need to match the workload. To show the difference, he introduces another chart: blue now means demand in requests per second, while red means time to first token. The question is whether the service can begin answering promptly as more requests arrive, without increasing the GPU count.

The serving chart follows the same 56 B200 GPUs through the migration. Time to first token falls from 14.26 seconds mid-migration to 1.68 seconds once the service is stable. That is an 88% reduction in the wait before the first output appears, enough to bring it below the team’s three-second target.

On the same slide, Revolut reports 76% higher requests per second. Abitbol describes the plotted demand as roughly three requests per second in April and more than seven in August. Those approximate readings do not establish the baseline for the slide’s 76% figure. The fleet served more requests while the wait for the first token fell.

Abitbol recommends testing how much context the team actually needs. His slide contrasts 256k and 1M tokens: longer context consumes more KV-cache capacity for little gain in this workload. That trade-off matters when the same GPUs must keep many engineers’ requests moving.

• Quantization: Abitbol favors FP4 for the GPU generation he discusses and reports roughly 40% lower GPU footprint without a precision loss. However, the spoken comparison names a move from FP4 to FP8 while recommending FP4, leaving the direction inconsistent. The supported recommendation is to investigate low-precision serving; the 40% figure is not a reproducible conversion rule as stated.
• Tensor parallelism: Fitting the model is only the first capacity test. GLM can fit at TP4, yet leave insufficient room for the key-value cache used during inference. Abitbol suggests that TP8 may work better, depending on workload size. The decision therefore includes space for serving active requests, not only space for model weights.
• Cache hits: For coding workloads, he sets a target above 90% cache hits. This makes cache reuse a first-class serving metric alongside request rate and latency, rather than an incidental optimization.

He also points to optimized speculative decoding and prefill-related optimizations, without developing their implementations. Those are further tuning directions, not individually measured explanations for the fleet-wide gain. The detailed example he does supply is the TP4 versus TP8 decision: a model that fits can still be configured poorly for the amount of work engineers ask it to handle.

The production discussion introduces a capability tradeoff. The GLM deployment described here is text-only. Abitbol would choose the stronger model for the main coding task and solve image recognition separately, rather than make vision support the deciding criterion for every request. A local router can send image-recognition work to a model such as Gemini while keeping GLM on the main task.

Which work goes to which model? The routing proposal below shows a branch by capability, not a sequence in which every request must pass through two models. The main task stays with GLM; image recognition takes the vision-capable route. Abitbol also reports that UI designers have made useful progress with a vision-capable model, although he gives no measured turnaround comparison for that work.

The agent harness is a separate choice from the model endpoint. Abitbol describes OpenAI-compatible endpoints with Responses API support, used through OpenCode, Claude Code and Codex, including the Codex app. In this setup, moving inference to self-hosted weights need not require abandoning the coding interface engineers already use.

The closing infrastructure questions are for the CIO. Abitbol separates the origin of model weights from the destination of inference traffic: downloading a Chinese open model and running it on a US-based service does not require sending inference requests to a China-hosted endpoint. Hosting location is therefore a decision Revolut can make independently of where the model was developed.

For an EU-regulated bank, the next issue is what the coding agent can actually do. Abitbol describes Revolut’s coding tasks as human-in-the-loop work rather than autonomous agents. A sandbox makes that distinction operational by defining which operations may proceed and which are not allowed. His concrete example is allowing grep but not Gradle: the policy distinguishes individual tools instead of granting unrestricted execution and relying on a general promise of supervision.

The sandbox serves several purposes in parallel:

• Human oversight: Operation rules and approval features support the supervised workflow Abitbol wants regulators to see.
• Internal misuse: Restrictions also provide a shield against rogue use by people inside the company.
• Prompt injection: Abitbol remains concerned about injection, even while expressing confidence in more capable models. The need for restrictions does not disappear with that confidence.

Data location and retention are another pair of deployment requirements. Abitbol lists the US, EU, UK and Israel as locations acceptable under the data-equivalence arrangements he invokes, and says inference or GPU providers offer zero retention by default. These statements describe his compliance framing, not a blanket guarantee for every provider or regulated workload. The consequential deployment questions remain where inference data goes and what the selected service retains.

Finally, the service needs strong telemetry. If an incident occurs, the team must be able to go deep into the logs and reconstruct what happened; the same instrumentation also supports usage analytics. That is where the talk ends: inexpensive tokens still need controlled execution and an inspectable production system around them.