How to Reduce Your AI API Costs

Quick answer

Five things move an AI API bill more than anything else: routing each request to the cheapest model that can actually do the job, caching anything you send more than once, batching work that doesn’t need an instant answer, capping how much the model is allowed to write back, and trimming what you send in the first place. Stacked together, these routinely cut a bill by 60-90%, and none of them require switching providers.

Key takeaways

• Model tiering is the single biggest lever — routing simple tasks to a budget model instead of the flagship often cuts cost per request by 10x or more before you touch anything else.
• Prompt caching and batch processing stack. Caching alone saves up to 90% on repeated input; batching saves 50% on top of whatever you’re already paying. Used together on the same request, effective savings compound past 90%.
• Output tokens cost far more than input tokens on every major provider — often 5-6x per token — so an unbounded max_tokens setting is one of the most common silent cost leaks.
• None of these techniques require leaving your current provider. Anthropic, OpenAI, and Google all support caching and batch discounts on their current model lines, with the same basic mechanics.
• The savings are additive, not exclusive. A workload using the wrong model, sending an untrimmed prompt, and generating unbounded output is often paying 10-20x what the same task costs once all five levers are applied.

Every AI API bill has the same shape: it’s driven by which model you called, how many tokens went in, how many came out, and whether you paid full price for tokens you’d already sent before. Most teams overspend on all four without realizing it, because the default way of calling an API — same model for everything, no caching, no batching, no output limit — is also the most expensive way.

This guide covers the five techniques that actually move the needle, in the order they’re worth doing, with real numbers from Anthropic, OpenAI, and Google’s current pricing as of late August 2026.

The five levers that actually move your bill

1. Route to the cheapest model that can do the job

Every major provider now ships at least three pricing tiers of the same model family, and the price gap between them is large. On OpenAI’s current GPT-5.6 line, the flagship Sol costs $5 per million input tokens and $30 per million output; the budget Luna tier costs $0.20 and $1.20 — a 25x spread for tasks Luna handles identically, like classification, extraction, or short-form completion. Anthropic’s spread runs from Claude Haiku 4.5 at $1/$5 per million up to premium Opus-tier pricing. Google’s Gemini lineup goes from Flash-Lite tiers under $0.15 per million up past $2 for Pro-tier reasoning.

The mistake isn’t using a flagship model — it’s using it by default for tasks that don’t need it. A support-ticket classifier, a data-extraction pipeline, or a short-form content generator rarely needs the same model as a complex coding agent or a research summarizer. Test your actual task against a mid-tier or budget model before assuming you need the top of the line; for most structured or short-output tasks, the answer is closer than expected. Our guide on how to choose the right AI model for your task covers the decision framework in more depth.

Our AI Model Comparison Tool puts pricing and capability side by side across providers to check.

2. Cache anything you send more than once

If your application repeats the same system prompt, tool definitions, or reference document across many requests, prompt caching is usually the single largest lever available. Every major provider now offers it, and the mechanics are close to identical: you pay slightly more the first time a piece of content is cached, and a fraction of the normal rate every time it’s read back.

Anthropic charges 1.25x the base input rate to write a 5-minute cache, then bills cache reads at 10% of the standard rate — a 90% discount on every repeated read. OpenAI’s GPT-5.6 family bills cached input at 10% of standard rates across all three tiers, with writes at 1.25x. Google’s Gemini API applies the same 90%-off pattern on cache reads, with an hourly storage charge for content kept live between requests.

The math works in your favor fast. If a 2,000-token system prompt gets reused across 10,000 requests a day, caching turns roughly 20 million tokens of full-price input into one cache write plus 10,000 cache reads at a tenth of the cost — often a difference of hundreds of dollars a month on that one input alone.

Our Prompt Caching ROI Calculator estimates the break-even point for your own request volume, and the Guide to Prompt Caching covers the implementation details — including the prefix-ordering mistake that silently erases the savings if the cached content isn’t structured correctly.

3. Batch what doesn’t need an instant answer

Every major provider offers an asynchronous batch API that processes requests within roughly 24 hours (often much faster) at exactly half the standard price — on both input and output tokens. This applies to Anthropic’s Batch API, OpenAI’s Batch endpoint, and Google’s Gemini Batch API identically: submit a batch, get results back later, pay 50% less.

