How to Cut Your OpenAI or Anthropic Bill

TL;DR

Almost everything in a provider-specific cost guide is not provider-specific. The levers are the same on OpenAI and Anthropic. One thing genuinely differs, and it is caching.

Here is the finding that should reorder your priorities. At 100,000 requests a month with a stable 10,000-token prefix:

Claude Sonnet with caching configured properly costs $1,198 a month. GPT-5.6 with no caching costs $1,612. The optimised expensive model beats the unoptimised cheap one, despite Sonnet billing 2.4x more per input token.

Which means provider shopping is close to the weakest move available to you, and it is the one most teams reach for first. If your goal is to lower your OpenAI bill this quarter, the provider you are on is very unlikely to be the reason it is high.

Want the saving captured rather than calculated? We build caching, routing and cost instrumentation into your stack end to end. See how we approach AI development.

Key Takeaways

• Switching providers moves your bill by roughly 2x. Fixing caching on the provider you already use moves it by 3x.
• OpenAI's older automatic caching can never cost you money, but it is capped near 43%.
• Explicit caching on Claude reaches 67% to 74%, and below roughly 11,000 requests a month it costs you 21% more.
• At low volume, the longer cache is the correct one. Claude's 1-hour cache starts paying at around 1,500 requests a month, seven times lower than the 5-minute cache.
• Batch, routing and loop discipline behave identically on both. Do not go provider shopping for those.

Claude API cost optimization: what actually differs from OpenAI

Strip out the marketing and the two providers differ in exactly one place that matters for cost: how caching is billed.

That last row is the whole strategic difference. OpenAI's automatic caching has no write fee, so it is impossible to get wrong and impossible to lose on. It is also capped: a 50% read discount is half of what the explicit systems give you.

Anthropic's caching has a higher ceiling and a real floor. You pay a premium to write the cache, so if your traffic is too sparse to reuse it, you pay the premium repeatedly and get nothing back.

The volume where caching starts paying

This is the part nobody writes down, so here it is with numbers. Same workload throughout: a 10,000-token stable prefix, 500 fresh tokens, 300 output tokens.

Negative numbers mean caching made the bill worse.

The mechanism is simple once you see it. Caching pays when requests arrive faster than the cache expires. Below that, every single call writes a cache nobody ever reads, and you pay the write premium for the privilege.

At 100,000 requests a month you get one every 26 seconds, comfortably inside a five-minute window. At 5,000 a month you get one every nine minutes, and a five-minute cache is cold every time.

OpenAI's GPT-5.6 and later behave almost identically to Claude's 5-minute cache here, because the write premium and read discount are the same. The table's OpenAI column is the older automatic behaviour specifically.

The counterintuitive one: use the longer cache when you are small

Most teams assume a longer TTL is for bigger workloads. It is the reverse.

Running the same Claude models through Amazon Bedrock keeps these rates and changes the rules: the minimums there run up to four times higher, and missing one fails silently.

Claude's 1-hour cache costs more to write, 2x base instead of 1.25x, but it survives an hour of silence. That extra premium is trivial next to the cost of writing a cache that expires before anyone reads it.

The numbers: the 5-minute cache starts paying at roughly 11,000 requests a month. The 1-hour cache starts paying at roughly 1,500. Seven times lower.

So if your traffic is sparse, reaching for the cheap short cache is exactly backwards. And if it is very sparse, under about 700 a month, neither one helps and you should leave caching off entirely.

Where provider shopping actually ranks

Now put the two decisions side by side on the same workload.

Moving from Sonnet to GPT-5.6 cuts the bill 55%. Turning on caching properly on Sonnet cuts it 67%. The optimised expensive option lands below the unoptimised cheap one.

That is not an argument for either provider. It is an argument that the configuration decision is larger than the vendor decision, and it is available to you this week without a migration, a re-evaluation, or a single changed prompt.

Migrations also carry a cost this comparison ignores: every prompt has to be re-validated against different model behaviour, which is engineering time that produces no new features.

One more reason not to build a strategy on today's price list. The Wall Street Journal reported in June 2026 that OpenAI is weighing significant token price cuts in anticipation of Anthropic making similar moves. If that plays out, the vendor gap narrows further and the configuration gap does not, which makes the argument on this page stronger rather than weaker. It also will not lower your bill on its own, for the reason set out in why AI bills rise while token prices fall.

On Azure OpenAI, none of this pricing applies

Worth stopping on, because a reader running OpenAI models through Azure has been reading advice built on the wrong billing model.

Azure OpenAI offers the pay-as-you-go shape described above, and a second one that behaves nothing like it: Provisioned Throughput Units. A PTU is reserved capacity measured in tokens per minute, and you pay for it whether you use it or not. A monthly reservation runs roughly $2,448 per PTU, a yearly commitment closer to $1,750.

That converts the entire question from token efficiency to utilisation, which is the same argument as self-hosting wearing a different label, and it fails the same way:

PTUs break even somewhere around 60% to 70% sustained utilisation. Below that, pay-as-you-go is cheaper, and the gap widens the emptier the reservation sits. Azure Monitor exposes ProvisionedUtilization, so this is one metric away from being answerable rather than argued.

The trap we see most often is dev, QA and internal tools running on provisioned capacity. None of them need a latency guarantee, and a PTU costs its full monthly minimum while idle overnight and at weekends. Moving non-production to pay-as-you-go is usually the single largest Azure OpenAI saving available, and it requires no change to a single prompt.

Caching, routing, batching and loop discipline all still apply on top. They just act on a smaller share of the bill, because on a PTU deployment your dominant cost is capacity you already committed to.

The order to work in

