The 5 PM Speedup

TL;DR.

Revolut says it cut its AI coding inference bill by about 90% in under a year by self-hosting GLM for roughly 2,000 engineers on 56 Nvidia B200 GPUs. The story went around fast, and the headline number is real for Revolut. The most useful detail in the talk, though, is a throwaway line: the model serves about 200 tokens per second during the day and close to 800 tokens per second for engineers who sign in after 5 PM.

That speedup is what idle capacity looks like from the user's side. A self-hosted fleet is sized for the busiest hour and billed for every hour. Here is what that means for anyone trying to copy the move.

• Self-hosting turns tokens from a variable cost into a fixed one. In our model, 56 B200s at $5.50 an hour cost $224,840 a month, about $112 per engineer, whether engineers use them or not. Revolut said some engineers had been spending "$1,000 a month, $10,000 a month" before. That gap explains most of the 90%.
• "A tenth of the price" depends on what you compare it to. Revolut's $0.30 per million tokens is 15% of Sonnet 5.5's list input rate. A coding agent's traffic is mostly cache reads, though, and at a 95% cache-read mix Sonnet 5.5 averages $0.355 per million. Against that, $0.30 is a 15% saving, not 90%.
• Utilization sets your real price. A peak-sized fleet serving one time zone runs at about 31% over a week in our model, for $0.345 per million. Fill the nights with batch work and the same fleet drops to $0.160.
• The cheapest setup is hybrid. Own about a third of the peak and send the overflow to an API. In our model, 17 GPUs plus Sonnet 5.5 overflow costs $188,499 a month, 18% below all-API and 16% below the peak-sized fleet.
• Revolut still routes. GLM is text-only, so vision requests go to Gemini or GPT Luna. Self-hosting is one more route, not the end of routing.

Below: the numbers from the talk, three charts, and fleetmath.py, 66 lines of Python that price your own fleet against API tiers and find the cheapest GPU count.

Revolut figures are as reported by The Register on November 3, 2026, from David Abitbol's talk at AI Engineer in New York in October. They are the company's own numbers, not audited results, and total cost of ownership was not disclosed. Everything labeled "our model" uses stated assumptions: $5.50 per B200-hour, 15 million tokens per engineer per workday, and a synthetic weekday load curve. No figure here comes from Nadir customer data.

What Revolut actually said.

Two lines in that table are worth more than the headline. The speedup after 5 PM tells you how busy the fleet is. And the list of what moved cost most is mostly serving work, not buying more GPUs.

The 5 PM speedup is idle capacity.

Decode speed on a shared GPU rises as load falls, because each user gets a bigger share of the batch. Going from about 200 to near 800 tokens per second after hours says the fleet is much less busy at 6 PM than at 11 AM. That is normal. Engineers in one region work roughly the same hours, so a fleet that keeps up at 11 AM is mostly idle at 3 AM and on Sunday.

The GPUs cost the same at 3 AM. In our synthetic week, a fleet sized for the weekday peak averages 42% of capacity on weekdays and 31% over the full week. Whatever a GPU-hour costs you, rented or amortized, a token from that fleet costs about 3.2x what it would at full load.

We covered how hard load moves self-hosted cost in The Utilization Tax: on identical H100s, one paper measured up to 36x between saturated and lightly loaded. The 5 PM speedup is the same effect, seen from the user's chair.

A tenth of what?

"$0.30 per million tokens, a tenth of the commercial price" is true against a list rate for fresh input. Coding agents don't pay that rate for most of their tokens. A typical agent session is about 95% cache reads, and providers bill cache reads at a small fraction of fresh input. At that mix, at Anthropic's November 2026 list prices:

None of this means the 90% is wrong. It means the 90% comes from two things at once: a cheaper rate, and a switch from uncapped spending to a fixed fleet. Revolut's own description of the before state, engineers spending $1,000 to $10,000 a month, points at the second. If your engineers already run cached sessions on a mid-tier model, your saving from the same move would be much smaller than Revolut's.

Fixed cost changes how people behave.

