Question 1

Why do stacked LLM savings not simply add up?

Accepted Answer

Because each lever discounts what is left after the previous one, not the original price — the savings compound, they do not add. If prompt caching cuts your input cost by 40%, the Batch API takes its 50% off the already-cheaper cached number, and a 20% committed-spend discount then comes off what remains after both. Stack those naively by adding — 40 plus 50 plus 20 — and you would claim 110% savings, which is nonsense; you cannot save more than you spend. The correct arithmetic is multiplicative: you keep 60% after caching, then 50% of that, then 80% of that, which is 0.6 times 0.5 times 0.8, or 24% of the original — a 76% saving, not 110%. This is why pricing each lever in isolation and summing overstates the total, and it is exactly the mistake this calculator exists to prevent. It applies the levers in a defined order, each acting on the running balance, and shows the real combined effect rather than an impossible sum. The intuition to keep: three big-sounding discounts rarely make things free, because each one is fighting over a smaller and smaller pie.

Question 2

Does prompt caching only discount the input tokens?

Accepted Answer

Yes — prompt caching discounts the input side only, because it works by reusing a prefix of tokens you have already sent, and output tokens are generated fresh every time so they are never cached. That distinction matters a lot for how much caching can save you. If your workload is input-heavy — a long system prompt, a big retrieved context, a fixed few-shot block repeated across requests — a large share of your bill is input tokens and caching bites hard. If your workload is output-heavy — short prompts producing long generations, like drafting or code — most of your cost is output tokens that caching cannot touch, and the headline cache discount applies to a small slice of the bill. This calculator asks for your input and output token counts separately precisely so it can apply the cache discount to the input portion alone and leave the output portion at full price. It also asks what fraction of your input is actually cacheable and reused, because only the repeated prefix gets the discount — a fresh, unique prompt caches nothing. The result is a cache saving grounded in your real token split, not a flat percentage slapped on the whole bill.

Question 3

In what order should the discounts be applied, and does it change the total?

Accepted Answer

This calculator applies them in the order they occur in practice: prompt caching first, because it changes the per-token price at request time; then the Batch API, because batching discounts the whole request at submission; then the committed-spend or volume discount, because that is a contract-level reduction applied to your invoice at the end. The good news is that for simple percentage discounts, multiplication is commutative — 0.6 times 0.5 times 0.8 is the same number whatever order you multiply in — so the final total does not depend on the sequence. What the order changes is the story the waterfall tells: applying caching first shows how much the cache alone saved, then how much batch added on top of that, then what the committed discount scraped off the remainder, which mirrors how you would actually reason about layering them. Where order genuinely matters is when a discount is not a flat percentage — for example a committed-spend tier that only unlocks above a dollar threshold, or a cache write premium you pay before you earn read savings. This calculator uses flat percentages for clarity and flags those real-world wrinkles in its notes so you know when the clean multiplication stops being exact.

Question 4

Can I really stack all three discounts at once in production?

Accepted Answer

Sometimes, but not always, and that is the honest catch this calculator wants you to see before you bank the combined number. Prompt caching and a committed-spend discount stack cleanly — caching is a runtime feature and the committed discount is a billing arrangement, so they do not conflict. The friction is usually the Batch API, because batching trades latency for its discount: batch jobs are asynchronous and can take minutes to hours, so you can only route the share of your traffic that tolerates waiting. Real-time chat, an interactive agent, or anything a user is watching cannot go through batch, so the batch discount applies to a fraction of your volume, not all of it. There can also be feature-level incompatibilities — some providers do not offer prompt caching on batched requests, or the cache TTL is too short to survive a queued batch job — so the two biggest levers occasionally cannot both apply to the same request. This calculator lets you set the batch share below 100% to model that split, and treats the combined figure as a best case for the portion of traffic where all three genuinely apply. Verify each lever is available together on your provider before you promise finance the stacked saving.

Calculadora de pila de ahorros de LLM

Cascada de ahorro: cada palanca actúa sobre lo que quedó la última

Aditivo versus multiplicativo: la trampa

Tres descuentos rara vez lo hacen gratis

Cómo funciona esta calculadora

Preguntas frecuentes

¿Por qué los ahorros acumulados de LLM no simplemente se acumulan?

¿El almacenamiento en caché solo descuenta tokens de entrada?

¿El orden de los descuentos cambia el total?

¿Puedo realmente apilar los tres en producción?