GintiCalcEvery calculation

TokenLedger

LLM Workload Cost Calculator

Price a real workload — then see what caching and routing actually save before you refactor anything.

Monthly LLM cost and what caching plus routing saves

Two levers cut a token bill: prompt caching discounts repeated input, and routing simple traffic to a cheaper model. Rows use 2,000 input and 500 output tokens per request at $3 and $15 per million, a 90% cache discount, and a cheap model at 20% of list.

Requests/monthCache hit rateRouted to cheap modelBaselineOptimisedMonthly savingAnnual
1 M0%0%$13,500$13,500$0 (0.0%)$0
1 M50%0%$13,500$10,800$2,700 (20.0%)$32,400
1 M50%30%$13,500$8,208$5,292 (39.2%)$63,504
1 M80%50%$13,500$5,508$7,992 (59.2%)$95,904
10 M50%30%$135,000$82,080$52,920 (39.2%)$635,040

Caching only discounts input tokens, so a workload dominated by long outputs benefits far less than these rows suggest. Token and instance prices move constantly; treat the rates here as illustrative and put your own contracted rates into the calculator.

An LLM workload cost calculator prices a production language-model deployment from real usage figures and then quantifies the two optimizations that reliably reduce that bill: prompt caching and model routing. Simple token-multiplication calculators are commodity content and stop at the first number. The useful question is not what a million tokens cost — it is what your specific traffic costs today, and how much of that you can remove without changing the product.

The baseline is straightforward: monthly requests multiplied by input and output tokens per request, priced at the separate input and output rates providers charge. Two details matter here and are frequently missed. Output tokens usually cost several times more per token than input tokens, but production workloads typically send far more input than they generate output, so the input side often dominates total spend despite the lower unit price — which is precisely why caching is so effective. The calculator then layers the optimizations. Prompt caching discounts the repeated prefix of your prompts, so the discount applies to the cached share of input tokens only, not to output and not to cache misses. Model routing sends a share of traffic to a smaller, cheaper model, priced as a percentage of the main model's cost. Applying both gives an optimized monthly figure, and the difference from baseline becomes the monthly and annual saving.

The reason the source research calls this the competitive anchor of an AI-cost cluster is that the inputs should come from your provider's usage export rather than from estimates. Teams consistently guess their input-to-output ratio wrong, and the ratio drives which optimization pays. A workload with long, stable system prompts and short answers is a caching goldmine; one with short prompts and long generations barely benefits from caching and needs routing or output-length control instead. Running the calculator with measured numbers tells you which lever to pull before anyone refactors code. Two caveats: caching only helps where the prompt prefix genuinely repeats and stays within the provider's cache window, and routing only works if the cheaper model actually holds quality on the traffic you send it — a routed request that fails and gets retried on the expensive model costs more than never routing it. Validate quality on a real sample before assuming the saving. This prices API tokens only, excluding infrastructure, vector search, and engineering time.

Input usually dominates, even though output costs more per token

Output tokens are typically priced 3-5× higher than input, which leads teams to assume output drives the bill. In practice most production workloads send far more input than they generate output — long system prompts, retrieved context, conversation history — so the input side often accounts for the majority of spend. That's exactly why prompt caching, which discounts repeated input, is usually the single biggest lever.

Routing only saves if quality holds

Sending 30% of traffic to a model costing 20% as much looks like an easy win, but a routed request that produces a bad answer and gets retried on the expensive model costs more than never routing it — plus the quality damage. Route on measured task difficulty, validate on a real sample, and monitor the fallback rate; the saving is only real if the cheap model actually finishes the job.

Frequently asked questions

1M requests/month at 1,200 input and 400 output tokens, $3/$15 per million — what does that cost, and what can I save?

That's 1,200M input tokens ($3,600) and 400M output ($6,000) = $9,600/month at list. A 40% cache hit rate at 90% off input saves about $1,296; routing 30% of the remaining traffic to a model at 20% of cost saves roughly a further $2,000 — landing near $6,300/month, about 34% off.

Should I optimize caching or routing first?

Check your input-to-output ratio. Long, repeated prompts with short answers favour caching, which is also lower-risk because it doesn't change which model answers. Short prompts with long generations barely benefit from caching — those workloads need routing or tighter output limits. Measure before refactoring.

Why do my estimates never match my actual bill?

Almost always because the assumed token counts are wrong. Retrieved context, system prompts, conversation history, and tool results inflate input far beyond what teams estimate. Pull the real input/output figures from your provider's usage export — that single correction usually explains most of the gap.

How is this different from the AI feature gross margin calculator?

This one prices the workload itself and the infrastructure-side savings available on it. The gross margin calculator takes a cost-to-serve figure and compares it against what you charge per user to report profitability. Use this to establish and reduce your true cost, then that to check whether your pricing clears it.

Related Developer calculators

You might also like

Last updated: August 10, 2026