The Trick Behind LLM Gateway Discounts: Advertised 50%, Actual 28%

"50% off" "up to 80% off" — almost every LLM gateway that undercuts the official API slaps a discount badge like this somewhere prominent. The number is real, but it's not the number you save on your bill. The problem lies in the anchor used to calculate the discount: the badge only looks at input and output prices, while in a real coding session, most of the money is spent elsewhere.

Where the money goes in a real session

Take a two-hour Claude Code session on a medium-sized code repository: dozens of requests, routine context reuse. Agentic coding tools resend the system prompt, project context, and conversation history with every request; the provider caches that prefix and bills the repeated portion at a much cheaper "cache read" rate. A typical token breakdown looks like this:

Component	Token count
Cache read	5,000,000
Fresh input	250,000
Output	100,000
Cache write	350,000

Cache reads account for 88% of the token volume. Long sessions push this ratio above 95%, but regardless of the exact proportion, this structure holds for any agentic tool.

What are the four cache-related token billing categories

Modern LLM APIs split a request's tokens into four categories, each priced separately. Fresh input is prompt content the model hasn't seen before, billed at the standard input rate. Cache write is the act of writing a prefix (system prompt, project context, conversation history) into the provider's cache for the first time, typically costing more than regular input — Anthropic charges 1.25× the input price (5-minute TTL), and OpenAI has adopted a similar mechanism since GPT-5.6. Cache read is the portion of subsequent requests that hit the same cache and skip recomputation, priced far below input — roughly one-tenth of input for the Claude series. Output is new tokens generated by the model, priced the highest. The relative difference between these four unit prices can exceed tenfold, so the token count structure heavily influences the final bill — which is exactly why a discount badge that only looks at input and output prices is misleading.

Where the money actually flows

Using Anthropic's published prices (input $10, output $50, cache read $1, cache write $12.50 per million tokens), this session costs $16.88:

Item	Cost	Share of bill
Cache read	$5.00	29.6%
Cache write	$4.38	25.9%
Fresh input	$2.50	14.8%
Output	$5.00	29.6%

Cache reads account for 88% of the token volume but only about 30% of the money — because the cache read unit price is cheap. But add in cache writes, and cache pricing together accounts for 56% of the bill. Input and output — the two numbers every discount badge is built on — make up only the remaining 44%.

In other words, a discount that only covers input and output actually discounts less than half of what you pay.

Why cache reads are "cheap" yet still a big expense

The cache read unit price is low, but agentic coding sessions resend nearly identical prefixes every turn, hitting the cache extremely frequently, and the accumulated token volume far exceeds fresh input. A 90% discount on unit price multiplied by 20× the volume is still a substantial expense. Conversely, cache writes occur only when a prefix first appears or is rewritten after cache expiry; while the volume is smaller than cache reads, the unit price is 1.25× the input price, so by dollar amount it often rivals output. Put these two lines together and the caching system can account for about half of a typical session's bill. To genuinely save money on a discount, a provider must offer comparable reductions across all four lines — especially without passing through cache writes at full price.

Four tricks that make the badge bigger than the bill

None of these are lies — just true statements about the wrong number.

The discount applies only to input and output. Cache reads are billed at the provider's list price, or with only a tiny discount. The badge says 50%, but the cache line gives you 0–20%.

Cache writes aren't mentioned at all. Anthropic charges 1.25× the input price for 5-minute cache writes; OpenAI has done the same since GPT-5.6. If the gateway passes this through at list price, a quarter of your session is billed at full price.

"Up to X% off" is calculated on the cheapest line. It might be the output price of some model, or some promotional tier. The rest of the catalog falls well below that badge number.

Cache pricing isn't on the pricing page. You only discover it on the invoice. If a provider's price table has only two columns, ask where the other two went.

The marketing logic of "up to X% off"

"Up-to" discounts are usually calculated from the cheapest cell in the entire catalog — say, the output price of an obscure model in a limited-time promo, or a first-deposit tier available only to new users. This means the percentage on the badge is an upper bound, not the expected value in a user's actual scenario. For commonly used models (like Claude Sonnet or GPT-5 class) and typical agentic usage, the real savings are often less than half the advertised figure. The way to judge is simple: treat the badge number as "the most you could save in the best case," then multiply and sum line by line according to your own usage mix — the gap between the two is the fluff in the marketing.

A comparison experiment with three providers

The same session, three hypothetical providers:

Provider	Input/Output	Cache read	Cache write	Session cost	Real discount
Official API	—	—	—	$16.88	—
"50% off," cache read at 20% off, cache write full price	50%	20%	0%	$12.13	28%
"50% off," both cache lines at 20% off	50%	20%	20%	$11.25	33%
All four prices uniformly at 35% off	35%	35%	35%	$10.97	35%

A uniform 35% off beat the "50%" badge on this session — not because 35 is bigger than 50, but because it applies to the 56% of the bill the badge ignores.

To be fair, if a provider discounts both cache lines by more than 23%, its "50%" would break even with the uniform 35% off. That's exactly the point: the two cache lines determine the outcome, and the badge doesn't tell you what they are.

Verify any provider in three minutes

1. Collect the four unit prices for the model you're using: cache read, input, output, cache write. If a pricing page is missing one, ask support; if support doesn't know, that's your answer.
2. Write down your usage breakdown. Claude Code prints it under /usage (input, output, cache read, cache write), and other tools log it too. If you have nothing, use the table above.
3. Multiply and sum. Four multiplications and one addition, per provider. Compare totals, not badges.

Before topping up, it's worth asking four questions:

• Do cache reads and output get the same discount?
• How are cache writes charged?
• Is the "up to" number the best case or the typical case?
• Can I see official prices and your prices side by side?

Transparency is the real competitive edge

The subtlety here is that discounts themselves aren't wrong — what's wrong is using an incomplete framing to create an illusion. When a provider shows official prices side by side with its own and applies a uniform multiplier across all four prices (including cache), price comparison actually means something. For users, rather than chasing the percentage on a badge, it's better to learn to read those four unit prices — this three-minute method gets you closer to what you'll actually save than any "up to 80% off."

How to read a pricing page

A complete LLM gateway pricing page should at minimum display the official and gateway prices side by side for all four token categories: input, output, cache read, and cache write, and note whether a uniform multiplier applies to all four. If the pricing page has only two columns (input, output), you can basically conclude that the two cache lines are either passed through at official prices or hidden in the small print of "subject to invoice." A more reliable approach is to ask the provider for a side-by-side comparison table, or an API that exports itemized billing, so users can verify their actual spending for a given week line by line instead of making decisions based on a badge number.