Batching only helps if the workload doesn’t need a synchronous response. It’s a strong fit for bulk document processing, nightly data pipelines, evaluation runs, content generation queued ahead of publish, and any backend job where a user isn’t staring at a loading spinner. It’s a poor fit for live chat, real-time agents, or anything a person is actively waiting on.

Batching and caching stack. A cached read that would normally cost 10% of standard price drops to 5% of standard price when processed through batch — a 95% discount on that portion of the request.

4. Cap output length deliberately

Output tokens cost meaningfully more than input tokens on every major provider — commonly 5-6x per token (see Understanding Tokens: A Complete Guide if the input/output distinction itself needs unpacking). This makes uncontrolled output length one of the most common, least-visible sources of overspend. A model that wanders into a 1,500-token explanation when a 150-token answer would do isn’t just slower; it’s often costing more than the entire input side of the request.

Set an explicit max_tokens (or provider-equivalent) ceiling matched to what the task actually needs, and audit prompts the way you’d audit a slow database query — not as a one-time setup step, but as something to revisit when a workload’s bill looks larger than its volume explains. Tasks like classification, extraction, and short-form generation should have tight, deliberate output caps; open-ended writing or long-form code generation need more room, but even there, an unbounded ceiling invites runaway responses on edge cases.

5. Trim what you send before you send it

The token count on the input side is often padded with more than the task needs: verbose system prompts, unnecessary conversation history, full documents where only a section is relevant, or repeated boilerplate instructions that could be shortened or cached instead of resent in full every time.

