How to Reduce Your LLM API Costs in 2026 (Without Losing Quality)

Most teams start cutting their AI bill in the wrong place. They shorten prompts, which is the smallest lever available, and never touch model routing, which is the largest. The levers that matter, ranked by what they actually save, are routing per task, caching your stable prefix, batching anything asynchronous, and only then trimming tokens. Applied together on a real workload, they compound to a 28x reduction.

This guide ranks the levers, shows the arithmetic on each, and starts with the one step almost everyone skips: finding out which lever your bill actually responds to.

First, run the diagnostic

Before you change anything, pull one week of usage and sum two numbers: total input tokens and total output tokens. That ratio decides your entire optimization strategy, and it is different for different products.

Here is why it matters. Take the same model, Claude Haiku 4.5 at $1 input and $5 output per million tokens, and two common workloads.

Same model, same rates, and the dominant side flips completely. On the classification workload, caching your input prefix is the big win. On the generation workload, caching is nearly irrelevant, because input is under 5% of the bill, and your leverage is entirely on the output side: capping max_tokens, controlling reasoning effort, and using a cheaper model.

Advice that ignores this is guesswork. Output is billed at 5x input on every Claude model, but which side dominates your bill depends on your token ratio, not the rate card. Get the ratio first, then pull the right lever.

The four levers, ranked

Lever 1: route by task (up to 41x)

The biggest saving available, and the one most teams never touch, because the model string was written once and never revisited.

Take a realistic pipeline, 10,000 calls a day with a 5,000 token system prompt including tool definitions and examples, 500 tokens of variable input, and a 300 token structured response. Same task, different model:

The reason this is safe is that quality saturates on most high-volume tasks. Extraction, classification, formatting, and routing are solved problems. A frontier model does not extract a date field 41 times better than a cheap one, because there is no better. You are paying for headroom the task cannot use.

The rule: cheap models for anything a machine reads, better models for anything a human reads. And route per task, not per app. A single product usually has both kinds of work in it.

Lever 2: cache your stable prefix (10x on the cached portion)

Every provider bills a repeated prompt prefix at a discount, and the discount is steep. Per Anthropic’s caching documentation, a cache read costs 0.1x the base input rate, a 90% saving. A 5-minute cache write costs 1.25x base input, and a 1-hour write costs 2x. These multipliers stack with the Batch API discount.

Run the breakeven and it is almost absurd. Write at 1.25x plus one read at 0.1x equals 1.35x, against 2.0x for sending the same content twice uncached. The 5-minute cache is profitable from the first hit. The 1-hour cache breaks even on the second. And the default 5-minute cache refreshes at no extra cost each time it is used, so steady traffic keeps it warm for free.

On the workload above, caching the 5,000 token prefix cuts monthly input cost from $1,650 to $300 on Haiku 4.5, a 5.5x reduction on the input side with zero quality change.

Three things break caching, and all of them fail silently.

Your prompt may be too short to cache at all. There is a minimum cacheable prefix length, and it is model-specific and larger than most people assume:

Note the trap in the last row. Haiku 4.5, the model people reach for precisely because it is cheap and high volume, has the highest threshold on the list. A 2,000 token system prompt that caches happily on Sonnet 5 will not cache at all on Haiku 4.5. Anthropic’s docs are explicit that shorter prompts are processed without caching and no error is returned. Minimums can also differ by platform, so check your provider’s documentation for the model you actually run.

A changing prefix. The cache requires a byte-identical prefix, and cache writes happen only at your breakpoint. One timestamp, session ID, or user name at or before that breakpoint means the hash never matches and you pay for a fresh write on every request while never getting a read. Order it static first, dynamic last, and place the breakpoint on the last block that stays identical across requests.

Configuration changes you did not think of as prompt changes. Changing the reasoning effort setting or the thinking configuration invalidates cached message blocks. So does toggling tools, images, or web search. If you are tuning effort down for cost, expect a cache reset when you do.

The fix for all three is verification, not assumption. Check the usage fields on your responses: if both cache_creation_input_tokens and cache_read_input_tokens come back 0, nothing cached. Target a 60 to 80% hit rate on a stable-prefix workload. One useful bonus: cache hits are not counted against your rate limits, so good caching buys you headroom as well as savings.

Lever 3: batch anything asynchronous (2x)

Anthropic’s Batch API takes 50% off both input and output, processing within 24 hours, and the discount stacks with prompt caching.

The qualifying test is simple: is a human waiting on this response right now? If not, batch it. Nightly enrichment, bulk classification, document processing, eval runs, and content pipelines all qualify. Most teams run these synchronously purely out of habit and pay double for latency nobody needed.

Lever 4: trim tokens (marginal)

The lever everyone starts with, and the smallest one. It is still worth doing, but do it in the right order.

Set max_tokens deliberately rather than defensively. Cut few-shot examples to the minimum that holds quality, since every example bills on every call forever. Delete accumulated instructions: most production system prompts are scar tissue, one line added per bug, and nobody ever removes any.

And on newer Claude models, check your reasoning settings. Adaptive thinking is on by default on Sonnet 5 at high effort, and thinking tokens bill at output rates while the thinking field returns empty by default. Setting effort to low on classification-type work is a large saving that looks like a token trim. The full mechanics are in what actually changed on the Sonnet 5 bill.

What it looks like compounded

The levers multiply. Same workload, 300,000 calls a month, applied in order:

28x, with no quality loss on a task where quality had already saturated.

