How to reduce LLM API costs
Four levers, in this order: prompt caching, batch processing, output length, then model tier. The first three change what you pay without changing what your product does. The fourth is the only one that risks output quality, which is why it belongs last rather than first.
The instinct on seeing a large LLM invoice is to look for a cheaper model. That is usually the wrong first move: it is the one option that can make your product worse, and on most workloads it is not even the biggest saving available.
The four levers, priced on one workload
A chat workload of 500,000 calls a month at 6,000 input and 700 output tokens each, running on Claude Opus 5, costs $23,750 a month at list rates. Here is what each lever takes off that same bill.
| Lever | Saves / month | % of bill | What it costs you |
|---|---|---|---|
| Prompt caching 27 of 60 models offer it, median 90% off input. | $7,088 | 30% | None. Same model, same output. |
| Batch processing 18 models offer roughly 50% off input and output. | $11,875 | 50% | Latency only. Hours instead of seconds. |
| Halving output length Needs no provider feature, works on every model. | $4,375 | 18% | Product change. Shorter answers. |
| Dropping to Claude Haiku 4.5 5.0x cheaper on a blended rate. | $19,000 | 80% | Quality risk. Needs evaluation. |
Two things to read out of that table. The model switch is the largest single number, and it is also the only row with real risk attached. And caching plus batching together, on a workload that can take both, get most of the way there with none of that risk. That is the whole argument for the ordering.
Lever 1: prompt caching
Providers discount input tokens they have processed for you recently. 27 of the 60 models tracked here publish a cached rate, at a median around 90% off, and on Claude Opus 5 specifically it is $0.50 against $5.00 standard.
The catch is that caching matches on a prefix, so it only works if your prompt is ordered for it. A timestamp or a user ID near the top of a system prompt invalidates everything after it and can silently take a workload from a 90% hit rate to zero. Full mechanics, including the ordering rules and what a realistic hit rate looks like, in the prompt caching guide.
Lever 2: batch processing
18 models offer roughly 50% off both input and output for work submitted asynchronously. Unlike caching, it discounts output too, which makes it the bigger lever for generation-heavy jobs. The only requirement is that nobody is waiting: bulk classification, offline summarisation, dataset labelling, nightly enrichment and evaluation runs all qualify. See batch API pricing.
Lever 3: output length
Output costs several times what input does on essentially every model, so it is the half of the bill worth attacking, and it needs no provider feature at all. Setting a max output limit, asking for the answer without the preamble, and returning structured data instead of prose all do the same job. On the example above, halving output length saves $4,375 a month.
This one is also the most commonly missed when comparing models. A cheaper model that answers at twice the length has spent its price advantage before you have evaluated a single response for quality.
Lever 4: model tier
Last, not first. The saving is real and often large: the same workload on Claude Haiku 4.5 instead of Claude Opus 5 costs $4,750 against $23,750. But this is the only lever where the number on the calculator is not the whole story, because a model that fails more often shifts cost somewhere the API bill does not show.
Treat the calculated saving as the budget available for evaluating the swap, not as the conclusion. choosing an LLM by cost covers how to make that call, and the model switching savings calculator puts a figure on it for your own volume.
The lever nobody lists: call count
All four levers above optimise the price of a call. The variable that most often blows a budget is how many calls happen per user action, and it is not on any rate card. An agent that averages six model calls per request costs six times what a single call does; add retries, a reranking pass and a self-critique step and the multiplier grows again.
Before tuning rates, count the calls. It is common to find a feature making three model calls where one would do, and removing two of them beats every discount on this page combined.
Cost reduction questions
How can I reduce LLM API costs?
Four levers, in order of effect for most workloads: enable prompt caching and order prompts so the stable part comes first; move anything latency-tolerant to a batch API; cap output length, since output is the expensive half; and only then consider a cheaper model tier. The first three carry no quality risk at all, which is why they come first.
How much can prompt caching save?
On the 500,000-call example on this page, $7,088 a month, or 30% of the bill, at a 75% cacheable prefix and a 70% hit rate. The median discount across the 27 models that publish one is about 90% off input.
Is switching to a cheaper model the best way to save money?
Usually not the first thing to try, despite being the most obvious. It is the only lever that risks output quality, and a cheaper model that needs two attempts or produces output someone corrects costs more than the model that got it right — none of which appears on the API bill. Exhaust caching, batching and output limits first.
Do caching and batch discounts stack?
On some providers, and where they do they multiply rather than add: half of a tenth is a twentieth. Check the provider's documentation, then size each lever separately rather than guessing at the combined figure.
What is the single biggest cause of an unexpected LLM bill?
Call volume per user action, not per-call cost. An agent loop averaging six model calls per user action costs six times what a single call does, and retries, reranking passes and self-critique steps multiply it further without ever showing up in a per-call estimate. Count the calls before optimising the rate.