Once the fleet is paid for, the next token is close to free until you run out of capacity. Revolut said lower costs let it relax token budgets and spread usage into debugging and Jira and Confluence work, which is where it saw the biggest gains.

That's the right response to a fixed cost, and it's the opposite of what an API bill pushes you toward. On an API, every extra token is extra money, so finance asks for caps, the pattern we saw in Uber's four-month budget and in the token caps spreading this fall. On a fleet, the waste is the hours nobody uses. The question changes from "how do we use fewer tokens" to "how do we fill the GPUs we already pay for."

There's a risk on the other side, too. Usage on a free-at-the-margin fleet grows until it hits the peak, and then the only fix is more GPUs, a large step cost. The Jevons effect is real, and on a fleet it shows up as a hardware request instead of a bigger invoice.

Three ways to lower the real price.

1. Fill the nights. Some agent work doesn't need a person waiting: test generation, nightly code review of open PRs, eval runs, documentation, dependency upgrades, ticket triage. Queue it for off-peak hours. In our model, filling every off-peak hour to 60% of peak adds 115% more tokens to the same fleet, lifts utilization to 68%, and drops the price from $0.345 to $0.160 per million. If you don't own GPUs, the API version of this is the batch tier at about half price.

2. Cap context where you can. Revolut's "long context is a scam" line has a cost reason behind it. Each user holds 6 to 26 GB of KV cache, so context length decides how many users fit on a GPU. Limiting context to what the work actually needs fits more concurrent sessions on the same hardware. It also matches what benchmarks keep finding: models degrade well before their advertised window, as we covered in The Ruler Gap.

3. Own the base, rent the peak. Don't size the fleet for 11 AM. Size it for the load you have most of the day, and send the excess to an API.

In our model the cheapest point is 17 GPUs, $188,499 a month, with about half the tokens on the API. That's 18% below all-API ($231,384) and 16% below the 56-GPU fleet ($224,840). The bottom of the curve is flat: anything from 12 to 32 GPUs is within 2% of the minimum, so you don't need a precise forecast to land in the right range. The ends are steep, and a peak-sized fleet sits near the expensive end. We worked through the same shape with smaller models in Own the Base, Rent the Peak.

The hybrid number assumes the self-hosted model and the API model are interchangeable for these tasks. That's a quality assumption, not a cost one, and you should test it on your own work before you rely on it. Running the same open weights on different stacks can also change results.

Tutorial: fleetmath.py.

fleetmath.py prices a self-hosted fleet against API tiers at an agent token mix, shows what utilization does to the real price, and sweeps GPU counts with API overflow to find the cheapest mix. Edit the constants at the top: GPU count and hourly cost, engineers, tokens per engineer per workday, your hourly load curve, and your rate card.

"""fleetmath.py: what a self-hosted coding-model fleet really costs per token.

A fleet is sized for the weekday peak and billed every hour of the week. This
prices one against API tiers at an agent token mix, shows how utilization moves
the real $/M, and finds the GPU count that is cheapest once overflow goes to an
API. All inputs are assumptions: replace them with your own quote and traffic.
"""
GPUS, GPU_HR = 56, 5.50            # fleet size, $ per GPU-hour (rented or amortized)
ENGINEERS, TOK_PER_DAY = 2000, 15e6  # active engineers, tokens per engineer per workday
HOURS_PER_MONTH, WEEKS_PER_MONTH = 730, 730 / 168

# Weekday demand by local hour, as a share of the peak hour. Weekends run at 12%.
WEEKDAY = [.04, .03, .03, .03, .04, .06, .12, .30, .62, .88, 1.0, .97,
           .80, .92, .98, .95, .85, .55, .30, .20, .15, .12, .08, .05]
WEEK = WEEKDAY * 5 + [h * 0.12 for h in WEEKDAY] * 2      # 168 hourly shares

# $ per million tokens at an agent mix: 95% cache read, 3% fresh input, 2% output.
MIX = (0.95, 0.03, 0.02)
RATES = {  # cache read, fresh input, output ($/M, list price)
    "Opus 5.5": (0.20, 4.00, 20.00),
    "Sonnet 5.5": (0.10, 2.00, 10.00),
    "Haiku 5.5": (0.01, 0.10, 0.50),
}
API = {name: sum(m * r for m, r in zip(MIX, rate)) for name, rate in RATES.items()}


