Revolut Self-Hosted GLM-5.3: Costs and the API Alternative

For most teams evaluating Revolut’s self-hosted GLM-5.3 results, start with a metered API pilot. Keep a frontier-model route for tasks that fail your quality checks. Consider dedicated hosting only after your own traffic, latency, and operating costs support it.

The figures below distinguish Revolut’s reported results from recommendations for your team. Documentation and API prices were checked on 2026-11-09.

What did Revolut actually deploy?

Revolut made open GLM models its default for roughly 2,000 engineers and retained frontier models for exceptions. Its AI Engineer presentation and transcript describe the move from GLM-5.1 to GLM-5.3. The later deployment used 56 Nvidia B200 GPUs.

The operating-metrics slide also names Together. Do not turn this into a claim that Revolut bought 56 cards for its own premises. The slide identifies a partner, not hardware ownership or the full operating arrangement.

The model endpoint and coding client are separate choices. Do not make a model change depend on replacing every coding client. In the described architecture, GLM handles text-based work while a router sends image understanding to a vision-capable model.

The productivity claims need their own boundary. Abitbol reported about 60% better coding time and 70% better lead time. However, the adoption slide labels lead-time improvement as 60%.

Treat these as reported internal trends, not a controlled GLM-versus-Claude benchmark. They do not establish that changing the model alone caused the improvement.

What does the 90% cost reduction measure?

The headline compares Revolut’s reported inference invoices, not the total cost of employing its engineers or owning infrastructure. The official talk account describes a bill around one-tenth of earlier frontier-provider spending. One-tenth of the previous bill means a 90% reduction.

Separately, The Register’s report attributes $0.30 per million input/output tokens to Revolut’s GLM-5.1 phase. Keep that historical per-token figure separate from the reported bill reduction. It is neither a public GLM-5.3 API tariff nor a Claude Code or Codex subscription allowance.

The operating-metrics slide also marks cached tokens as free. However, the talk account does not provide matched traffic and billing periods. It also lacks the operating-cost breakdown needed to reconstruct an all-in figure. Do not label $0.30 a fully amortized ownership cost.

Before comparing a hosting proposal, ask what its numerator includes: GPU rental or depreciation, supporting servers, networking, storage, power, support, and engineering labor. Check whether those charges are already bundled to avoid counting them twice.

Then define the denominator. Fresh input, cache reads, and generated output are different billing categories. An average that includes zero-priced cache reads cannot be compared directly with an uncached input price.

Why 256K context and a three-second first token?

Use 256K as a workload budget to test, not as GLM-5.3’s model limit. Z.ai’s current model documentation lists text-only input and a 1M-token context window.

Abitbol’s “Long context is a scam” remark describes his serving tradeoff. Longer requests need more context storage and input processing. That leaves less room for concurrent sessions on a fixed fleet.

His practical targets were under three seconds to first token and roughly 200 generated tokens per second. They describe Revolut’s desired experience, not a guarantee that every fresh 256K-token request completes its input processing within three seconds.

For your pilot, measure cold requests separately from requests that reuse cached context. Record median and 95th-percentile latency at normal and peak concurrency. Measure task completion too: fast token generation does not include time spent running tests or waiting for tools.

Start with relevant files and retrieved evidence rather than filling the available window. Reserve room for output. Increase the context budget only when accepted-task results justify the added cost or delay.

Which parts require GPU capacity and operations work?

Reproducing Revolut’s serving performance requires workload-specific tuning, not merely loading the same model weights. Its performance slide shows first-token latency falling from 14.26 seconds to 1.68 seconds on the same 56 B200 GPUs.

That is about an 88% reduction in first-token waiting time. It is not evidence that every coding task became 88% faster.

The talk discusses FP4 quantization and separating prefill from decode. Prefill processes the input. Decode generates output tokens. These are serving-system choices that require capacity testing and an operator responsible for regressions.

The 56-card fleet is also not a minimum hardware requirement for loading GLM-5.3. The current vLLM recipe documents single-node FP8 deployment on eight H200 or H20 GPUs. That smaller configuration does not promise Revolut’s concurrency, latency, or economics.

For a dedicated-hosting pilot, request a replay of representative agent sessions on the proposed hardware. Fix the model checkpoint, precision, context budget, and peak concurrency. Require both passing task results and acceptable latency before expanding capacity.

What can a team copy without 56 GPUs?

Copy the default-model policy and evaluation method before copying the infrastructure. The following is a proposed pilot, not a reconstruction of Revolut’s private configuration.

Select 20 representative repository tasks, such as bug fixes, tests, refactors, and documentation changes. Run GLM-5.3 and your current model from the same starting commits. Keep the coding client, tool permissions, acceptance tests, and review criteria fixed.

Give each run its own working copy. A successful task must read the required files, produce a reviewable change, and pass the agreed checks. A plausible chat answer is not enough.

Use an explicit routing policy:

