How to reduce your LLM API costs

If your model bill is growing faster than your usage, the cause is almost never mysterious. Four things drive nearly all of it: how many input tokens you send, how many output tokens you generate, how much of your input is repeated across calls, and what you pay per million tokens. Everything below is a lever on one of those four.

This guide is the hub for a small set of deeper pieces. If you already know which part you need, jump to how vendor list prices compare, a head-to-head on two frontier models, how to estimate a monthly bill from real usage, or what prompt caching is actually worth.

Where the money actually goes

Token pricing is asymmetric, and that asymmetry is the single most useful fact for controlling spend. Output tokens cost several times more than input tokens on every model in our catalog. Cached input, where a vendor offers it, costs a fraction of normal input.

So a workload that reads a large document and returns a short label has a very different cost profile from one that reads a short prompt and writes a long essay, even at identical total token counts. Before optimizing anything, find out which shape yours is. The estimation walkthrough shows how to get that number from logs rather than guessing.

Lever 1: right-size the model

The largest models are priced for the hardest problems. A meaningful share of production traffic is not hard: classification, extraction, routing, short summarization, format conversion. Running that traffic on a smaller model is usually the single biggest line-item change available, because the price gap between tiers is multiplicative, not marginal.

The practical pattern is a router: cheap model first, escalate on low confidence or on an explicit signal from the task. You keep quality where it matters and stop paying premium rates for work that never needed them. Compare the tiers on the full price table or browse the model catalog to see which pairs make a sensible fast path and slow path.

Lever 2: cache the part of the prompt that never changes

Most production prompts are mostly boilerplate: a system prompt, tool definitions, few-shot examples, a policy document. That prefix is identical on every call, and you are paying full input price for it every single time.

Both vendors price a cache read at a small fraction of the normal input rate. For a prompt that is mostly stable prefix, that is close to a straight discount on the input half of your bill. The mechanics, the ordering rules that make it work, and the cases where it silently does not apply are covered in the prompt caching breakdown.

Lever 3: stop paying for output you discard

Output is the expensive side of the ledger, and it is the side developers most often leave uncontrolled. Three habits waste it consistently:

• No max token limit. A model that rambles for 900 tokens when 80 would do is charging you for the other 820.
• Asking for prose when you need structure. Requesting a compact JSON object instead of an explained answer often cuts output by an order of magnitude.
• Regenerating whole documents to change one field. Ask for the delta, apply it yourself.

None of these trade away quality. They remove tokens nobody reads.

Lever 4: measure before you optimize

Teams routinely optimize the wrong endpoint because intuition about token volume is unreliable. One background job that re-embeds a corpus nightly can outweigh all interactive traffic combined. Log input tokens, output tokens, cached tokens, and model, per route, and sort by cost rather than by call count.

Once you have per-route token volumes, the API cost calculator turns them into a monthly figure in a few seconds, and shows the same workload at list price and at outlet price side by side.

Lever 5: the unit price itself

The first four levers reduce how many tokens you buy. This one changes what each token costs, and it is the only lever that applies to every request you make without any engineering work.

corouter resells capacity for these models at outlet prices, metered per token and billed from prepaid credit. You keep the same model IDs and familiar JSON shapes, so the change is a routing decision rather than a rewrite of your application logic.

What the levers are worth together

Take a mid-sized workload: 50M input tokens and 5M output tokens a month. At published list prices against outlet prices, before any engineering changes at all:

Now layer the engineering levers on top. Route the easy half of that traffic to a smaller model and the input line drops again. Cache a stable 2,000-token system prefix and most of the remaining input cost goes with it. These compound, because they act on different terms of the same equation.

A sensible order of operations

1. Instrument first. One week of per-route token logging beats a month of guessing.
2. Cap output tokens everywhere and switch verbose endpoints to structured responses.
3. Turn on prompt caching for any prompt with a stable prefix. See the caching guide for what qualifies.
4. Move non-hard traffic to a smaller tier. The vendor price comparison shows where the tier gaps are widest.
5. Reprice the whole thing. Check your real numbers in the cost calculator.