---
title: "How Revolut Cut AI Coding Costs 90%: 56 B200 GPUs, Buy vs Rent"
description: "Revolut reports 2,000 engineers using 56 B200 GPUs at $0.30 per million tokens. Our original analysis tests GPU buy vs rent, 36-month resale, throughput limits, 90% caching, and Cursor, Claude and ChatGPT alternatives."
date: 2026-11-05T00:42:39.560Z
source: https://venturecapitaltracker.com/revolut-ai-coding-costs-gpu-buy-vs-rent-2026
---

# How Revolut Cut AI Coding Costs 90%: 56 B200 GPUs, Buy vs Rent

> Revolut reports 2,000 engineers using 56 B200 GPUs at $0.30 per million tokens. Our original analysis tests GPU buy vs rent, 36-month resale, throughput limits, 90% caching, and Cursor, Claude and ChatGPT alternatives.

**Updated November 4, 2026 · VCT original financial model.** Revolut says its self-hosted **GLM-5.3** coding infrastructure serves roughly **2,000 engineers on 56 NVIDIA B200 GPUs** at a reported blended price of **$0.30 per million tokens with cache reads free**, and cut its coding-model invoice to about **one tenth** of what it paid for Anthropic and OpenAI. Those are **company-reported** results, presented by AI operations leader David Abitbol at [AI Engineer NYC on October 13, 2026](https://ai.engineer/nyc/2026/talks/revolut)—not an independent audit of Revolut's costs or engineering productivity.

**The question the headlines miss: when would it make sense to buy the GPUs, rent them, or use cheaper APIs and coding subscriptions?** It depends on the cache-read share, output tokens, tasks completed, serving hours, model quality and the cost of idle capacity. This original calculation covers all four choices, including GPUs' potential—but highly uncertain—future resale value.

**Quick answer:**

| Investment decision | VCT result, using transparent assumptions |
| --- | --- |
| Purchase one eight-B200 server | **$450K hardware plus $20K installation** (illustrative), 36-month economic holding period |
| Own it for three years | **$17,935/month economic TCO**, including 30% projected resale, 10% cost of capital and $6K/month facilities/support |
| Rent the same eight B200s at Together's $8.19/GPU-hour | **$11,532 for 176 billable hours** or **$47,830 for 730 hours** |
| When ownership beats the same on-demand rental | Around **274 billed hours/month** before incremental platform staffing; around **335 hours** using Lambda's $6.69 rate |
| When ownership beats the same-model GLM-5.3 API | About **41.3B counted tokens/month** at a 90% cached/8% fresh/2% output split; the node must have sufficient throughput *and* be used long enough |
| What 56 GPUs can handle | **35.7 engineers with access per GPU** in Revolut's example, but *not* 35.7 simultaneous full-speed users per GPU |

**Don't confuse three different denominators:** billed API tokens, total model-server processed tokens and successful coding tasks. An agentic task can cache gigabytes of context, make dozens of requests and still produce a small accepted patch. The economic objective is **fully loaded dollars per accepted, verified task at the required latency**, not the lowest promotional cents per million.

## What Revolut actually disclosed—and what remains unknown

The [original talk, transcript and operating slides](https://ai.engineer/talks/Ok6QdZHCcI8-revolut-cut-ai-coding-costs-90-self) support the following fact check.

| Revolut claim | What can be concluded |
| --- | --- |
| 2,000 engineers; 56 B200s; GLM-5.3 serving with Together | Engineers with access to the model; actual peak concurrency and fleet traffic not published |
| $0.30 per million input/output tokens, cache free | Company-reported blended cost; detailed calculation, accounting basis, utilization and paid vs cached-token denominator not provided |
| 90% cheaper invoices than its previous Anthropic/OpenAI setup | Company comparison, **not** an apples-to-apples current-market API benchmark |
| Under 3 seconds to first token; >200 tokens/sec interaction target | Operational goals; not published p95/p99 SLO across all engineering teams |
| 14.26 to 1.68 seconds TTFT, +76% requests/sec on the same 56 GPUs | Reported inference-tuning improvement without increasing the GPU fleet; workloads and distributions not available for reproduction |
| Faster coding and lead times across the engineering organization | Historical observational associations; model changes were not isolated in a controlled causal experiment |
| GPUs purchased, leased, or contracted with Together | **Not disclosed**—it would be incorrect to say Revolut bought 56 B200s |
| Security and compliance | Revolut reports sandboxes, operation rules, logging and image requests routed separately; local serving does not automatically satisfy every applicable compliance requirement |

Revolut's technical experience is that **FP4 quantization, efficient tensor parallelism, smaller actively served contexts, KV-cache engineering and routing** can deliver greater throughput on the **same GPUs**. Its operations team reported that employees could use models beyond coding—documentation, Jira, coordination and inbox tasks—once budgets stopped making people ration tokens. The causality and the size of productivity uplift remain unverified outside the organization.

GLM-5.3 is an **open-weight** model from Z.ai, not a proprietary foundation model created by Revolut. Open weights permit local deployment subject to license and security review; they do not imply that model development was free.

## A real 2.4-billion-token coding example: caching dominates the bill

One developer supplied the following **self-reported** usage: **two legacy Cursor Pro+ subscriptions at $60 each, $120 total each month**, and **2.4 billion counted tokens/month, of which 90% are cache reads**. This is an *individual case study*, not a randomly sampled average from Cursor, Anthropic or OpenAI.

| Measured or reported | Monthly figure |
| --- | ---: |
| Total counted tokens | **2.4B** |
| Cache reads (90%) | **2.16B** |
| Remaining fresh-input plus output tokens (10%) | **240M** |
| Paid for two Cursor Pro+ subscriptions | **$120** |
| Effective rate across all counted tokens | **$0.05/1M tokens** |

At $0.30/M applied to *all* 2.4B counted tokens, the hypothetical cost would be **$720**. At $0.30/M applied only to the 240M **non-cached** tokens, the hypothetical charge would be **$72**. Revolut says "cache is free," but its billing reconciliation is undisclosed; do **not** claim one of those figures is its actual tariff or that the $120 plan entitles every developer to 2.4B tokens. Cached prefixes are cheaper to *serve* but still occupy memory and infrastructure.

To calculate provider API charges, we need the **remaining split**. For the article's reproducible example, assume **90% cache reads, 8% uncached input and 2% generated output**—2.16B, 192M and 48M tokens respectively. Only the 90% cache share was reported; the additional 8%/2% assumption is a VCT sensitivity scenario.

## Current alternatives: GLM, DeepSeek, OpenAI, Claude and Cursor

These are **list-price API-equivalent calculations**, not actual subscription bills. All prices are **US dollars per million tokens** from the provider sources linked in the table, and all use the same 90%/8%/2% workload. Vendor models and agent harnesses are not interchangeable in quality or token usage.

| Model / provider price source | Cached read | Fresh input | Output | 2.4B-token hypothetical |
| --- | ---: | ---: | ---: | ---: |
| [DeepSeek V4.1 Flash, off-peak](https://api-docs.deepseek.com/quick_start/pricing/) | $0.003 | $0.15 | $0.60 | **$64** |
| [OpenAI GPT-6 Luna, standard API](https://developers.openai.com/api/docs/pricing) | $0.01 | $0.10 | $0.50 | **$65** |
| [Z.ai GLM-5.3 Flash via Cursor](https://cursor.com/docs/models/glm-5-3-flash) | $0.029 | $0.15 | $0.50 | **$115** |
| DeepSeek V4.1 Flash, peak | $0.006 | $0.30 | $1.20 | **$128** |
| [OpenAI GPT-6.1 Terra, standard API](https://developers.openai.com/api/docs/pricing) | $0.05 | $1.00 | $5.00 | **$540** |
| [Cursor Composer 2.5](https://cursor.com/docs/models-and-pricing) | $0.20 | $0.50 | $2.50 | **$648** |
| [GLM-5.3 via Cursor](https://cursor.com/docs/models/glm-5-3) | $0.26 | $1.40 | $4.40 | **$1,042** |
| [Claude Sonnet 5.5 API](https://www.anthropic.com/claude-sonnet-5-5) | $0.10 | $2.00 | $10.00 | **$1,080** |
| [GPT-6.1 Sol API](https://developers.openai.com/api/docs/pricing) | $0.10 | $2.00 | $10.00 | **$1,080** |
| [Claude Opus 5.5 API](https://cursor.com/docs/models-and-pricing) | $0.20 | $4.00 | $20.00 | **$2,160** |

DeepSeek's off-peak and peak rates apply at **different hours**, so they are a range, not a fixed blended month. Its official pricing page lists UTC scheduling and separately billable search/fetch APIs. OpenAI's standard rate differs from Flex, Fast and regional processing. Enterprise contracted rates, cache writes, context premiums, app tooling and tax can change the outcome. **Do not interpret cheaper tokens as equivalent coding quality.** For this workload, a managed API may be cheaper than the $120 subscription, *if the plan allows the required work*—and much cheaper than running a rarely used 8×B200 server.

**Exact formula, all volumes in millions:** *API charge = cached-read count × cached price + fresh-input count × input price + output count × output price + tool/cache-write fees.* The real comparison should multiply by **attempts per accepted task** and include engineer review and failure costs.

### ChatGPT, Claude Code and Cursor are subscriptions—not raw-token guarantees

| Product, individual plan | Public U.S. web price per month | Practical constraint |
| --- | ---: | --- |
| [Legacy Cursor Pro+](https://cursor.com/docs/models-and-pricing) | $60 | Legacy monthly usage pools and optional paid overflow; user example subscribes twice |
| [Cursor Premium / Super / Ultra](https://cursor.com/pricing) | $30 / $100 / $200 | New X Subscription model-pool economics and pay-as-you-go third-party models differ materially from legacy plans |
| [Claude Pro / Max / Ultra](https://support.claude.com/en/articles/11049741-what-is-the-max-plan) | $20 / $100 / $200 | Shared Claude and Claude Code usage allowances, time/weekly windows and model eligibility |
| [ChatGPT Plus](https://help.openai.com/en/articles/6950777-what-is-chatgpt-plus) | $20 | ChatGPT and eligible coding workflows, **not** unrestricted API usage |
| [ChatGPT Pro 100 / 200 / 500](https://help.openai.com/en/articles/9793128-about-chatgpt-pro-tiers) | $100 / $200 / $500 | Higher allowances and capabilities, still subject to product-specific fair-use and rate limits |

Individual developer plan comparisons **do not automatically transfer to an enterprise's per-seat procurement contract or pooling rights**. Before pricing Claude or ChatGPT from a token count, obtain actual usage telemetry including cache hits and writes, model mix, counted reasoning/output, tool calls and subscription-limit events.

### Three usage patterns—not measured platform averages

| Illustrative workload | Total/month | Cached / fresh / output | Sonnet 5.5 API equivalent |
| --- | ---: | --- | ---: |
| Lightweight Claude/ChatGPT research user | 20M | 30% / 50% / 20% | **$61** |
| Regular Cursor/Claude Code agentic developer | 200M | 70% / 20% / 10% | **$294** |
| Extreme parallel-coding example above | 2.4B | 90% / 8% / 2% | **$1,080** |

Those are **hypothetical workloads run through API pricing**, not a promise that a $20 or $100 plan will serve that volume. The user's $120 realized price is especially informative because it challenges the assumption that self-hosting must be cheaper than a developer's actual subscription.

## What can 56 B200s actually serve at a useful speed?

**"2,000 engineers / 56 GPUs = 35.7 engineers per GPU" describes access, not full-speed concurrency.** Agents spend time calling tools, executing builds, waiting for approvals or running tests; requests arrive in bursts. Separate (a) total processed+cached tokens, (b) fresh prefill throughput, (c) generated tokens per second, (d) simultaneous in-flight requests and (e) latency percentiles.

An independent [SemiAnalysis InferenceX GLM-5.3/B200 benchmark](https://inferencex.semianalysis.com/run/glm-5-3-on-b200) measures **9,876 total tokens/sec per GPU at an approximate 200-output-token/sec interactivity target** on the **AgentX coding workload** with optimized FP4/Dynamo SGLang serving. At a 50-output-token/sec target, its measured throughput differs: 13,575 total tokens/sec/GPU with another serving configuration. These are *benchmark operating points*, not Revolut production trace data. You must never describe 9,876 as **output tokens/sec per GPU**.

The [NVIDIA Dynamo GLM-5.3 recipe](https://docs.nvidia.com/dynamo/dev/recipes/glm-5-2) tests an agentic workload with **64K median input, 400 median output, 90% KV-cache hits, and KV-aware routing**. Its published B200 deployment examples require **16 GPUs** (four four-GPU workers) for an aggregated configuration and **20 GPUs** for a disaggregated one. A model shard can fit in four GPUs, and an eight-GPU server is a reasonable **capital-cost building block** for modeling, but that does **not** establish that a lone eight-GPU node replicates NVIDIA's production benchmark behavior, KV-cache headroom or failover. Test your topology.

For a capacity **upper-bound illustration**, assume 70% of the 9,876 total-token/sec/GPU benchmark is safely usable at the required latency, leaving 30% for scheduling, variation and spikes. This is our assumption, **not a vendor guarantee**.

| Hardware | 176 serving hours / month | 730 serving hours / month |
| --- | ---: | ---: |
| One B200 GPU | **4.38B** counted total tokens | **18.17B** |
| One 8×B200 server | **35.04B** | **145.34B** |
| Seven 8×B200 servers / 56 GPUs | **245.29B** | **1.017 trillion** |

At a fixed 200-token/sec interactive target, spreading a fixed quantity of work over **730 hours instead of 176 hours** increases monthly volume capacity about **4.15×**. It does **not** make a server capable of four times the concurrent peak traffic. More off-hour autonomous jobs can raise utilization, while daytime latency targets and queueing remain the binding constraint.

### The heavy-coding-user stress test

One 2.4B-token/month user (90% cached reads) consumes **6.85% of a single 8-B200 node's modeled 176-hour capacity**, or **1.65% of its modeled 730-hour capacity**. Therefore, without spare nodes or peak/latency effects, the benchmark-equivalent upper bounds are ~**14** such users per node in 176h or ~**60** if perfectly smoothed over 730h; across 56 GPUs ~**102** versus ~**424**. This does **not** refute Revolut's 2,000 engineers—it reveals why daily token volume and arrival patterns are missing variables in the headline.

With 2% output in the illustrative mix, that heavy user generates **48M output tokens/month**, averaging **~76 output tokens/sec during 22 eight-hour workdays**. An entire organization with 2,000 such users would request ~152,000 aggregate output tokens/sec while on shift. That is very different from 2,000 engineers holding occasional conversations.

### How much reserve capacity?

For seven eight-GPU nodes, **one-node failure removes ~14.3% of the fleet**. Either (i) keep *logical headroom* across active nodes and show latency still meets SLOs after one fails, or (ii) pay for an **additional physical hot/warm standby node**. For example, with 70% normal usage on 56 GPUs, losing eight leaves the original demand at approximately **81.7% of the surviving 48-GPU capacity**—before other failure modes or traffic spikes. A hot standby costs capital and power even if it creates no incremental billable tokens.

A single 8-GPU node is not an enterprise N+1 service. A rigorous purchase case should compare the **same number of resilient replicas** across on-prem, reserved cloud and API, and demand p95/p99 first-token latency plus sustained throughput load-test evidence.

## Rent GPUs: public alternatives and the hidden hourly contract

As of November 4, 2026, the major specialist cloud price pages show these illustrative **on-demand** rates. Availability, server topology, geographic region, networking and committed discounts may differ.

| GPU cloud / product | B200 per GPU-hour | 8 GPUs × 176h | 8 GPUs × 730h |
| --- | ---: | ---: | ---: |
| [Lambda HGX B200 8-GPU instance](https://lambda.ai/pricing) | **$6.69** | $9,420 | $39,070 |
| [RunPod Secure Cloud B200](https://www.runpod.io/pricing) | **$7.99** | $11,250 | $46,662 |
| [Together AI GPU Clusters B200](https://www.together.ai/pricing) | **$8.19** | **$11,532** | **$47,830** |

**Product selection matters.** Lambda also lists different 16+-GPU cluster contracts with longer minimum terms; Together's **dedicated inference** B200 list price is separate from **GPU Clusters**, and its **preemptible $4.09** rate is unsuitable as the only source of always-on low-latency service. RunPod community rates and secure-cloud rates are not identical. Reserving capacity for 90+ days often changes the break-even. Some providers have a minimum node size or availability-zone shortage; an eight-GPU equivalent is not a binding offer until confirmed.

If a workload can run during 22 eight-hour workdays and shut down without SLA penalty, paying for **176 hours** is much cheaper than paying for **730 hours**. The owned server's power bill and reserved floor-space may persist after the engineers go home. Conversely, off-hour autonomous agent fleets may use enough night/weekend capacity to make owning infrastructure more attractive.

## Buy B200 GPUs: the servers are an asset, but not a risk-free investment

You buy a **whole HGX system**—GPUs, CPUs, memory, interconnects, storage, cooling, rack space, networking, warranty—not eight consumer graphics cards. [Lenovo's June 2026 TCO study](https://lenovopress.lenovo.com/lp2368-on-premise-vs-cloud-generative-ai-total-cost-of-ownership-2026-edition) quotes **$550,475** as the usual customer price for its specific eight-B200 configuration. The [October 2026 Rack Report](https://www.amcompute.com/gpu-server-values/b200) indicates **$360K–$470K** for other standard eight-GPU nodes. Specifications, support and procurement terms differ; **$450K** is our illustrative purchase price, not a confirmed offer.

**Asset value is real; future resale is uncertain.** American Compute reports **too few used B200-server sales for a reliable observed resale price**. Its **forecast** for 36-month B200 residual value is approximately **16%–46%** of purchase price, depending on conservative versus moderate assumptions. This is a third-party forecast, **not** a guaranteed buyback or independent liquidation appraisal. GPUs can be sold, moved to another workload, leased to outside users, or retained as redundancy, but the operational and commercial terms determine whether they produce cash. NVIDIA's hardware roadmap and falling inference pricing can impair them long before the book-depreciation period ends.

### Three-year discounted cash-flow example: one eight-B200 server

| Variable | VCT scenario |
| --- | ---: |
| Upfront server purchase | $450,000 |
| Deployment / networking / setup | $20,000 |
| Hold and depreciate for analysis | 36 months |
| Terminal resale **scenario**, after 36 months | 30% × purchase = **$135,000** |
| Power, colo, network, warranty / support monthly | **$6,000** assumed |
| Annual opportunity cost of capital | **10%** |
| Dedicated MLOps engineering payroll | **Excluded from base; stress-test separately** |
| **Equivalent monthly economic ownership cost** | **$17,935 per node** |

For rigor, use **present value**, not just linear depreciation. Define monthly discount rate *r = 10% / 12*, term *n = 36*, and present-value annuity factor *A = (1 − (1 + r)^−n) / r*.

**Monthly ownership TCO = ((purchase + setup − terminal resale / (1 + r)^n) / A) + recurring operations.**

For this base case, it is **$17,934.51/month**. This is an **economic equivalent monthly cost**, not the cash you pay every month, an EBITDA figure, or an official tax depreciation rate. It assumes the hardware retains value only as an uncertain terminal cash flow, and financing cost is represented by the discount rate.

**Resale sensitivity, same hardware and other assumptions:**

| 36-month resale assumption | Monthly economic TCO |
| --- | ---: |
| **0%**—no recoverable hardware proceeds | **$21,166** |
| **16%**—lower 2029 residual forecast band | **$19,442** |
| **30%**—middle scenario | **$17,935** |
| **46%**—upper 2029 forecast band | **$16,211** |

A forced liquidation, storage and removal fees or hardware failure could push realization below the forecast bands. Conversely, a second internal workload may create **reuse value** greater than resale proceeds. Do not double count **reuse value and resale**: you can reuse the same server or sell it, not both.

**Power sanity check:** At an illustrative 14 kW IT power draw for an eight-B200 node, power-usage effectiveness of 1.3, 730 hours/month and $0.15/kWh, electricity alone is **~$1,993/month**. The other ~$4K of the assumed $6K operating budget must cover colocation, network, warranty and support. A dedicated on-call inference/SRE team may require **another $15K–$30K/month in fixed fully loaded personnel costs**; at one node, this can materially change the answer. The 14kW, PUE and electricity assumptions are not universally observed deployment costs.

### Buy-versus-rent crossover: 274–335 hours per month, before staffing

At Together's **$8.19 per GPU-hour**, eight GPUs cost **$65.52/hour**. Divide the **$17,935 economic monthly ownership cost** by that hourly rental rate: **~274 billable hours/month**. Against Lambda at **$6.69 per GPU-hour**, the break-even is **~335 hours/month**. This comparison assumes equivalent fully usable GPU configurations, identical inference quality and no incremental dedicated serving payroll.

- **176 hours/month:** Rent Together **$11,532** versus own **$17,935**. Renting wins.
- **730 hours/month:** Rent Together **$47,830** versus own **$17,935**. Ownership wins against *on-demand GPU rental*, provided the fleet is actually needed throughout the period.
- **One dedicated $15K/month platform operator, one node:** Own ~**$32,935/month**, moving the Together buy/rent crossover to **~503 hours/month**. The same operator cost spread over many nodes is much less significant.

**Cash payback is a separate calculation:** avoiding a $47,830 cloud rental while spending $6,000/month to operate an owned node would recover $470,000 upfront in roughly 11.2 months **if** you genuinely need 730 billed GPU hours every month, the cloud has no cheaper long-term contract, and the owned system is service-equivalent. This is a *simple cash-payback comparison*, **not** investment profit, an IRR, or a promise that 24/7 on-demand rental is the appropriate alternative for three years.

### What if you rent out your idle owned GPUs?

An owned server can potentially generate outside revenue, but that requires customers, a secure multi-tenant stack, billing, incident response, SLAs and distribution. It can also reduce availability for internal users.

**Illustration only:** a team uses its eight-GPU server 176 hours/month, leaving **554 potential hours**. Suppose it can sell idle time at **$4 of net incremental contribution per GPU-hour** *after* extra hosting fees and variable costs:

| Share of otherwise idle 554 hours sold | Monthly contribution | Net effective owned TCO |
| --- | ---: | ---: |
| 0% | $0 | **$17,935** |
| 25% | $4,432 | **$13,503** |
| 50% | $8,864 | **$9,071** |

To beat Together's **$11,532** work-hours rental bill in this scenario, you would need around **200 extra sold hours/node/month**, roughly **36% of the 554 idle hours**, at that assumed *net* contribution. This is **not** a forecast: customer demand and actual net selling rates may be lower or zero, and the accounting must avoid counting the same GPU capacity twice.

**Investor interpretation:** A B200 is a depreciating productive asset, not an appreciating securities investment. Its financial return arises from **avoided compute spend, cash-paying tenants, or productive reuse** *minus* capital costs and risks; a resale forecast alone is not operating yield.

## Interactive calculator: when does self-hosting break even?

Adjust engineers, cache ratios, GPU pricing and hardware depreciation below. The calculator compares subscription, managed API, GPU rental and owned-GPU economic cost under the same demand assumptions. Its outputs are scenarios, not quotes or guarantees of equivalent model quality.

[[VCT:GpuEconomicsCalculator]]

## Team-size economics: demand is more important than headcount

An eight-B200 node has a modeled limit of **35.04B counted tokens in 176 serving hours**, based on SemiAnalysis's **9,876 total tokens/sec per GPU at the 200-output-tokens/sec interactivity target**, 70% usable capacity, and no extra node reserved for failover. It is **145.34B in 730 continuous hours** if requests are sufficiently spread out.

At those assumptions, scaling by the number of engineers alone is wrong: an engineer consuming 100M tokens/month and the unusually heavy 2.4B-token/month example consume **24× different capacity**.

### How team size changes the decision

For the table, **a subscribed engineer costs a hypothetical $120/month** (the real power-user example's two legacy Cursor subscriptions), **every workload is served within 176 hours/month**, and infrastructure requires enough full eight-GPU nodes to process the total volume. **No standby node or $15K+ monthly dedicated inference engineer is included**—both should be added for production HA.

| Engineers | Tokens/user/mo | Active 8×B200 nodes | 120-dollar subscriptions/mo | Buy economic TCO/mo | Rent 176h/mo |
| --- | ---: | ---: | ---: | ---: | ---: |
| 50 | 100M | 1 | $6,000 | **$17,935** | **$11,532** |
| 200 | 100M | 1 | $24,000 | **$17,935** | **$11,532** |
| 500 | 200M | 3 | $60,000 | **$53,804** | **$34,595** |
| 100 | 2.4B | 7 | $12,000 | **$125,542** | **$80,721** |
| 2,000 | 100M | 6 | $240,000 | **$107,607** | **$69,189** |

**Read the table correctly:** At 200 engineers consuming 100M tokens monthly, a $17,935 owned node is below $24,000 in seat subscriptions, but renting those eight GPUs **for 176 hours is only $11,532**, and a pay-as-you-go GLM API might cost less still. At 100 super-heavy users consuming 2.4B tokens each, fixed subscriptions may be dramatically less expensive **if the product actually permits the workload**; a seven-node GLM fleet is not competitive at their reported $120/subscriber spend.

**Contrast a fully utilized service:** At 500 engineers × 200M counted tokens = **100B/month**, the same benchmark model fits within the **145.34B** one-node capacity when serving over 730 hours. An $17,935 owner/TCO could then beat 730-hour on-demand renting (~$47,830), 500 hypothetical subscriptions ($60,000), and the **GLM-5.3 API equivalent of ~$43,400**. Quality, 24/7 utilization, failover and staff payroll remain critical. No 8-GPU single-node design should be labeled highly available.

### Buy versus the same-model API: a stricter break-even

For **GLM-5.3**, the same 90% cache / 8% fresh / 2% output mix costs:

**Blended GLM API rate = 0.90 × $0.26 + 0.08 × $1.40 + 0.02 × $4.40 = $0.434 per 1M counted tokens.**

Equating this with the $17,934.51/month owned-node economic cost gives **41.3B counted tokens/month**, *at equal quality and developer experience*. Compare it with the node's benchmark-derived capacity:

| Serving window | Max modeled token capacity per node | Equivalent GLM API bill at that volume | Own node economic TCO |
| --- | ---: | ---: | ---: |
| 176 hours | **35.04B** | **$15,208** | **$17,935** |
| 730 hours | **145.34B** | **$63,078** | **$17,935** |

**Critical finding:** at 176 hours/month, buying cannot beat paying for the same-model API under **these exact capacity, cache and price assumptions**, even if the server runs flat out. At 730 hours, it can. This is not a categorical verdict for every company: vendor discounts, burstiness, model latency, migration costs and different cache accounting can reverse the result.

At the full modeled capacity, the owned-node economic infrastructure cost is about **$0.512 per million counted tokens at 176 hours** or **$0.123 per million at 730 hours**. Do not compare either rate to a token invoice that excludes cache reads without normalizing the denominator.

**For an alternative cheap hosted model**, the comparison can be even less favorable to buying B200s: at the hypothetical 90/8/2 mix, DeepSeek Flash's off-peak API would be approximately **$0.0267 per million counted tokens**, much lower than the maximum-capacity owned-node economics. This is *not* evidence DeepSeek Flash has GLM-5.3's or Claude's task quality or security guarantees.

### Mini-calculator: the decisions readers should test

Our separate, ready-to-integrate calculator uses these inputs:

1. **Team demand:** engineers, counted tokens per engineer/month, cache/fresh/output split (must sum to 100%), subscription price, and serving hours/month.
2. **Performance and reliability:** validated total tok/s per GPU at a specified user latency, usable fraction, GPUs/node, and separately reserved spare nodes.
3. **Cloud/own economics:** hourly rental price, complete server purchase and installation, monthly operations, years held, projected resale, cost of capital and incremental platform engineering cost.
4. **API comparison:** provider's current cached/fresh/output rates and applicable tool charges.

**Capacity needed = CEILING(total tokens per month / [GPUs per node × tested total tok/s/GPU × serving seconds/month × usable fraction]).**

**Total buy/month = active plus reserved nodes × discounted monthly ownership cost/node + incremental platform staff.**

**Total rent/month = active plus reserved nodes × GPUs/node × billed hours × hourly price + incremental platform staff.**

**Total API/month = cached tokens × cache price + fresh tokens × input price + output tokens × output price + other tool and platform charges.**

The calculator should always label the result **"estimated nominal economics; model-quality and peak-latency equivalence not established"**, rather than auto-declaring the cheapest row a purchasing recommendation.

## The best alternatives: use the right tier before spending capital

The most competitive option is usually a **portfolio of inference and developer products**, not a single cheap model. These categories have different integration, security and quality characteristics.

| Strategy or provider | Attractive use case | Why it may win | Risk to check |
| --- | --- | --- | --- |
| **Cursor/Claude Code/Codex/ChatGPT seats** | Developers with variable interactive demand | Tools, editor integration and model selection included | Quotas, legacy eligibility, enterprise per-seat licensing and non-poolable allowances |
| **DeepSeek Flash / GLM-5.3 Flash hosted API** | Repeated, routine high-cache tasks | Very cheap variable cost; zero GPU floor | Coding capability, rate limits, data residency, tool quality |
| **GLM-5.3 hosted at Z.ai / Together / DeepInfra / Fireworks** | Same open weights without operations work | Zero hardware purchase and actual pay-per-token costs | Vendor availability, tokenizer/billing differences, cache behavior, region |
| **Claude Sonnet/Opus or GPT-6.1 frontier API** | Hard coding tasks, critical reviews and multi-step debugging | Stronger task completion may require fewer attempts or less human time | Higher output cost and prompt-cache policy |
| **Rent B200s: Lambda, Together, RunPod** | Steady-but-uncertain load; evaluation and short commitments | No residual-value risk and can scale down | Hourly minimums, idle allocation, GPU availability, standby capacity |
| **Buy eight-B200/B300 servers** | High, stable demand over 24/7, privacy-driven deploys | Lowest fixed-compute cost at sufficient utilization; resale/reuse optionality | High capex, staffing, facility cost, slow hardware delivery, obsolescence |
| **Existing RTX PRO 6000 / H200 / MI355X / small-model clusters** | Narrower open models; smaller company workloads | Better-fit capacity without paying for flagship HGX B200 | Model sharding, cross-GPU interconnect, throughput and memory limitations |

**Model candidates to benchmark before buying:** GLM-5.3 (closest to the Revolut example), GLM-5.3 Flash, current DeepSeek Flash/Pro, Qwen open-weight coding models, Kimi, and smaller gpt-oss/Qwen families. Do not declare one model "equally good" using different benchmark suites. Run an evaluation suite of real repository tasks: time-to-accepted patch, tool success/failures, security regression checks and human review minutes.

**Serving software:** NVIDIA Dynamo/SGLang and vLLM are mature open-source directions worth evaluating; the [NVIDIA GLM-5.3/5.2 example](https://docs.nvidia.com/dynamo/dev/recipes/glm-5-2) uses FP4 B200 workers, KV-aware routing and realistic cached coding traces. SemiAnalysis [InferenceX](https://inferencex.semianalysis.com/run/glm-5-3-on-b200) demonstrates how throughput and per-user speed can trade off. A benchmark taken at 50 output tokens/s cannot be substituted for the throughput at Revolut's 200 tok/s target.

**Compliance and supply chain:** Self-hosting a Chinese-developed open-weight model can keep inference traffic in the organization's own perimeter—but only after auditing the model artifacts, licensing, dependencies, sandbox permissions, logs, retention, PII handling and applicable data-transfer rules. Security comes from the deployment architecture and governance, not the model's country of origin alone.

**Avoid an especially common procurement mistake:** a **$450K node purchased** versus **$8.19/GPU-hour cloud list price** is not a full choice set. Compare the provider's **reserved term**, spot/preemptible limitations, model API with real cache-hit ratio, alternative open models on fewer GPUs, electricity and networking, N+1, hardware warranty, on-call staffing and opportunity cost of capital.

## What engineers actually ask: six 2026 Reddit case studies

Published articles often choose a GPU price, divide it by a per-token API rate, and announce a break-even. Users ask harder questions: *What happens when the hardware is idle? Are subscriptions subsidized? How much of my context is cached? What about the person on call? Will my GPUs still be valuable after three years?* The following are dated **self-reported community examples**, not independently audited company disclosures or representative survey results. Their value is in the *questions and methods*, not in treating every claim as a benchmark.

| Community evidence | Reported experience | Implication for the model |
| --- | --- | --- |
| [r/LocalLLaMA: $6,406 used MI100 server](https://www.reddit.com/r/LocalLLaMA/comments/1tsbl9j/cost_analysis_of_my_64k_local_llm_server/) | One operator describes four used MI100s running Qwen3.6 27B, with **20.4M input and 1.32M output tokens per day**, **630W at the wall**, about **$64/month power** and **$308/month API-list-price equivalent**. | Small existing/used GPUs can win for a narrow, stable workload. Include **salvage**, power and the model's real output speed; do not scale a 27B example directly to an 800B GLM fleet. |
| [r/kubernetes: teams that moved to self-hosting](https://www.reddit.com/r/kubernetes/comments/1wv76bd/teams_that_moved_from_llm_apis_to_selfhosting_was/) | An anonymous respondent claims a prior **$14K/month API bill**, **$60K in A100 hardware**, and weeks spent correcting autoscaling and cold starts. | MLOps time, p95 latency and incident response can erase apparent compute savings. A social comment is not an audited case study. |
| [r/ClaudeAI: $200 subscription vs $7,470 API-equivalent](https://www.reddit.com/r/ClaudeAI/comments/1vbvdzl/200_subscription_vs_7470_of_api_usage/) | One developer deduplicated Claude Code session-token records and estimated **$7,470 at retail API rates** while paying a **$200** subscription, noting they still hit limits. | API list-value **is not Anthropic's marginal serving cost**, and an individual subscription is not an unlimited commercial API commitment. |
| [r/ClaudeCode: 19.59B token operations across sessions](https://www.reddit.com/r/ClaudeCode/comments/1uupcp1/i_ran_247_agent_sessions_across_five/) | A developer reports **94% cache reads**, **61.8M output tokens** and **$19.7K API-list equivalent** across 247+ sessions, while actual subscriptions were much cheaper. | Counted tokens are a poor proxy for generated output, cost to serve or productivity. Include cache and output mix. |
| [r/ClaudeCode: are cache reads counted against plan limits?](https://www.reddit.com/r/ClaudeCode/comments/1vejlfo/nobody_outside_anthropic_can_tell_you_whether/) | The author correctly distinguishes published **API token/rate-limit rules** from undisclosed **subscription quota metering**. | Do not promise that API cache discounts translate one-for-one into more subscription allowance. |
| [r/codex: measuring effective subscription value](https://www.reddit.com/r/codex/comments/1x1y2c1/codex_200_500_my_logs_show_apiequivalent_token/) | One self-reported study says a $500 tier delivered a **lower API-equivalent value per paid dollar** than its author's former $200 tier. | More expensive subscription tiers are not guaranteed to scale linearly in usable token capacity, especially across time windows. |

**A worked check of the $6.4K used-GPU story:** the poster's $308/month API-equivalent minus ~$64/month electricity is **$244/month** of gross operating avoidance. Dividing $6,406 by $244 gives a **~26-month simple cash payback** **before** labor, motherboard failures, insurance, network, opportunity cost or resale. If used hardware can be resold, economic TCO can be lower; if the process stops needing that model or output quality drops, payback may never occur. The poster also warned that the coding-plan comparison needed another telemetry check—another reason to label it anecdotal.

These cases explain why three calculators are necessary within one article: **API token pricing**, **GPU buy-versus-rent**, and **the fully allocated cost of a productive AI engineering workflow**.

## A faster model can be economically cheaper even with more expensive tokens

Cost per million tokens alone can reward low-quality systems that generate cheap but unusable patches. Build an evaluation from real GitHub issues with the same agent instructions, test suites and review policy. Track accepted changes, retries, tool execution and human review time. Model drift and false positives belong in the denominator.

**Hypothetical quality-adjusted example** at a **$75/hour** fully loaded engineering rate (illustrative—not vendor benchmark data):

| Metric per attempted task | Model A: expensive but accurate | Model B: cheap but requires more correction |
| --- | ---: | ---: |
| Model/API cost per attempt | $3.00 | $0.50 |
| Success and acceptance rate | 90% | 75% |
| Human review/fix time per accepted change | 10 minutes | 25 minutes |
| Approximate model cost / accepted task | $3.33 | $0.67 |
| Human time / accepted task | $12.50 | $31.25 |
| **Quality-adjusted cost per accepted task** | **$15.83** | **$31.92** |

The cheaper model's inference is **six times less expensive per attempt**, yet the entire accepted task is about **twice as costly** once review time is included. This is why enterprise buyers should test a fallback to premium frontier models before deciding that 100% of requests belong on a cheaper self-hosted endpoint.

**Operational denominator:** dollars per accepted, tested change = *(inference + tools + GPU overhead + SRE + failed retries + review labor) / accepted changes*. Report it by task class and maintain a holdout evaluation set. If the cheaper model fails critical security tasks at a higher rate, that risk cannot be reduced to one blended token price.

## An independent plausibility check on Revolut's 56-GPU throughput

Revolut's own [talk and slides](https://ai.engineer/talks/Ok6QdZHCcI8-revolut-cut-ai-coding-costs-90-self) show a stable serving phase at around **5.95 requests/second**, compared with 3.38 during its earlier TP8 migration. The slides describe **76% more requests/second** and **88% lower first-token latency**, measured on the same 56 GPUs. Those numbers prove the internal serving configuration improved; **they do not disclose mean prompt length, cache hits by request, or total per-engineer tokens**.

As a **sanity check, not a production measurement**, 56 GPUs × the independent [9,876 total tokens/sec per GPU benchmark](https://inferencex.semianalysis.com/run/glm-5-3-on-b200) equals **~553K benchmark total tokens/sec**. Dividing that by **5.95 RPS** would imply **~93K counted tokens/request if running at 100% of that benchmark** or **~65K at the article's illustrative 70% usable capacity**. This *does not establish that Revolut runs 65K prompts*: the benchmark uses a different workload, cache mix and optimized model-serving stack. It shows that engineers need to collect **request-weighted real token traces**, not reverse-engineer production traffic from one slide.

This cross-check also limits claims about concurrency. A **request per second** is an arrival-rate measure, while a **200 output-token/sec stream** is a per-request decoding speed. A large input prefill may produce very few output tokens; cached context does not cost the same GPU work as fresh context. Sizing from total tokens alone should be explicitly described as a **screening estimate**, not a production capacity guarantee.

## What other cost calculators and guides leave out

The following are worth comparing before commissioning an enterprise inference platform; none supplies audited Revolut traffic. They illustrate why a **new synthesis** is useful:

| Public comparison or tool | Strength | Still needed to answer this article's full question |
| --- | --- | --- |
| [Finout's Claude Code pricing analysis](https://www.finout.io/blog/claude-code-pricing-2026) | Subscription levels, quota mechanisms, cost spikes and monitoring | Independent same-task GLM fleet capacity, purchased B200 cash flows and residual value |
| [Helicone's LLM cost calculator](https://www.helicone.ai/llm-cost) | Current API rate cards and per-model cost math | Physical GPU ownership, operating hours, team size and enterprise failover |
| [nkrimmel's open-source LLM TCO model](https://github.com/nkrimmel/llm-tco) | 12/36-month API-versus-self-host TCO, sensitivity, concurrency and shareable scenarios | Revolut's exact deployment, 2026 B200 resale and unusually high coding-cache shares |
| [LeanLM's self-hosting cost study](https://leanlm.ai/blog/self-hosting-llm-cost) | Same-open-model API versus self-hosting and utilization sensitivity | Real-user Cursor, Claude and ChatGPT subscription economics and purchase salvage |
| [Cloud Parity's inference calculator](https://cloudparity.io/calculator) | Multi-provider rental price comparison and model sizing | Recoverable resale/finance and a full GPU-owned-vs-subscription view |
| [LLMTCO's API versus self-host tool](https://llmtco.com/compare/api-vs-self-hosting/) | Editable tokens and 12/24/36-month horizon | Revolut-specific latency targets, ownership/resale and accepted-task cost |
| [Premai's self-hosted LLM guide](https://www.premai.io/blog/self-hosted-llm-guide-setup-tools-cost-comparison-2026/) | Practical setup and popular queries about running models | Subscription usage patterns, cash-flow modeling and a 56-B200 production case |

**The key difference:** our calculator is intended to ask not merely "which rate is cheaper" but **"can the configuration actually serve the demand within the chosen latency and failure budget, and is it cheaper on a fully comparable task?"** A calculated break-even that exceeds one node's available throughput is an impossible break-even for that configuration.

## Why this matters to venture investors and infrastructure startups

The [VCT AI infrastructure funding map](/ai-infrastructure-startups-funding-2026) tracks neoclouds, inference platforms, networking, chips and data centers; this case explains **how a buyer might underwrite their services**. The gross margin of a GPU-cloud startup and the ROI of its customers depend on actual demand: running costs are not automatically justified by a large model, a large user count or an impressive benchmark.

A venture diligence memo should request six reproducible outputs:

1. **Real token traces:** cached reads, cache writes, fresh input and output by model, hour and tenant.
2. **Workload shape:** p50/p95/p99 first-token time, decoding throughput, concurrency bursts and context-length distribution.
3. **Accepted-task economics:** dollars per completed, tested change, including retries, tool use and developer review.
4. **Asset quality:** delivered GPUs, purchase price, warranty, installation and time to first revenue-generating inference.
5. **Capital and exit exposure:** cost of funds, encumbrances, depreciation and a resale sensitivity with a downside case of zero.
6. **Safety and retention:** customer data restrictions, fallback percentage, uptime, model drift, workload retention and gross margins after full overhead.

The highest-return intervention may not be a GPU purchase. It may be a cheaper default model, improved prefix caching, a shorter context, better agent instructions, lower output verbosity, scheduled workloads, or a smarter frontier fallback. Conversely, at sufficiently steady utilization, renting perpetual 24/7 capacity may transfer a very large margin to the provider.

See [Qodo's code-verification economics](/2026-qodo-70m-code-verification) and [Factory's coding-agent funding case](/2026-factory-200m-5b-khosla-sequoia-coding-agents) for two examples of why accepted engineering work matters more than tokens. The winner is the system that delivers **the lowest quality-adjusted cost per accepted unit of work**, with enough reliability that engineers actually use it. That is a stronger investment metric than dollars per million tokens alone.

## Research notes and reproducibility

**As-of date:** November 4, 2026. US-dollar prices are public US list prices, excluding tax and discounts unless stated. The 2.4B-token Cursor example is self-reported. The 100M and 200M per-employee scenarios, $450K node, 30% resale after 36 months, $6K/month operations, 10% capital cost and 70% benchmark utilization are **VCT assumptions**. The 9,876 total-token/sec/GPU value is a published benchmark at a specific user-speed target, **not** a Revolut fleet average. No throughput, resale value or GPU availability should be inferred as guaranteed. This is an operating-economics analysis rather than financial or procurement advice.

For updated workloads, recompute before purchasing: subscription rules and AI API prices change quickly, while hardware acquisition and facility commitments can last years.

**By:** [Venture Capital Tracker](https://venturecapitaltracker.com/editorial-policy)

**Editorial note:** AI tools assisted with research, structure, or drafting. Venture Capital Tracker retains human editorial responsibility for factual accuracy, relevance, and source quality before publication.