For chat applications, this usually means summarizing or truncating older conversation turns instead of resending the full history on every message. For RAG and document-heavy workloads, it means retrieving and sending only the passages that are actually relevant, rather than an entire source document — our RAG Pipeline Cost Calculator breaks down where retrieval-augmented costs typically concentrate. For anything with a long, mostly-static system prompt, it means moving that content into a cache (lever #2) instead of paying full input price for it on every call.

This is the lever most teams skip, because it requires actually looking at what’s inside a request rather than adjusting a setting. It’s also often where the largest single reduction is available, because unlike model tier or caching, there’s frequently no tradeoff at all — the trimmed content wasn’t improving the response.

How much do these actually save, stacked?

None of these five levers are exclusive. Applied together, the discounts compound:

• Right-sizing the model alone: often a 5-25x reduction in per-token cost, depending on how mismatched the original choice was
• Caching on top of that: up to 90% off the portion of input that’s repeated
• Batching on top of both: an additional 50% off, applied to already-discounted cached tokens
• Output capping and input trimming: reduces the token counts everything else is multiplied against

A workload that’s using a flagship model, sending an uncached 3,000-token system prompt on every call, generating unbounded output, and running synchronously ends up paying full price on every one of those dimensions at once. The same workload — right-sized model, cached system prompt, batched where the response isn’t time-sensitive, and a sane output ceiling — routinely costs 70-90% less for the same underlying task.

A worked example: cutting a real workload’s bill

Take a document-summarization pipeline: 50,000 documents a month, each with a 2,000-token shared instruction prefix (formatting rules, output schema, examples) plus roughly 1,500 tokens of unique document content, generating a 300-token summary. Run synchronously on a flagship-tier model with no caching, that’s roughly 3,500 input tokens and 300 output tokens per call, 50,000 calls a month — about 175 million input tokens and 15 million output tokens, billed in full every time.

Now apply the levers. The shared 2,000-token prefix gets cached instead of resent — it’s identical across all 50,000 calls, so after the first write, the other 49,999 reads cost a tenth of standard input price. The task itself doesn’t need flagship reasoning, so it moves to a mid-tier model at roughly a third of the flagship’s per-token rate. Since summaries don’t need to return instantly, the whole job runs through the batch API overnight, taking another 50% off everything.

The result isn’t a small optimization — it’s the difference between a workload that looks expensive enough to question and one that barely shows up as a line item, without changing what the pipeline actually does or which provider it uses.

Common mistakes that quietly inflate your bill

Using the same model for every task by default. The convenience of one model everywhere is real, but it means simple, high-volume tasks are subsidizing the cost of complex ones for no reason.

Never checking if caching is actually landing. Most providers report cache hit/miss data in the response metadata. If a cache is being written but never successfully read back — often because the cached content isn’t byte-for-byte identical between calls, or because unstable content like a timestamp got mixed into the prefix — the caching setup is pure overhead with none of the savings.

Leaving max_tokens unset or set far higher than needed. This is the most common single-line-of-code overspend, because it’s invisible until a bill is reviewed.

Resending full conversation history indefinitely. A chat application that never truncates or summarizes older turns pays a growing input cost on every single message as the conversation gets longer, even when most of that history is irrelevant to the current turn.

Treating batch as only for huge jobs. Batch discounts apply at any volume — a nightly job processing a few hundred items still gets the same 50% off as one processing millions.

Where these techniques have real tradeoffs

None of the five levers are free of judgment calls, and treating them as pure wins in every case leads to its own problems.

Model tiering fails silently when the cheaper model’s errors are more expensive than the money saved — a support bot that mis-classifies edge cases, or a code-review model that misses a real bug, can cost more in downstream cleanup than the API savings were worth. Test against a representative sample of your actual hardest cases, not just the easy majority, before committing to a lower tier.

Caching adds a small amount of architectural complexity: content that’s supposed to be identical between calls has to actually stay identical, which means auditing what goes into the cached portion of a prompt and keeping dynamic content (user IDs, timestamps, session state) strictly out of it. A caching setup that looks correct but silently never hits is worse than no caching at all, since it adds the write premium without ever recovering it in cheaper reads.

Batching trades latency for cost, which is the right trade for backend jobs and the wrong one for anything a user is waiting on. It’s easy to over-apply batch to a workload that started as background processing and quietly became latency-sensitive as a product evolved — worth revisiting periodically, not just deciding once.

Building a cost-monitoring habit

The techniques above are one-time architectural decisions, but AI spend tends to grow with usage in ways that are easy to miss until a bill spikes. Track spend by task or feature, not just as a single line item, so a change in one part of the product doesn’t hide inside an aggregate number. Revisit model choice periodically — pricing on all three major providers has shifted multiple times in 2026 alone, and a model that was the best value six months ago may not be today. And when a new model generation ships, treat it as a prompt to re-test your task against the current lineup rather than assuming last quarter’s choice is still optimal. If your team doesn’t have a monitoring habit yet, how to set an AI budget for your team covers the process side of getting there.

For a live snapshot of current rates across providers, see the AI Model Pricing Comparison Chart — pricing moves often enough in 2026 that it’s worth checking against a source that’s kept current rather than relying on numbers from a few months back. For the authoritative numbers straight from each provider, see Anthropic’s pricing page, OpenAI’s API pricing page, and Google’s Gemini API pricing page.

FAQ

Does prompt caching work the same way across Anthropic, OpenAI, and Google?

The core mechanic is consistent — pay a small premium to write a cache, then a fraction of standard price to read it back — but the exact discount and cache lifetime vary by provider. All three currently offer roughly 90% off cached reads, but cache duration, minimum content size, and write pricing differ enough that it’s worth checking each provider’s current documentation before assuming identical behavior.

Is batch processing worth it for a small workload?

Yes. The 50% discount applies regardless of volume — a batch of 200 requests gets the same rate as a batch of 2 million. The only requirement is that the workload can tolerate an asynchronous response, typically within 24 hours.

Will switching to a cheaper model hurt output quality?

Sometimes, but less often than assumed. For structured tasks like classification, extraction, formatting, and short-form generation, mid-tier and budget models frequently perform identically to flagship models. The gap widens on complex reasoning, long-form writing, and difficult coding tasks — those are exactly the cases where the flagship tier’s cost is usually justified.

How do I know if my prompt caching setup is actually saving money?

Check the cache-related fields in the API response metadata after each call — providers report whether a request hit or missed the cache. If hits are rare or absent, the cached content likely isn’t staying identical between calls, which is usually caused by dynamic content (timestamps, session IDs, changing context) getting mixed into the part of the prompt that’s supposed to be cached.

Do these techniques apply if I’m using a model through a chat subscription instead of the API?

No — subscription plans like ChatGPT Plus, Claude Pro, or Gemini Advanced are flat-rate and don’t bill per token, so caching and batch discounts don’t apply. These five levers are specific to pay-per-token API usage; if you’re still deciding between the two, API vs chat interface: which should you use? walks through that decision.

Is there a downside to capping output length too aggressively?

Yes — a max_tokens limit set too low will cut off responses mid-answer rather than making them more concise, which can be worse than the cost it saves. The goal is matching the cap to what the task genuinely needs, not minimizing it blindly.