Methodology: rates are Anthropic’s published list prices. The workload is 300,000 monthly calls at 5,000 stable input tokens, 500 variable input tokens, and 300 output tokens. The 5,000 token prefix is deliberately above Haiku 4.5’s 4,096 token cache minimum, and the cache figure assumes a warm prefix with write costs amortized across high volume. Your numbers will differ, which is the point of running the diagnostic first.

Four ways the bill grows on its own

Optimization is not one-time. These are the leaks that reopen after you have closed them.

A floating model alias. Model strings come in two shapes: a dated snapshot and a floating alias. The alias moves when the provider ships a new snapshot. Your code did not change, but the model behind it did, along with its tokenizer, its default reasoning behavior, and possibly its cache minimum. Pin the dated snapshot in production and promote new versions when your evals say so, not when the provider ships.

A new tokenizer counting the same text differently. Anthropic’s newer models produce roughly 30% more tokens for identical text. The rate held, the count did not. Re-measure your real prompts after any model change rather than reusing old token counts.

Retries billing as full calls. Invalid JSON, a truncated response, a timeout. Every retry is a complete charge. If your real calls-per-request ratio is 1.4 and you budgeted 1.0, you are 40% over on a line nobody tracks. Log it.

Introductory pricing expiring. Claude Sonnet 5 runs at $2/$10 per million tokens through August 31, 2026, then moves to $3/$15 on September 1. Any forecast built on the intro rate is already wrong for the autumn.

The measurement habit that holds it together

Every lever above degrades silently if you stop watching. Three numbers, logged per task, catch all of it:

1. Tokens per request, input and output separately. Catches tokenizer changes and prompt creep.
2. Cache hit rate, from the usage fields on your responses. Catches a broken or undersized prefix, which is invisible otherwise.
3. Cost per completed task, not cost per token. The only number that survives a model swap, a tokenizer change, and a price increase all at once.

That third one is the whole discipline in a phrase. Two models at the same per-token rate can bill you 30% apart on the identical job. The rate card is not the invoice.

One caution before you downgrade anything: a cheaper model still returns a confident, plausible answer when it is wrong. Nothing errors. Build a small evaluation set and run it before and after each change, so the quality cost of a saving is a number you can see rather than a surprise your users find first. Cost optimization without evaluation is not optimization, it is a gamble with a delayed result.

Where a gateway fits

Look at what lever 1 actually requires. To route per task you need several models across more than one provider, which normally means separate accounts, keys, SDKs, billing, and failure modes before you save a dollar. That friction is exactly why most teams hardcode one model and eat the 41x on their highest-volume workload.

An AI API gateway removes it. One OpenAI compatible endpoint, every model behind it, one bill. Switching the model on a task becomes a string change instead of an integration project, which is also what makes benchmarking cheap: running your eval set across five models is a loop over five strings rather than five integrations. Measure across models, then route each task to the one that passed.

MixRoute is built for that loop: one OpenAI compatible API across 200+ models, automatic failover when a provider drops, and zero markup on provider pricing. Smart routing, which picks the best model per request on quality, cost, and latency, is coming.

FAQ

How can I reduce my LLM API costs? In priority order: route each task to the cheapest model that clears your quality bar, cache your stable prompt prefix, batch anything a human is not waiting on, and trim tokens last. On a typical high-volume workload these compound to roughly a 28x reduction. Start by measuring your input to output token ratio, because it determines which lever matters most for your product.

What is the biggest driver of AI API costs? Model choice, by a wide margin. The same task can cost $10,500 a month on a frontier model and $256 on a cheap one, because quality saturates early on high-volume work like extraction and classification. Prompt length is the smallest lever, despite being where most teams start.

Does prompt caching actually save money? Yes, when your prefix is stable, reused, and long enough to qualify. Cache reads cost 0.1x the base input rate on Anthropic, and a 5-minute cache write costs 1.25x, so it is profitable from the first hit. It fails when the prefix changes between calls, when the prompt is below the model’s minimum cacheable length, or when traffic is sparse enough that entries expire before reuse.

What is the minimum prompt size for Claude prompt caching? It varies by model. Claude Fable 5 and Mythos 5 need 512 tokens, Claude Opus 4.8 and the Sonnet 5, 4.6, and 4.5 line need 1,024, Opus 4.7 needs 2,048, and Opus 4.6, Opus 4.5, and Haiku 4.5 need 4,096. Prompts below the threshold are processed without caching and no error is returned, so check the usage fields to confirm a cache actually happened.

Why did my AI bill go up when I did not change anything? Common causes: a floating model alias that moved to a new snapshot, a new tokenizer counting the same text as more tokens, reasoning enabled by default and billed at output rates, retries billing as full calls, or introductory pricing expiring. None of these throw errors, which is why they go unnoticed.

Is it cheaper to use one model or several? Several, routed by task. A single model means you either overpay on bulk work or underdeliver on the work that matters. Different tasks have opposite requirements, and the cost spread between the right and wrong model on high-volume work can exceed 40x.

Should I use batch processing for AI API calls? Yes for anything asynchronous. Anthropic’s Batch API gives 50% off both input and output with processing inside 24 hours, and it stacks with prompt caching. The test is whether a human is waiting on the response right now. If not, batch it.

The bottom line

Cutting an AI bill is not about writing shorter prompts. It is about routing each task to the model that can actually do it, caching what repeats, batching what can wait, and measuring cost per task instead of cost per token.

Run the diagnostic first, since the input to output ratio tells you which lever your bill responds to. Then work down the list in order. And keep an evaluation set, because a cheaper model that got worse will not tell you.

MixRoute puts every major model behind one OpenAI compatible endpoint with automatic failover and zero markup, so routing per task is a string change instead of four integrations. Start building on MixRoute