Home › Guides › How LLM API pricing works

How LLM API pricing actually works: a developer's field guide

LLM API bills surprise developers not because prices are hidden — every provider publishes them — but because five different billing concepts get multiplied together: input, output, cached input, reasoning tokens and batch rates. This guide explains each one, shows which is probably eating your budget, and ends with how to compare two models on your real workload instead of headline rates.

The unit: per million tokens

Nearly every LLM API prices in dollars per 1M tokens. A token is roughly three-quarters of an English word; code and non-English text use more tokens per word. Two things to internalize:

Prices are quoted per 1M tokens but you pay for fractions. If input costs $3 per 1M and your request used 8,000 tokens, that's $0.024 — not $3.
Rates vary by orders of magnitude. At the time of writing, flagship models run a few dollars per million input tokens while lightweight models run a few cents. The spread between the cheapest and priciest serious model is roughly 100×. That spread is exactly why a price tracker exists: the model you picked in January may have three cheaper equivalents by October — see the current spread on the cheapest models page.

Input vs. output: the two prices that matter

Every model quotes two headline numbers: input (what you send) and output (what it generates). Output is almost always the expensive side — commonly 3–4× the input price, and sometimes 10× or more on flagship models.

Why this matters more than it looks: output pricing is where the model choice bites. A reasoning-heavy workload (agents, chain-of-thought, code generation) produces far more output tokens than input tokens. Two models with the same input price can differ by 5× on your actual bill if one is output-heavy. Always price the workload, not the headline rate — plug your real volumes into a cost calculator instead of eyeballing the table.

The third price: cached input

Prompt caching is the single most underused discount in LLM APIs. When you resend the same prefix (system prompt, documents, few-shot examples), providers can serve it from cache and charge a cached-input rate that's typically 5–10× cheaper than fresh input. Most model pages here list the cached-input rate next to the regular one.

Example math, with illustrative numbers: a system prompt of 5,000 tokens at $3/1M input costs $0.015 per request fresh. With cache hits at $0.30/1M, the same 5,000 tokens cost $0.0015. If that prompt ships in every one of your 100,000 daily requests, caching takes that line item from $1,500/day to $150/day.

Catch: cache hit rates are entirely determined by your prompt architecture. Changing one byte at the start of a cached prefix can invalidate the whole block, depending on the provider. If you're designing for cacheability, put the stable content first and the variable content last — cache-friendly prompt ordering is free money.

The fourth concept: reasoning tokens

"Reasoning" or "thinking" models bill the tokens the model uses internally to think before answering — and these are charged at the output rate, even though you never see them directly. An agentic task that "looks" like a 500-token answer may have burned 4,000 hidden reasoning tokens billed at output price.

Practical rule: if your workload uses reasoning models, budget the total token count, not the visible answer length. This is the most common cause of "the dashboard says $40 but my bill says $160."

The fifth: batch API and tiered discounts

Several providers offer batch processing — non-urgent requests processed within hours — at roughly 50% off the standard rate. If your workload is offline (evals, data labeling, nightly summarization), batch pricing is the easiest discount you'll ever collect.

Providers also run volume tiers and committed-use discounts, but these only make sense once you know your baseline from list prices. Negotiate after you have a measured monthly spend, not before.

How to actually compare two models

Don't compare headline input prices. Do this instead:

Measure your workload's token profile. Log input vs. output tokens per request type for a week. Most teams are shocked by their real output share.
Compute a blended rate. The convention is 80% input / 20% output, but compute your blend — an agent workload might be 30/70.
Check the official price against the catalog. Aggregator catalogs (like the one this site snapshots daily) can lag provider announcements by hours to days. For flagship models, cross-check against the provider's own pricing page before committing spend — we do this for 77 flagships on the official prices page.
Re-run the comparison quarterly. Prices only move in one direction, and it's down. A model that was cheapest in Q1 may sit mid-table by Q3 as newer models undercut it. The price changes page shows the daily drift.

The honest summary

LLM pricing is five numbers, not one: input, output, cached input, reasoning, and batch. The developers who overspend are the ones optimizing the input number while their bill is dominated by output and reasoning tokens they never modeled. Price the workload — your real token mix, your real cache hit rate — and re-check it every quarter. The market moves fast; your model choice should move with it.

Next: how to cut the bill for the model you already use →

By the LLMPrices editorial team · October 2026. All pricing guides →