• Send ordinary text-based coding tasks to GLM-5.3.
• Send tasks that require interpreting images to an approved vision-capable model.
• After a failed repair attempt, or an explicit reviewer request, escalate to the frontier route and record the reason.

This policy is an evaluation starting point, not a universal optimal retry count. Keep both routes within your approved data-handling and tool-permission rules.

For a client-side routing implementation, use the Claude Code Router configuration guide. That is an implementation option, not a claim that Revolut used that package.

Record input, cached input, output, failed attempts, escalation charges, elapsed time, and human review time. Compare total spending per accepted task. The coding-agent cost-per-task guide explains why a lower token rate alone cannot settle that comparison.

Promote GLM-5.3 only for task categories that meet your quality threshold. Keep the existing route where additional retries or review erase the savings.

What does GLM-5.3 cost through an API?

Z.ai’s standard API provides a measurable baseline without a GPU commitment. As of 2026-11-09, its published pricing lists these USD rates for GLM-5.3:

Token category	Price per 1 million tokens
Uncached input	$1.40
Cached input	$0.26
Output	$4.40

Cached-input storage is listed as free for a limited time. Do not treat that temporary condition as a permanent term.

For an illustrative workload with 100 million input tokens and 10 million output tokens, the uncached model-token charge is:

100 × $1.40 + 10 × $4.40 = $184.00

If 90 million of those input tokens are billed as cache hits, the estimate becomes:

10 × $1.40 + 90 × $0.26 + 10 × $4.40 = $81.40

These are calculated examples, not measured bills. They assume no paid tools and cover model-token charges only. The 90% cache share is an example assumption, not a promise about your workload.

Use the actual response field usage.prompt_tokens_details.cached_tokens to distinguish cached input. Z.ai documents that field in its context-caching guide.

BetterToken’s catalog, checked on 2026-11-09, also lists glm-5.3. Its OpenCode GLM integration uses the OpenAI-compatible base URL https://www.bettertoken.ai/v1. Compare its current prices for your measured traffic mix; this API route does not reproduce Revolut’s infrastructure economics or include a coding-tool subscription.

To check Z.ai access, create a Standard API Key using its HTTP API instructions. Use a funded standard API account for this example.

Run this in Bash with curl installed. The first command waits silently for your key. Paste it and press Enter; the key will not appear on screen.

read -rs ZAI_API_KEY && export ZAI_API_KEY

curl --silent --show-error \
  --write-out '\nHTTP %{http_code}\n' \
  "https://api.z.ai/api/paas/v4/chat/completions" \
  -H "Authorization: Bearer $ZAI_API_KEY" \
  -H "Content-Type: application/json" \
  --data '{
    "model": "glm-5.3",
    "messages": [
      {"role": "user", "content": "Return exactly READY."}
    ]
  }'

The Chat Completion reference documents this endpoint and response format. Check for HTTP 200, a nonempty choices[0].message.content, and the usage object. The expected answer is READY; this checks access, not coding quality or tool execution.

For HTTP 429, inspect the JSON error code before retrying. Z.ai distinguishes 1113, insufficient balance or resource package, from 1302, a request rate limit. Fund the correct API account for the first case; reduce request frequency for the second. These meanings are specific to Z.ai’s error reference.

Does Yingjun Wu’s 35% break-even apply to your team?

No. Wu’s analysis concerns selling DeepSeek V4.1 Flash inference, not serving GLM-5.3 to an internal engineering team.

In his analysis updated on November 2, 2026, H200 fails to cover rent even at full utilization. His B300 case breaks even near 35%. The H200 case earns about $1.60 per GPU-hour against $3.99 in rent. Those rounded inputs leave a calculated $2.39 hourly shortfall even before other costs.

His calculation excludes bandwidth, people, and spare capacity. Treat those inputs as his scenario, not current rental quotes or measurements reproduced here.

The useful lesson is the method. For internal hosting, replace token-sales revenue with the API spending your deployment would actually avoid. Recalculate with your model, cache mix, achievable throughput, quality checks, and required latency.

Which deployment should you choose?

Choose metered API access when demand is uncertain or your team lacks inference operators. Revisit that choice when repeated measurements show that avoided API spending can cover a complete hosting quote.

Pilot dedicated hosted capacity when demand is steady but owning and operating hardware is not your goal. Require a contract that states who handles upgrades, capacity limits, failures, data location, and support. Stay metered when the required commitment exceeds your realistic usage.

Operate your own inference stack when control requirements justify it and a team can maintain it. Reverse the decision if peak-load latency, quality regressions, or staffing costs remove the expected benefit.

Before signing, require an accepted-task comparison, a peak-load replay, an all-in monthly budget, and a named operational owner. Include idle capacity and frontier exceptions. Use the team self-hosting TCO framework for the wider budget, rather than treating Revolut’s historical GLM-5.1 figure as your forecast.