def monthly_tokens():
    return ENGINEERS * TOK_PER_DAY * 5 * WEEKS_PER_MONTH


def fleet(gpus, api_price, week=WEEK):
    """Monthly $ for `gpus` GPUs sized against the 56-GPU peak, overflow to API."""
    per_share = monthly_tokens() / (sum(WEEK) * WEEKS_PER_MONTH)  # tokens per 1.0 share-hour
    cap = gpus / GPUS                                             # share of peak covered
    served = sum(min(h, cap) for h in week) * per_share * WEEKS_PER_MONTH
    overflow = sum(max(h - cap, 0) for h in week) * per_share * WEEKS_PER_MONTH
    gpu_cost = gpus * GPU_HR * HOURS_PER_MONTH
    return gpu_cost + overflow * api_price / 1e6, served, overflow


def report():
    toks = monthly_tokens()
    cost = GPUS * GPU_HR * HOURS_PER_MONTH
    util = sum(WEEK) / len(WEEK)
    print(f"fleet: {GPUS} GPUs  ${cost:,.0f}/mo  ${cost / ENGINEERS:,.2f} per engineer")
    print(f"tokens: {toks / 1e9:,.1f}B/mo  utilization {util:.0%}  "
          f"effective ${cost / toks * 1e6:.3f}/M  (at 100% busy: ${cost / toks * 1e6 * util:.3f}/M)")
    for name, p in API.items():
        api = toks * p / 1e6
        even = cost / (p / 1e6) / (ENGINEERS * 5 * WEEKS_PER_MONTH)
        print(f"  vs {name:<10} ${p:.3f}/M  API ${api:>9,.0f}/mo  "
              f"break-even {even / 1e6:5.1f}M tokens/engineer/day")
    filled = [max(h, 0.6) for h in WEEK]          # night and weekend filled to 60% with batch
    extra = (sum(filled) - sum(WEEK)) / sum(WEEK)
    print(f"fill nights to 60%: +{extra:.0%} tokens on the same fleet, "
          f"utilization {sum(filled) / 168:.0%}, ${cost / (toks * (1 + extra)) * 1e6:.3f}/M")
    p = API["Sonnet 5.5"]
    best = min(range(0, GPUS + 1, 2), key=lambda g: fleet(g, p)[0])
    for g in (0, best, GPUS):
        total, served, over = fleet(g, p)
        print(f"  {g:>2} GPUs + Sonnet overflow: ${total:>9,.0f}/mo  "
              f"{over / (served + over):.0%} of tokens on API")


if __name__ == "__main__":
    report()

With the defaults it prints:

$ python fleetmath.py
fleet: 56 GPUs  $224,840/mo  $112.42 per engineer
tokens: 651.8B/mo  utilization 31%  effective $0.345/M  (at 100% busy: $0.108/M)
  vs Opus 5.5   $0.710/M  API $  462,768/mo  break-even   7.3M tokens/engineer/day
  vs Sonnet 5.5 $0.355/M  API $  231,384/mo  break-even  14.6M tokens/engineer/day
  vs Haiku 5.5  $0.022/M  API $   14,665/mo  break-even 230.0M tokens/engineer/day
fill nights to 60%: +115% tokens on the same fleet, utilization 68%, $0.160/M
   0 GPUs + Sonnet overflow: $  231,384/mo  100% of tokens on API
  18 GPUs + Sonnet overflow: $  188,599/mo  50% of tokens on API
  56 GPUs + Sonnet overflow: $  224,840/mo  0% of tokens on API

The sweep steps by two GPUs, so it lands on 18; a one-GPU sweep finds 17 at $188,499. Read the break-even lines first. Against Opus-class pricing, the fleet pays off once the average engineer uses more than 7.3 million tokens a workday. Against Sonnet-class pricing, it takes 14.6 million. Against Haiku-class pricing, it never pays off at any realistic volume. Heavy agent users can pass 15 million tokens a day, light ones use far less, so put your own average in, not your power users'.

