RivenGet started
Back to blog
GuidesJuly 26, 2026

LLM API pricing comparison: how per-token billing really works

How per-token pricing works

Every commercial LLM API bills by the token, not by the request, the character, or the word. A token is roughly four characters of English text, or about three-quarters of a word. You pay for two separate quantities on every call:

  • Input tokens — the prompt, system instructions, context, and any retrieved documents you send to the model.
  • Output tokens — the text the model generates in response.

Output tokens almost always cost more, typically 3x to 5x the input rate, because autoregressive generation is more compute-intensive than processing a prompt.

A pricing page that advertises "$2 per 1M tokens" without specifying input or output is incomplete. Real comparisons need both numbers.

The markup that most gateways hide

Model publishers — the companies that train and host the weights — publish list prices. Anthropic, OpenAI, Google, Zhipu, Moonshot, and others all publish per-million-token rates that anyone can read.

Gateway and reseller APIs sit between you and the publisher. Some pass list price through transparently. Others add a margin, anywhere from 10% to 40%, and present the marked-up rate as if it were the base price. A few round token counts up, bill on rounded packages, or charge separate fees for features like context caching and tool calls.

The practical effect: two gateways listing the "same" model can produce materially different monthly bills. The only way to know is to compare the effective per-token rate against the publisher's published list price.

Riven passes every vendor's list price through with transparent per-token pricing and syncs rates daily. The model catalog shows the current input and output price for each of the 160+ models, and those numbers match what the publisher charges. There is no second price sheet, no volume-tier surcharge, and no per-feature fee layered on top of the base rate.

A worked example: production app monthly bill

Consider a production application that handles customer support triage. Realistic monthly usage:

  • 40M input tokens (tickets, conversation history, system prompts)
  • 8M output tokens (classifications, draft responses, summaries)

Running on Kimi K3 at $3/1M input and $15/1M output:

\[ \text{Input cost} = 40 \times \$3 = \$120 \] \[ \text{Output cost} = 8 \times \$15 = \$120 \] \[ \text{Total} = \$240 \text{ per month} \]

Running the same workload on GLM 5.2 at $1.40/1M input and $4.40/1M output:

\[ \text{Input cost} = 40 \times \$1.40 = \$56 \] \[ \text{Output cost} = 8 \times \$4.40 = \$35.20 \] \[ \text{Total} = \$91.20 \text{ per month} \]

The GLM 5.2 bill is less than 40% of the Kimi K3 bill for the same token volume. Whether GLM 5.2 is good enough for your task is a quality question, not a pricing question, but the cost difference is large enough that it is worth testing before defaulting to a more expensive model. A common pattern is to route easy, high-volume requests to a budget model and reserve frontier models for the harder subset that actually needs them.

Now add a gateway that marks Kimi K3 up by 25%. The input rate becomes $3.75/1M and the output rate $18.75/1M. The same workload now costs $300 per month instead of $240 — a $60 monthly delta that grows with volume.

Why list-price passthrough matters

If your application runs meaningful volume, a 20% markup is not a rounding error. Over a year, the Kimi K3 example above costs $2,880 at list price and $3,600 with a 25% markup. The difference, $720, buys roughly 240 million additional input tokens at list price.

List-price passthrough means the rate you see on the pricing page is the rate the publisher charges, nothing added. Combined with daily sync, it means you capture every price reduction the moment the publisher ships it.

Comparing models side by side

Reading 160+ pricing pages by hand is impractical. The LLM API pricing calculator lets you enter monthly input and output token counts once and sort every model by total cost. Per-model detail pages, for example Kimi K3, show current rates and specifications.

Try it