How to cut your OpenAI & Anthropic API bill by 50%+
Most large LLM bills are big for one reason: every request goes to a premium model, whether it needs one or not. Below are seven levers that reduce cost, ranked by how much they typically move the number. The first one alone often cuts a bill by 40–70%. None of them require switching providers, and most take an afternoon to implement.
If you just want to see your own numbers, plug your usage into the free LLM cost calculator — the routing slider at the top models the biggest lever below. Otherwise, read on.
01
Route easy work to a cheaper model
This is the lever that matters most, because per-token prices span a huge range — a frontier model can cost 5 to 25× more per token than a small, fast one. Yet most of what production apps do is not frontier-hard: classification, tagging, short summaries, extraction, routing, reformatting, and simple Q&A are all handled well by a small model.
The move is to split your traffic by difficulty and send each request to the cheapest model that can actually do it. A rough tiering:
| Task type | Send to |
|---|---|
| Classification, tagging, extraction, short summaries | Small / cheap model |
| General chat, RAG answers, drafting | Mid-tier model |
| Hard reasoning, long-horizon agents, code review | Premium model |
Even a conservative split — say 60% of requests dropped one tier — reshapes the bill, because you're removing the most expensive tokens first. The catch is quality: you have to verify the cheaper model is actually good enough on your data, not assume it. Run both on a sample, compare outputs, and only route down where the cheap model passes.
See your routing savings
The calculator's slider lets you set what share of traffic truly needs the premium model, then shows the blended cost and the percentage saved against running everything premium.
Open the calculator →02
Turn on prompt caching
If a large chunk of your prompt repeats across requests — a fixed system prompt, a reference document, a set of few-shot examples, a tool schema — you're paying full price to re-send it every time. Prompt caching stores that repeated prefix so subsequent requests read it at roughly one-tenth of the normal input price.
It's a near-free win for the right workloads: agents with a big system prompt, chatbots with a long instruction block, or any pipeline that stuffs the same document into every call. The rules are simple but strict — caching is a prefix match, so the repeated content has to sit at the front of the prompt and be byte-for-byte identical. A stray timestamp or a reordered JSON key at the top silently breaks it.
Rule of thumb: if more than ~1,000 tokens of your prompt are identical across calls, caching will pay for itself within a couple of requests.
It does nothing for prompts that differ from the first token every time — so it helps RAG-with-fixed-instructions but not one-off, wholly-unique prompts.
03
Use the Batch API for anything not real-time
Both OpenAI and Anthropic offer a Batch API that runs the exact same requests at half price, in exchange for asynchronous delivery (usually within an hour, up to 24). If a human isn't waiting on the response, this is free money:
- Overnight processing and backfills
- Bulk classification, tagging, enrichment
- Evaluation runs and regression suites
- Generating embeddings or summaries over a large corpus
The only cost is latency. Split your workload into "someone is waiting" (real-time API) and "results by tomorrow are fine" (batch), and move everything you can into the second bucket.
04
Trim the context you send
Input tokens are billed whether the model needed them or not. Two common sources of waste:
Over-stuffed RAG
Retrieving 20 chunks "to be safe" when 4 would answer the question multiplies your input cost. Tighten retrieval: fewer, higher-relevance chunks, deduplicated, with a re-ranking step so the best passages come first. Better retrieval usually improves answer quality while cutting tokens.
Unbounded chat history
Sending the entire conversation on every turn grows cost linearly with length. Summarize or truncate old turns, or use provider-side context management, so a long session doesn't re-bill the whole transcript each message.
05
Cap output with max_tokens
Output tokens are the expensive ones — often 4–5× the input price per token. A model with no output ceiling can ramble, and on reasoning models an unbounded response can burn a surprising amount. Set a max_tokens that reflects the answer you actually need, and instruct the model to be concise. This won't halve a bill on its own, but it removes the tail of runaway responses that quietly inflate costs.
06
Use a smaller model with better prompting
Teams often reach for the biggest model to compensate for a vague prompt. Frequently a smaller model with a well-structured prompt, a few good examples, or light fine-tuning matches the big model on a narrow task at a fraction of the price. This overlaps with lever 01 but goes further: instead of just routing, you actively invest in making the cheap model good enough. Best suited to high-volume, repetitive tasks where the per-request engineering pays off across millions of calls.
07
Self-host an open model — above the break-even
Open-weight models (Llama, Mistral, Qwen and friends) can run on GPUs you rent or own, at a very low marginal cost per token. At high, steady volume this is the cheapest option by far. But it flips: below a break-even volume, per-token API pricing wins, because a GPU bills by the hour whether it's busy or idle, and you now own reliability, scaling, and ops.
Do the math before committing — we walk through the break-even in self-hosting vs API: the break-even. As a rule, self-hosting pays off once you have large, predictable, always-on volume; it's a poor fit for spiky or low traffic.
Put them together
These levers stack. A realistic combined program on a metered workload:
| Lever | Approx. impact |
|---|---|
| Route easy work to a cheaper model | −40–70% |
| Prompt caching (cache-heavy workloads) | −20–50% input |
| Batch API (non-real-time share) | −50% on that share |
| Context trimming | −10–40% input |
You won't get every discount on every request, and they overlap — but it's why "cut the bill in half" is a conservative headline for most teams that have never optimized, not an aggressive one. Start with lever 01; it's the biggest and the fastest.
Want this to happen automatically?
A routing layer applies lever 01 for you — inspecting each request and sending it to the cheapest capable model, so you capture the saving without choosing a model per call. See the options and pricing:
Compare routing tools →FAQ
What's the single biggest way to reduce LLM API costs?
Model routing (lever 01). Because a frontier model can cost 5–25× more per token than a small one, moving even half your traffic down a tier typically cuts a bill by 40–70%.
Will a cheaper model hurt quality?
Only if you route work it can't handle. The discipline is to test the cheap model on your actual data first and route down only where it passes — not to assume. On easy tasks (classification, extraction, short summaries) the quality gap is usually negligible.
Does prompt caching work for every app?
No — only when a large part of the prompt repeats across requests. It's excellent for agents and chatbots with a big fixed system prompt, and useless for wholly-unique one-off prompts.