How LLM API pricing is calculated

Three rates, not one

A per-token price is never a single number. Every model on this platform carries three: what you pay to send tokens in, what you pay when those input tokens hit a prefix cache, and what you pay for tokens the model writes. Quoting only the first is how a rate card ends up looking half its real size.

Here is the full card for the five text models we currently serve, in USD per million tokens, with the model publisher's own official rate alongside. The savings column is a blended figure, and the section below explains how it is blended, because that calculation is where most published percentages quietly cheat.

Why output costs more than input

Reading a prompt and writing an answer are different computations. Input tokens are processed in one batched forward pass over the whole sequence, which saturates a GPU efficiently. Output tokens are produced one at a time, each requiring a full pass over the model weights, and each one waits for the previous. The second is the expensive half, and the rate card reflects it.

The multiple varies a lot by model, and it changes which model is cheapest for a given shape of work. Kimi K3 charges 4.9x more for output than input; DeepSeek V4 Flash charges exactly 2x. A summarisation job that reads 50,000 tokens and writes 300 is priced almost entirely off the input rate. An agent that reads a short instruction and writes a long file is priced almost entirely off the output rate. Comparing two models on their input rate alone will pick the wrong one about half the time.

The arithmetic on one real request

A two-token prompt to GLM-5.2 that produced 77 completion tokens. Input: 2 tokens at $0.82 per million is $0.00000164. Output: 77 tokens at $2.55 per million is $0.00019635. Total $0.00019799 -- which is exactly what the response carries.

That field is the one non-standard key in our responses. It exists so that nobody has to reconcile a bill against a rate card to find out what a call cost. If the number in usage.cost_usd ever disagrees with the number on the pricing page, the pricing page is a lie, and that is a much more serious defect than a slow endpoint.

curl https://router.xark.io/api/v1/chat/completions \
  -H "Authorization: Bearer sk-..." \
  -H "Content-Type: application/json" \
  -d '{"model":"z-ai/glm-5.2","messages":[{"role":"user","content":"Hello"}]}'

# "usage": {
#   "prompt_tokens": 2,
#   "completion_tokens": 77,
#   "total_tokens": 79,
#   "cost_usd": 0.00019799
# }

The smallest amount of money this system can move is $0.000002

Underneath the decimal prices there is an integer. The gateway holds balances in its own quota unit, where 500,000 quota is one US dollar -- so one quota unit is $0.000002, and no charge, refund or balance can land between two of them. Our own append-only credit ledger runs on a finer grid, integer micros at $0.000001 each, but the coarser of the two grids is the one that decides what actually moves.

That matters more than it sounds at these prices. On DeepSeek V4 Flash at $0.09 per million input tokens, a single token is worth $0.00000009 -- about a twenty-second of the smallest unit the system can represent. You need 23 input tokens before the charge reaches one quota unit at all.

This is also why our money formatting refuses to print $0.00. A genuine spend of $0.001386 rendered at two decimal places tells a customer they were charged nothing, and tells an operator that consumption is zero. Both are false, and both fail in the direction that hides a problem, so precision follows magnitude: below a hundredth of a cent the UI says less than $0.00001 rather than picking a rounding that lies.

How a published rate becomes a billing ratio

The gateway does not store dollars per million tokens. It stores a multiplier, and computes quota as prompt tokens times the ratio, plus completion tokens times the ratio times a completion multiplier. Because 1,000,000 tokens at ratio 1 costs 1,000,000 quota, and 500,000 quota is a dollar, a ratio of 1 means $2 per million. The conversion is therefore: ratio equals the published dollar rate divided by two.

Getting that divisor wrong by a factor of two is the entire failure mode of this design, and it would be invisible until a customer reconciled a bill. So the catalogue is the source and every ratio is derived from it by a script -- the ratios are never typed by hand -- and the script prints a round trip for one model and exits non-zero if converting back does not land within a millionth of the published price.

For GLM-5.2 at $0.82 in, $2.55 out, $0.16 cached, the three numbers written to the gateway are the ones below. Note that cached input is stored as a fraction of the input rate rather than as its own absolute price, which is why a cached rate here can never drift above the uncached one.

What a percentage saving means here

A saving quoted against a two-sided rate card needs a stated method, because averaging the input and output percentages is not the same as the money a customer keeps. Our figure blends the two, weighted one to three in favour of output, because real workloads spend far more of their bill on the writing side than on the reading side.

For GLM-5.2: the official blend is $1.40 plus three times $4.40, or $14.60. Ours is $0.82 plus three times $2.55, or $8.47. That is a 42% reduction, and it is the number the site prints and the API returns in savings_percent.

The claim we do not make is that this is the cheapest inference anywhere. It is not. DeepInfra publishes Llama 3.3 70B at $0.10 input and $0.32 output per million, which is a floor set by a company that owns its own serving stack; Together AI publishes the same model at $1.04 flat. Our claim is narrower and checkable: below the model publisher's official rate, with no fee on top.

Reading the rate card programmatically

The full card is a public, key-free, CORS-open JSON endpoint. Publishing it is a positioning decision rather than a convenience: a platform whose argument is that there is no hidden markup should let anyone diff its rates automatically, including the comparison sites that would otherwise scrape the HTML and get it wrong.

The models endpoint carries the same figures per model, plus the official rate and the blended saving, in a namespaced pricing object. It is namespaced deliberately -- an SDK that validates strictly will ignore an unknown key but will choke on a redefined known one, so platform data hangs off its own object rather than being sprinkled into the top level of a model record.

# The whole rate card. No key, CORS-open, cacheable.
curl https://router.xark.io/api/v1/pricing

# One model, with the official rate and competitor rates alongside.
curl https://router.xark.io/api/v1/models/z-ai/glm-5.2

# Every text model, priced.
curl "https://router.xark.io/api/v1/models?type=text"

A short checklist for costing a workload

Count input and output separately. An estimate built on a single blended rate will be wrong by the output multiple, which on Kimi K3 is a factor of five.

Check whether your prompt repeats. If a fixed system prompt is resent every turn, the cached-input rate governs most of your bill, not the input rate.

Read usage.cost_usd on the first hundred real requests rather than trusting a spreadsheet. Tokenisation rarely matches a character-count estimate, and the response already contains the truth.

If you stream, ask for usage explicitly. Without stream_options.include_usage a streaming caller never learns what the call cost, because the usage block only exists on the blocking response.