✓ Multiplicative, not additive· Caching → Batch → Committed· report an issue →
Prompt caching, the Batch API and a committed-spend discount each cut your bill — but stacked naively they seem to save more than you spend. They compound: batch discounts the already-cheaper cached price, and the committed discount comes off what is left. This prices the true blended cost per million tokens, the real monthly bill, and a waterfall of where every dollar of saving actually comes from.
—
stacked / mo
—list price / mo
—total savings
—blended $/1M
Savings waterfall — each lever acts on what the last one left
Start at list price, apply prompt caching to the input side, then the Batch API to the batched share, then the committed discount to the whole remaining bill. The step column is what that lever alone removed; the running column is what is left.
Stage
Saved this step
Running monthly
Additive vs multiplicative — the trap
Adding the three headline discounts overstates the saving, sometimes past 100%. The real stack multiplies what you keep at each step. This shows the gap for your numbers.
Method
Claimed savings
Monthly
Three discounts rarely make it free
Every LLM cost-cutting guide lists the same levers — cache your prompts, batch what can wait, commit to spend for a volume discount — and every one of them quotes a headline percentage. The mistake is stacking those percentages by adding them. Discounts do not add, they compound: each one only gets to work on the money the previous one left behind. A 90% cache discount that only touches the input side, a 50% batch discount on the share of traffic that tolerates latency, and a 15% committed discount on the invoice do not sum to 155% off — they multiply down to a real number that is always less impressive than the sum and always more than zero. This calculator applies them in the order they happen — caching at request time, batch at submission, committed at billing — and walks the bill down a waterfall so you can see what each lever actually removed rather than what its brochure promised. It also spells out the catches the headline numbers hide: caching only discounts input tokens, so an output-heavy workload barely feels it; batch only applies to traffic that can wait, so an interactive product routes little of its volume through it; and some providers will not let you cache and batch the same request at all. Price each lever on its own with the prompt caching calculator, the batch API calculator and the committed-spend calculator — then come here to see what they really do together, and compare the result against the full cost optimization calculator.
List price starts from your token split: input tokens times input price plus output tokens times output price, divided by a million, times requests per month. Prompt caching acts on the input side only — the effective input price becomes the input price times one minus the cacheable-and-reused fraction times the cache read discount, so if 70% of input is reused and cached reads are 90% cheaper, you save 63% of the input cost while output stays at full price. The Batch API discount applies to the batched share of volume: the batched portion of the post-cache bill is multiplied by one minus the batch discount, the rest is untouched, because real-time traffic cannot batch. Finally the committed-spend discount is a flat multiplier on the whole remaining bill. The stacked total is list price run through all three in that order; the blended cost per million tokens is that total divided by total tokens processed. The additive-versus-multiplicative table contrasts the honest compounded saving with the naive sum of headline percentages, which can exceed 100% and is always wrong. Caching touches input only, batch touches the waiting-tolerant share only, and some providers block caching on batched requests — so treat the combined figure as the best case for traffic where all three genuinely apply.
Frequently asked questions
Why do stacked LLM savings not simply add up?
Each lever discounts what the last one left, so they compound instead of adding. Keep 60% after caching, 50% of that after batch, 80% of that after the committed discount, and you are at 24% of list — a 76% saving, not the 110% you get by adding 40, 50 and 20. You can never save more than you spend, which is why summing headline percentages is always wrong.
Does prompt caching only discount input tokens?
Yes. Caching reuses a prefix of tokens you already sent; output is generated fresh every time and is never cached. So an input-heavy RAG workload feels caching hard, while an output-heavy drafting workload barely notices it. This tool applies the cache discount to the input portion alone and to the reused fraction only.
Does the order of discounts change the total?
For flat percentages, no — multiplication is commutative, so 0.6 × 0.5 × 0.8 is the same in any order. Order only changes the story the waterfall tells. It starts to matter when a discount is not flat — a committed tier that unlocks above a threshold, or a cache write premium — which this tool flags rather than models exactly.
Can I really stack all three in production?
Caching and committed discounts stack cleanly. The Batch API is the catch: batch jobs are asynchronous, so only latency-tolerant traffic can use them, and some providers do not offer caching on batched requests. Set the batch share below 100% to model the split, and verify your provider allows the levers together before promising finance the combined number.