Token bill stamped minus 90 percent beside the words What 90% really costs

Revolut says it cut its AI coding inference costs by about 90% in under a year after making self-hosted GLM models its default. The Register reported the figures on November 3, from a talk David Abitbol, Revolut's ops and infrastructure lead, gave at the AI Engineer conference in New York in October. The headline spread fast, because many teams now have an AI bill that someone in finance has started asking about.

A 90% cut at a company with 2,000 engineers tells you very little about a team of 8, 40 or 150. This article pulls apart what Revolut reported, prices the same choice with today's public rates, and gives you a small script and a two-week test so you can work out your own number. Every price below comes from a vendor page linked in the Sources section. Where a figure is my own arithmetic or assumption, the text says so.

What Revolut actually reported

Revolut tried Gemini in early 2025 and Claude Code in early 2026, according to The Register. Abitbol said the company was highly skeptical of AI spending, because some engineers were spending about $1,000 or even $10,000 a month with little to show for it, so it launched with strict budget limits. It then moved its default to self-hosted open-weight models, starting with GLM-5.1 and later GLM-5.3.

The reported setup looks like this:

  • Roughly 2,000 engineers use the tools.
  • GLM-5.3 runs on 56 Nvidia B200 GPUs, equal to seven 8-GPU DGX B200 systems.
  • Self-hosting GLM 5.1 worked out to $0.30 per million input and output tokens, about a tenth of Codex or Claude Code.
  • At around 256K context, Revolut reports under 3 seconds to first token and about 200 tokens per second. Times above 5 seconds generate complaints.
  • Coding time improved by 60% and lead time by 70%.

The same report comes with caveats. The article gives no total hardware or operating cost, so the 90% rests on a per-token comparison. It doesn't explain how the 60% and 70% were measured, and the numbers come from a conference talk without independent verification. Claude and GPT were also not fully replaced. GLM is text-only, so vision and UI work goes through a model router to other models.

Abitbol also said coding speed was not the main bottleneck. The largest gains came from using AI for debugging and for Jira and Confluence tickets, once token rationing went away. Revolut's story is partly about cheap inference and partly about what people do when they stop watching a meter.

The prices you can check today

Three options sit on the table for most teams: a frontier API, a hosted open-weight API, and your own GPUs. Here are the published rates per million tokens as of November 5, 2026.

ModelInputCache readCache writeOutput
Claude Opus 5.5$4.00$0.20$5.00 (5 min)$20.00
Claude Sonnet 5.5$2.00$0.10$2.50 (5 min)$10.00
GLM-5.3 on Z.ai$1.40$0.26Not listed$4.40
GLM-5.3-FlashX on Z.ai$0.37$0.075Not listed$1.25

Read the input and output columns and GLM-5.3 looks about 65% to 78% cheaper than Opus 5.5. Now read the cache column. Hosted GLM-5.3 charges more for a cache read than Opus does, and more than twice what Sonnet charges. Coding agents resend a long conversation on every turn, so cache reads are often the largest token category they produce. A comparison that skips this column can overstate the saving by a wide margin.

Z.ai's page also shows cached input storage as free for a limited time, so check that line again before you budget on it.

Pricing a realistic token mix

To compare fairly you need a token mix, and yours will differ from anyone else's. As a worked example, take 100 million tokens of agent traffic split like this: 88 million cache reads, 6 million cache writes, 3 million fresh input and 3 million output. That split is my assumption, chosen to resemble a cache-heavy agent session. Replace it with your own logs.

Z.ai doesn't list a cache write price, so the example bills those tokens at its normal input rate.

OptionCost for the example mixCompared with Opus 5.5
Claude Opus 5.5$119.60Baseline
Claude Sonnet 5.5$59.8050% lower
GLM-5.3 on Z.ai$48.6859% lower
GLM-5.3-FlashX on Z.ai$13.6889% lower
$0.30 flat, Revolut's reported rate, all 100M tokens$30.0075% lower

Moving from Opus to Sonnet saves half on this mix with no infrastructure at all. Moving from Sonnet to hosted GLM-5.3 saves only 19%, because the cache rate eats most of the gap. A team that wants a 90% saving from a rate card alone has to drop to a much smaller model such as FlashX, and then the real question becomes how many tasks that model finishes without a human redoing them.

The $0.30 row is the weakest number in the table. The Register doesn't say how Revolut counts cached tokens, so a flat rate applied to all 100 million tokens may be too high or too low for them. I included it to show the scale, and you shouldn't budget on it.

What the GPUs cost a smaller team

Lambda lists HGX B200 at $6.69 per GPU per hour on demand, with 180 GB of memory per GPU. That is one public price and reserved deals are lower, so treat it as a starting point. An 8-GPU node running all month, at 730 hours, comes to about $39,070 before tax, storage, networking or anyone's salary.

