Self-Hosted AI Coding Infrastructure: What Revolut's Cost Collapse Tells Engineering Leaders About Build vs Buy

Revolut's reported 90% reduction in inference costs, achieved by migrating from Claude to self-hosted GLM models running on NVIDIA B200 GPUs, has circulated widely enough to land on the agenda of most engineering leadership teams. The reaction is understandable: if a fintech at that scale can cut nine-tenths of its AI coding tool spend, the build-vs-buy calculation looks very different than it did eighteen months ago. The problem is that Revolut's outcome is real but not portable. It reflects a specific combination of developer headcount, GPU capital commitment, and internal MLOps maturity that most enterprises have not yet assembled. This article works through what that combination actually requires, and where commercial providers retain a genuine total-cost-of-ownership advantage.

Companion piece to our broader work on open-weight model economics. See Token Bill vs Self-Hosted: Enterprise AI Cost Strategy for a detailed treatment of how open-weight models are reshaping enterprise AI cost structures.

The Inference Economics That Make Self-Hosting Attractive

Commercial AI coding tools price on a per-seat or per-token basis. At low developer headcount, that model is efficient because you pay for consumption without carrying idle infrastructure. The economics invert as headcount grows, because token volume scales with the number of active developers while the marginal cost of an additional self-hosted inference request approaches zero once the GPU cluster is provisioned.

The B200 GPU is central to why Revolut's numbers look the way they do. The architecture delivers substantially higher throughput per chip than its predecessors, which means fewer nodes are required to serve a given request volume. When you amortise hardware cost across thousands of developers generating continuous completions, the per-token cost can fall well below what frontier API providers charge, particularly for a model like GLM that is smaller and faster to serve than a 100B+ parameter frontier model.

The critical qualifier is utilisation. A GPU cluster serving a developer tool needs to sustain high utilisation across working hours to justify its capital cost. Organisations with fewer than several hundred active developers will struggle to keep the cluster busy enough, and the fixed cost per token rises accordingly.

What Developer Headcount Threshold Actually Triggers the Case

There is no universal crossover point, but the structural logic points toward a range. A single H100 or B200 node costs roughly $30,000 to $40,000 per year in cloud rental or proportionate capital depreciation. A commercial coding assistant at $20 to $40 per developer per month costs between $240 and $480 per developer per year. That means a single GPU node needs to serve the equivalent of 60 to 170 developers at full utilisation before it breaks even on cost alone, before accounting for the engineering time required to operate it.

In practice, self-hosting requires more than one node for redundancy, and it requires headcount to manage model updates, inference serving, and integration with developer tooling. A realistic minimum operational overhead is one to two senior ML engineers, which adds $300,000 to $500,000 in fully loaded salary cost annually. That overhead needs to be absorbed across the developer base. At 500 developers, it represents $600 to $1,000 per developer per year before any hardware cost, which erodes the margin quickly unless token volume is very high.

The honest threshold for a compelling case is somewhere above 1,000 active developers, with high daily usage patterns. Below that, the operational overhead dominates.

GPU Infrastructure Requirements and Hidden Costs

Choosing the right GPU generation matters more than it might appear. The B200 achieves its throughput advantage through higher memory bandwidth and improved attention computation, which directly reduces the latency of autoregressive token generation. For a coding assistant where developers are waiting on completions in real time, latency is a quality-of-service metric, not just a cost metric.

Cluster Architecture

A production inference cluster for a large developer tool program needs to handle burst load during peak hours, typically the first few hours of the working day across time zones. Autoscaling on bare metal is slower than on managed cloud infrastructure, so organisations typically either overprovision or accept degraded latency during peaks. Both choices have cost implications that do not appear in the headline per-token calculation.

Networking and Storage

High-throughput inference also places demands on interconnect and storage infrastructure that are easy to underestimate. Serving a 70B parameter model requires fast access to model weights on every request, and the storage and networking costs associated with that are real line items in the infrastructure budget.

Operational Maturity: The Threshold That Disqualifies Most Organisations

The infrastructure cost is visible and can be modelled. The operational maturity requirement is less visible and harder to acquire quickly. Running a self-hosted inference service for a developer tool is not the same as deploying a batch inference pipeline. It requires low-latency serving, high availability, graceful degradation under load, and continuous model evaluation as newer open-weight releases appear.

Organisations that have not already built and operated a production ML serving stack will face a longer ramp than they typically anticipate. The first three to six months are often absorbed by infrastructure provisioning, integration work, and reliability engineering before any meaningful cost saving is realised. During that period, commercial providers are still paying the bills.

Model quality management is a second operational dimension. Open-weight models improve rapidly, and the version of GLM or a comparable model that delivers acceptable code quality today may be superseded within six months. Evaluating, fine-tuning, and deploying model updates requires a systematic evaluation framework tied to real developer productivity metrics, not just benchmark scores.

Where Commercial Providers Retain the Advantage

For organisations below the headcount and maturity threshold, commercial providers offer something that is genuinely difficult to replicate: operational simplicity with no capital commitment and no engineering overhead. The per-token cost is higher, but the total cost of ownership is often lower once the full cost of self-hosting is accounted for.

Commercial providers also retain an advantage at the frontier. The largest and most capable models are not available as open weights. For coding tasks that require deep reasoning across large codebases, the performance gap between a frontier proprietary model and the best available open-weight alternative is still material in many cases. If that performance gap translates into measurable developer productivity, the cost comparison changes.

The practical framework for engineering leaders is to measure actual developer productivity impact before optimising infrastructure cost. Organisations that have not yet established a rigorous measurement framework for AI coding tool ROI are optimising the wrong variable.