Blog / Model watch

LLM API Pricing Comparison: 5 Traps in Per-Million-Token Prices

2026-10-22cdnping editors8 min read

When you compare LLM API pricing, don't just sort models by "price per million tokens." Split input price from output price, work out the cost per request using your own input-to-output ratio, then factor in caching, batching, retries, and tokenizer differences. For the same set of models, a different workload can completely reverse which one is cheap and which one is expensive.

We start with a price snapshot you can check yourself, to show how far unit prices actually spread. Then we cover the 5 places where people most often get the math wrong, and finish with a checklist you can fill in as-is.

#How far apart are LLM API unit prices right now?

As a reference we use the public OpenRouter model catalog, which cdnping fetched on 2026-10-17. The catalog had 376 models that day. cdnping closely tracks 16 of the latest models (counting different versions of the same model) from 8 vendors, and the table below shows their catalog prices (USD per million tokens). We leave out model names and look only at ranges and ratios, because specific models get replaced every few weeks.

Two things stand out. First, the highest and lowest input prices differ by about 40x, so picking the right tier matters more than shaving a few cents within a tier. Second, the model whose output price is about 39 times its input price sits in the lower range on input but near the top on output. Judged by input price alone it looks like a bargain, but if your task produces a lot of output, it isn't cheap.

These are OpenRouter catalog prices. They don't necessarily match the vendors' own websites, and they don't include each vendor's caching, batch, or other discounts. Check the official pricing pages before you make a final comparison. Live prices and availability are on cdnping's model monitor, and price changes are recorded line by line in official site changes.

#Trap 1: Why do input and output prices have to be calculated separately?

In the snapshot, all 16 models price input and output separately, and output is always more expensive than input. Comparing on just one of the numbers, or simply adding the two, gives a distorted picture.

The right way is to calculate per request:

cost per request = input tokens × input price / 1,000,000
                 + output tokens × output price / 1,000,000

Here is an example using three real price points from the snapshot (model names withheld, called A, B, and C) and two assumed workloads. The workloads are illustrative, not statistics.

• A: input 0.304, output 11.936
• B: input 4, output 12
• C: input 2, output 10

For read-heavy, write-light tasks like retrieval Q&A, A costs only about a third of C. Switch to a read-light, write-heavy generation task and A ends up more expensive than C. So the first step isn't looking up prices. It's measuring how much of your requests is input and how much is output.

#Trap 2: Why look at the output-to-input price ratio on its own?

The output-to-input price ratio determines which kinds of tasks a model is friendly to. For models in the 3x to 5x range, the cost ranking is fairly stable across both kinds of tasks. For models with a very high ratio, cost is highly sensitive to output length.

One kind of output is often overlooked: a reasoning model's thinking. Many reasoning models count the thinking part as output tokens. The UI may not show it, but the bill will. Whether it is billed and how is governed by each vendor's official documentation. When comparing reasoning models, send real requests and check how many output tokens the returned usage field reports, rather than estimating from the length of the final answer.

#Trap 3: How do context limits and long-context pricing affect cost?

The context limit itself costs nothing, but it determines whether you need extra engineering. Most models in the snapshot top out around 1 million tokens, and a few at about 260K. If your task needs to fit an entire code repository or a long document, a model with a smaller limit forces you to chunk and retrieve, and the extra requests and repeated input all cost money.

Also, some vendors charge a higher unit price for requests above a certain length. These tiered prices usually don't show up in aggregated tables. Look for "long context" or similar wording on the official pricing page.

#Trap 4: How do you factor in caching and batch discounts?

Prompt caching bills the repeated prefix of your input at a lower price, which matters a lot when you have a long system prompt or keep asking questions about the same document. Batch APIs trade a longer completion time for a discount, which suits offline jobs.

The size of the discount, the minimum cacheable length, and whether cache writes cost extra all differ by vendor, so we don't list specific numbers here. As a method, you can handle it like this:

effective input price = cache hit rate × cache read price
                      + (1 - cache hit rate) × standard input price
                      + extra cost of cache writes (amortized over write count)

Measure the hit rate from real logs rather than assuming an ideal value. For Claude's caching rules and common mistakes, see How to use Claude API prompt caching to actually save money.

#Trap 5: Why does the same text produce different token counts on different models?

Each model has its own tokenizer, and the same passage of Chinese text can be split into noticeably different numbers of tokens. If a cheaper-per-token model needs more tokens for the same content, the savings disappear. The differences are especially large for Chinese, code, and JSON.

The most direct approach is to test with your own real samples. Here is a generic way to do it that works with any OpenAI-compatible endpoint. Swap in the base URL, API key, and model name you want to compare:

# Prepare a representative real input and save it as sample.txt
TEXT=$(python3 -c 'import json,sys;print(json.dumps(open("sample.txt").read()))')

curl -s "$BASE_URL/v1/chat/completions" \
  -H "Authorization: Bearer $API_KEY" \
  -H "Content-Type: application/json" \
  -d "{\"model\":\"$MODEL\",\"max_tokens\":1,\"messages\":[{\"role\":\"user\",\"content\":$TEXT}]}" \
  | python3 -c 'import json,sys;print(json.load(sys.stdin)["usage"])'

With max_tokens set to 1, you pay almost only for input (a few reasoning models have a minimum for this parameter or use a different parameter name; adjust according to their docs if you get an error). Run it against each candidate model, note the prompt_tokens, and compare "token count × unit price" rather than unit price alone. If the token counts on your bill don't match your local estimates, work through the steps in AI API bill doesn't match: how tokens are counted and how to verify them.

#What else ends up on the bill besides unit price?

#Failures and retries

When a request fails and you retry, you usually pay again for the input that was already sent. Availability for the same model varies across inference providers. In cdnping's 2026-10-17 OpenRouter snapshot, a single model's 36 provider routes had 1-day availability ranging from about 88% to 100%. However low a route's unit price is, it still has to be multiplied by the amplification factor from retries. For detailed data, see How much can uptime differ when you switch OpenRouter providers for the same model. Probe results for the API endpoints themselves are on the API status page.

#Quantization

Under the same model name, different providers may run different precisions such as fp8 or fp4. If the cheaper provider uses a lower-precision version, output quality may differ, leading to rework or extra conversation turns. To learn how to spot this, see Is the model getting dumber, or did the provider change? Inference providers and fp8/fp4 quantization.

#Different billing units

Some services bill per token, while others use monthly subscriptions or custom quota units. For example, AGI Plan (AGI Plan is a commercial partner of cdnping) meters usage in CU: 1 CU equals 1,000 output tokens of a baseline model, and pay-as-you-go is 1 yuan = 500 CU (the yuan is the Chinese currency, CNY). The exact conversion is as shown at agiplan.dev/pricing. When comparing services like this, again convert to "how much does one typical request cost you," rather than comparing a plan price directly against a per-million-token price.

#A comparison checklist you can follow directly

After going through this table, the usual conclusion isn't "pick the cheapest model" but "tier by task": cheap models for retrieval, classification, and formatting, and expensive ones for long-chain reasoning and complex edits. For how to split this up, see How to build multi-model routing: route by task to cut LLM costs without a visible quality drop.

#How do you find out when prices change?

Many of the price tables you find in search results are months out of date and disagree with each other: after a vendor changes prices, few people update the copies. Rather than bookmarking a table, it's more reliable to watch the source. cdnping's official site changes monitors multiple official pricing pages and changelogs and records additions and removals line by line, while the model monitor automatically records listings, delistings, and price changes on OpenRouter. For how to use the three together, see How to find out right away when LLM API prices change.

The price snapshot in this article comes from cdnping's 2026-10-17 fetch of OpenRouter's public API. cdnping only began collecting data on that day, so the history is short. For unit prices, rely on the latest numbers on the official pricing pages.