Here is the same arithmetic for Revolut's scale: 56 GPUs at that list price would be about $273,487 a month, or roughly $137 per engineer across 2,000 people. Revolut hasn't said what it pays or whether it owns the hardware, so this is an outside estimate at one provider's on-demand rate. It still gives a useful comparison. Anthropic's Claude Code docs say enterprise deployments average about $150 to $250 per developer per month. At list rental prices, then, the cluster alone lands near the average spend it would replace.

That points to a likely explanation for the 90%. Either Revolut's heaviest users were far above the average, its real hardware cost is well below on-demand rental, or the figure is the per-token comparison rather than a total bill. All three could be true. None of them transfers automatically to your company.

Now the break-even for one 8-GPU node at $39,070 a month:

  • At $200 per developer per month, the midpoint of Anthropic's range, you need about 195 developers just to cover the rent.
  • Against the example mix on Opus 5.5, you need about 32.7 billion tokens a month.
  • Against the same mix on Sonnet 5.5, about 65.3 billion tokens.
  • Against hosted GLM-5.3, about 80.3 billion tokens.

Those figures ignore the person who gets paged when vLLM falls over at 2 a.m. They also ignore redundancy. One node is one failure away from a team with no coding agent, so a serious deployment needs a fallback route to a hosted API anyway.

Where the capacity limit really sits

Token prices tell you nothing about how many engineers a node can serve at once. Memory decides that first. The vLLM recipe for GLM-5.3 says the FP8 checkpoint fits on 8 H200 GPUs, and that 8 B200 GPUs can reach the full 1M-token context with an FP8 KV cache. It suggests starting with --max-num-seqs 32 and tuning from there: up when you have headroom, down when you run out of memory.

The KV cache is where context length gets expensive. The recipe gives one validated example on 8 MI325X GPUs: a 1,477,168-token KV cache at a maximum context of 524,288 tokens, which it reports as 2.82x maximum concurrency. Cut the maximum context to 262,144 and the same cache holds about 5.6 sessions at full length, by simple division.

This is why Abitbol's comment about context matters more than it first sounds. He said 256K is what's practically needed and called long context "a scam" in terms of usefulness. Capping context is a capacity decision. His view isn't universal, and a team working in a very large repository may disagree, but the trade is real and you can measure it.

Here's a rough ceiling for a B200 node, using numbers from two sources. Eight B200 GPUs give 1,440 GB. The NVFP4 checkpoint in the recipe is about 465 GB, which leaves about 975 GB. The Register cites 6 to 26 GB per user for GLM 5.1, depending on precision, without stating a context length. That suggests something like 37 to 162 live contexts. It's a memory-only estimate from a different model version, and throughput will likely limit you sooner. Use it to judge whether the idea is sane, then measure.

Revolut said its biggest gains came from tuning hyperparameters, NVFP4 quantization, disaggregated prefill and decode, and context-length tuning, rather than adding GPUs. Each of those takes engineering time. The recipe marks prefill/decode disaggregation as a separate deployment strategy, and it notes that pure throughput benchmarks tend to under-report real speed because speculative decoding accepts fewer tokens in synthetic runs. If nobody on your team wants to own that work, self-hosting is the wrong project.

A cheaper experiment than buying GPUs

You can test the model before you touch hardware, and this is the step I'd push almost every team under 200 engineers to do first. A hosted API tells you whether GLM-5.3 can finish your work. If it can't, you've saved yourself the cluster.

Step 1: measure a baseline for one week

Anthropic's costs page recommends starting with a small pilot group and tracking usage to set a baseline. Record the token categories, the cost per developer, and how many tasks were merged. Tokens per merged task is a better number than tokens per day, because a cheap model that needs three attempts is not cheap.

Step 2: run your own numbers

Paste your token counts into this script. It needs only Python 3 and has no dependencies.

# agent_cost.py: compare a month of agent tokens across price lists.
# Tokens are in millions. Prices are USD per million, checked 2026-11-05.
PRICES = {
    #                  input  write  read   output
    "Opus 5.5":       (4.00,  5.00,  0.20,  20.00),
    "Sonnet 5.5":     (2.00,  2.50,  0.10,  10.00),
    "GLM-5.3 hosted": (1.40,  1.40,  0.26,   4.40),  # write billed as input
    "GLM-5.3-FlashX": (0.37,  0.37,  0.075,  1.25),  # write billed as input
}

# Replace with one month of your own usage.
FRESH, WRITE, READ, OUTPUT = 3, 6, 88, 3
NODE_MONTH = 6.69 * 8 * 730  # 8 GPUs, on-demand list price, full month

total = FRESH + WRITE + READ + OUTPUT
for name, (i, w, r, o) in PRICES.items():
    cost = FRESH * i + WRITE * w + READ * r + OUTPUT * o
    breakeven_b = NODE_MONTH / (cost / total) / 1000
    print(f"{name:16} ${cost:10,.2f}   node breaks even at {breakeven_b:6.1f}B tokens/month")