What the model leaves out, on purpose:

• People and operations. On-call, upgrades, quantization work, evals for each new open model. Revolut's cost figure excludes this, and so does ours.
• Throughput. It assumes 56 GPUs exactly cover your peak. Measure tokens per second per GPU on your own model, quantization and context length, and set the fleet size from that.
• Quality. It assumes the open model can do the work you move to it. That's the assumption to test first.

When self-hosting is the wrong move.

• Your engineers already run cached sessions on a mid-tier model. At 95% cache reads, Sonnet-class pricing is about $0.36 per million. A fleet at 31% busy barely beats it, before staff.
• Your usage is small or spiky. Below the break-even line, every idle GPU-hour is pure loss. A fleet needs steady volume to pay for itself.
• You can't keep up with model releases. GLM-5.1 to GLM-5.3 happened in months. Each swap needs new evals, new quantization, and new serving tuning.
• Your workloads need multimodal or the frontier. Revolut routes vision elsewhere. If most of your hard work needs the top model, self-hosting covers the cheap part of the bill and leaves the expensive part where it is.

Where Nadir fits.

Revolut's setup has a router in it because no single model covers every request. That's the part Nadir does.

Know your traffic before you buy GPUs. fleetmath.py needs two inputs most teams don't have: tokens per engineer per day, and how much of that traffic a smaller model can handle. Nadir's Observe mode serves exactly the model you asked for and records what routing would have picked, so you get both from a week of your own traffic before you change anything. Every response reports which model served it and what it cost.

Treat the fleet as one more tier. In an on-prem deployment, a self-hosted model behind an OpenAI-compatible endpoint (vLLM, SGLang) is configured next to your hosted providers, and Nadir recommends the lowest-cost model it expects to handle each request. Text coding work can go to your GLM fleet, vision and frontier-only work to an API, and overflow past your fleet's capacity to a hosted fallback. The routing decision runs inside your network.

A free 30-day audit in your VPC. For teams weighing a move like Revolut's, the on-prem audit runs Nadir in shadow mode, then re-runs an agreed sample of up to 500 real requests with your provider keys and grades them with your tests or CI. It compares your current policy, a simple rule and Nadir, including retries and lost prompt-cache hits. Nadir charges no audit fee. Your inference, infrastructure and engineering time are separate, and recommendations stay projections until they're executed and graded.

On the hosted gateway with your own provider keys, the provider bills you directly and Nadir charges a flat $0.002 per request, with the first 50 requests a month free. Savings depend on your workload, and nothing in this post forecasts yours.

Start with a free key, see the on-prem audit, or estimate your savings from your current model spend.

Conclusion.

Revolut's 90% is a real result for Revolut, and it came from more than a cheaper rate. It moved from uncapped per-token spending to a fixed fleet, tuned the serving stack hard, capped context, and kept a router for the work its model can't do. The 5 PM speedup is the cost of that choice: GPUs paid for around the clock and busy for about ten hours a day. If you're thinking about the same move, start with your own traffic. Compare against cached prices, not list input rates. Fill the nights or own only the base. And keep routing, because no single model, hosted or yours, covers everything.

Sources: [The Register, report on Revolut's self-hosted GLM deployment, November 3, 2026](https://www.theregister.com/a/5307345), reporting David Abitbol's talk at AI Engineer, New York, October 2026. [Anthropic, Pricing](https://platform.claude.com/docs/en/about-claude/pricing), retrieved November 8, 2026: Opus 5.5 $4 input, $0.20 cache read, $20 output. Sonnet 5.5 $2, $0.10, $10. Haiku 5.5 $0.10, $0.01, $0.50, per million tokens. B200 rental prices vary widely by provider and term. Mainstream on-demand listings ran roughly $4 to $8 per GPU-hour in late 2026, and $5.50 is our assumption, not a quote. The load curve, token volume and hybrid sweep are our illustrative model, not Revolut's data.