Whether you file it under OpenAI cost optimization or Claude API cost optimization, the sequence is the same, and the sequence matters more than any individual move because each step acts only on what the previous one left behind.

1. Count the calls per completed outcome. One user action that quietly makes nine model calls is an architecture problem, and no pricing decision touches it.
2. Route what does not need the top tier. Classification, extraction and query rewriting rarely do.
3. Cache any stable prefix, with the TTL chosen from your real request spacing rather than the default.
4. Batch anything nobody is waiting on, for roughly half price.
5. Then, and only then, price the alternative provider.

Teams that set out to reduce OpenAI costs almost always start at step five, because it feels like the decision with the biggest number attached. It is the smallest one on this list, and the only one that costs you a migration.

That ordering is also what separates OpenAI cost management as a practice from a one-off cleanup. Steps one through four are things you build in, and they keep working as traffic grows. Step five is a thing you do once and cannot easily undo.

Batch: the lever nobody turns on

Worth its own section because it is the least used and the least risky.

Both providers give roughly 50% off for work submitted asynchronously, with results returned inside a 24-hour window. OpenAI calls it the Batch API, Anthropic calls it Message Batches. The discount and the trade are effectively the same on both.

The reason to care: a surprising share of production AI work has nobody waiting on it. Nightly enrichment, backfills, evaluation runs, document processing queues, report generation, embedding refreshes. If a human is not watching a spinner, the work is a batch candidate.

This is the one lever where the answer to "reduce Anthropic costs" and the answer to "reduce OpenAI costs" are identical, and it is close to pure margin: no quality trade, no routing logic, no evaluation set to build. The only thing you spend is latency you were not using.

OpenAI adds a third tier between real-time and batch: flex processing, which trades slower responses and occasional unavailability for a lower rate on the same synchronous API. It fits evaluations, enrichment and other lower-priority work that wants results sooner than a 24-hour batch window but does not need production latency. Anthropic has no direct equivalent, which makes this one of the few genuine one-provider levers on the page.

What behaves identically on both

Do not go provider shopping for any of these. They are the same lever with the same shape:

• Batch processing. Both offer roughly 50% off for work nobody is waiting on. Same discount, same trade, same 24-hour window.
• Routing to smaller models. Both have a cheap tier and an expensive one. The rule from small language models vs LLMs applies unchanged: the break-even success rate is about 1 divided by the price ratio.
• Loop discipline. An agent that carries its full transcript pays the same quadratic penalty everywhere. That is architecture, not pricing.
• Output length. Output bills four to five times input on both. Token optimization is provider-neutral.

If you find a "reduce your OpenAI bill" guide whose advice is mostly these four, it is a general cost guide wearing a provider's name.

So which provider is actually cheaper?

The honest answer is that the question is badly formed, because the spread within a provider is larger than the spread between them.

Claude's tiers run from $1 to $5 per million input tokens. That 5x internal range dwarfs the difference between comparable tiers across vendors. Your model tier and your caching configuration decide your bill. Your vendor mostly decides your integration work.

Pick on capability, latency, rate limits and the quality of the failure modes you can detect. Then optimise hard inside whichever you picked. That ordering will beat vendor-hopping every time.

If you want the comparison at your own traffic shape rather than at a headline rate, the calculator below ranks the models by what a month would actually cost you. Change the output share or the cache hit rate and watch the order move.

Where this fits

Everything above is one branch of a larger sequence. The five levers that move an AI bill, in the order that makes them multiply rather than overlap, are set out in our guide to LLM cost optimization. The caching mechanics referenced throughout, including per-provider pricing and the TTL trap in full, are in prompt caching.

And whichever provider you land on, instrument cost per task before you start comparing. A provider comparison run on cost per token will mislead you, because the cheaper model is the one that retries.

Rather have this done than read? We build the caching, routing and instrumentation in from the first commit. Tell us what your invoice looks like.

Frequently asked questions

How do I reduce my OpenAI bill?

In order: cut the number of calls your application makes per user outcome, route work that does not need the top tier to a smaller model, enable caching for any stable prefix, and move anything nobody is waiting on to the Batch API for roughly half price. Provider switching belongs last, not first.

How do I reduce my Anthropic bill?

Whether you search for it as reduce Claude costs or reduce Anthropic costs, it is the same four moves, with one Claude-specific decision: choose your cache TTL from your actual request spacing. Below roughly 11,000 requests a month the 5-minute cache costs more than it saves, and the 1-hour cache is the correct choice from about 1,500 a month upward.

Is Claude or GPT cheaper?

Neither, reliably. The tier range inside each provider is wider than the gap between them, so configuration decides the outcome. On our worked example a cached Claude Sonnet workload came in below an uncached GPT-5.6 one, despite Sonnet costing 2.4x more per input token.

Does prompt caching ever make the bill worse?

Yes, on explicit caching. You pay a premium to write the cache, so if traffic is sparse enough that each cache expires before anything reads it, you pay that premium on every call and get nothing. OpenAI's older automatic caching has no write fee and so cannot lose.

How do I reduce Azure OpenAI costs?

Start with the billing model rather than the prompts. If you are on Provisioned Throughput Units, check ProvisionedUtilization: sustained use below 70% means you are paying for idle capacity, and moving dev, QA and internal tools to pay-as-you-go is usually the biggest single saving. Caching and routing apply on top, to a smaller share.

Is switching providers worth it for cost alone?

Rarely. The move is worth about 2x, while fixing caching on the provider you already use is worth about 3x, and migration means re-validating every prompt against different model behaviour. Switch for capability, latency or rate limits. Optimise for cost.

Sources

• Anthropic pricing
• OpenAI API pricing
• OpenAI Batch API