Why "stack five discounts" isn't as simple as adding percentages
Almost every list of LLM cost-cutting tips quotes each lever's headline discount and implies they add up: batch at 50% off plus caching at up to 90% off cached reads looks, at a glance, like "140% cheaper." That's not how stacking works. Each lever only ever discounts whatever dollars the levers before it left standing, never the original baseline.
The calculator below runs the same five levers as an ordered waterfall: context trimming, then output discipline, then prompt caching, then model routing, then batch. Each one's savings are computed against the running remainder, not the starting bill, which is the only arithmetic that reconciles with an invoice at the end of the month.
The order the levers run in, and why it isn't arbitrary
Context trimming and output discipline go first because they change how many tokens exist at all, before anything downstream gets priced. Output discipline in particular is usually the single biggest lever on the page: output tokens are priced several times higher than input tokens on every model in this calculator, so a modest cut to response length routinely outweighs a much larger-looking percentage on a smaller cost base.
Prompt caching, model routing, and batch come next, in that order, because each one reprices whatever token volume and dollar cost the earlier levers left. Caching changes the per-token rate on the cacheable share of input, routing reprices a share of what's left at a different model's rates, and batch discounts whatever remains after both. Running them in a different order isn't cosmetic; it changes every downstream dollar figure.
Prompt caching can cost you money: the exact break-even
A cache hit is cheap: it bills at roughly a tenth of the base input rate on every provider in this calculator. But a cache miss isn't free either. It bills as a cache WRITE, at a premium over the base input rate (1.25x for a 5-minute entry, 2x for a 1-hour entry, on Anthropic's published rates). Below a certain hit rate, the write premium on the misses outweighs the discount on the hits, and caching costs more than never caching at all.
The exact break-even is where the blended rate equals the plain, uncached rate: hit × 0.10 + (1 − hit) × writeMult = 1, solved for hit. At the 1.25x 5-minute write multiplier that's (1.25 − 1) / (1.25 − 0.10) ≈ 21.7%. At the 2x 1-hour write multiplier that's (2 − 1) / (2 − 0.10) ≈ 52.6%. Drag the cache-hit-rate slider below that line for either TTL and the calculator reports a real, negative saving in brick, the same way this site's commitment-discount calculator already treats an under-utilized Reserved Instance.