With the example mix it prints $119.60, $59.80, $48.68 and $13.68, and the break-even figures for each. Add a salary line for the person running the cluster before you show this to anyone.

Step 3: point an agent at the hosted model

Claude Code reads ANTHROPIC_BASE_URL, and Z.ai publishes an Anthropic-compatible endpoint for this purpose. Its setup guide uses a config along these lines in ~/.claude/settings.json. Its example names GLM-4.7, so check the guide for the current model mapping.

{
  "env": {
    "ANTHROPIC_BASE_URL": "https://api.z.ai/api/anthropic",
    "ANTHROPIC_AUTH_TOKEN": "your-zai-api-key",
    "API_TIMEOUT_MS": "3000000"
  }
}

Later, a self-hosted server can use the same switch. The vLLM docs for Claude Code explain that vLLM implements the Anthropic Messages API, so setting the base URL to your server sends requests there. They also warn that the model needs strong tool calling support. Before you send any company code to a hosted endpoint, get a decision on the data terms, because this config sends your source to whoever runs that URL.

Step 4: replay real tasks for one week

Take 20 closed tickets from your own repository, a mix of bug fixes, small features and tests. Run each one on the model you use now and on the model you're testing, starting from the same commit. Score these things:

  • Did the tests pass without a human edit?
  • How many review comments would a senior engineer leave?
  • How many turns and tokens did it take?
  • How much human time went into rescuing it?

Vendor benchmarks won't answer this for you. Z.ai's model card claims a 50% improvement over GLM-5.2 on its own in-house Z.ai Code Bench, and that may well be true, but your codebase is what you are paying to change.

Watch reasoning effort while you test. The vLLM recipe says GLM-5.3 thinking is always on, the default level is max, and that level has the highest token cost. Lower levels are available through reasoning_effort. Compare like with like, and don't judge the price of a model that is running at its most expensive setting by accident.

What to do at each team size

These are my judgment calls from the numbers above, using Anthropic's average spend figures. Your own usage can move every line.

TeamSensible next move
1 to 20 engineersStay on hosted APIs. Default routine work to a cheaper model such as Sonnet 5.5 and keep Opus for hard problems.
20 to 200 engineersAdd routing and test a hosted open-weight model on low-risk work. A GPU node rarely covers its rent at average usage.
Around 200 or more, or heavy agent automationRun the break-even with real logs. Rent one node for a month before you commit to buying anything.
Strict data rules at any sizeSelf-hosting or a regional deployment may be justified by compliance alone, so judge it on that basis instead of on savings.

The parts that aren't about price

The GLM-5.3 license grants broad rights to use, modify and sell, with one notable condition: a company operating a Model as a Service business with aggregate revenue over $10 billion in 12 months must pass Z.AI's security review before commercial use. That is unlikely to touch a normal product team, but have your own lawyer read it. This isn't legal advice.

Privacy is a split decision. The Register reports that Abitbol acknowledged privacy and security concerns about Chinese open-weight models, and said there is little to worry about when they run on-prem or on regional cloud resources. That's one company's reasoning, and your security team may reach a different conclusion. Open weights do let you keep prompts on hardware you control. They don't answer every question about a model's training or behaviour, so keep the normal review steps for generated code.

iOS teams should note the text-only limit. Revolut routes vision and UI work elsewhere, and the vLLM recipe also tags GLM-5.3 as a text model. If your workflow sends simulator screenshots to the agent to check a SwiftUI layout, a GLM-only setup won't cover that step. You would keep a vision-capable model in the route, which is what Revolut does.

Flat billing also changes behaviour. Abitbol said a flat cost removes end-of-month bill shock. It removes a brake as well, and engineers who spent heavily on a meter will likely run more parallel tasks when the meter disappears. Revolut treats that as a benefit, because the debugging and ticket work paid off. Your cluster fills up the same way, so plan for demand to rise after launch and track queue time from day one.

Three numbers to bring to the meeting

If someone forwards you the Revolut headline and asks why your team isn't doing this, you can answer with evidence by the end of the two weeks. Bring your cost per merged task on the current model, the same figure on GLM-5.3 from the replay, and the monthly token count at which an 8-GPU node would pay for itself once you add the salary line. If the first two are close, routing work to cheaper models is the win you can have this month. If the token count is near your real usage and you have someone who wants to run inference, rent a node for a month and find out.

If you're tracking this on Claude's API, the Opus 5.5 Coding Workflow & Cost Kit is a product of mine that includes an editable .xlsx calculator with five token categories and manual rate inputs, along with planning, handoff and code review templates. It estimates first-party Claude API token charges only, so it won't cover GPU costs or predict subscription limits, and you can edit the rates when they change.

Sources