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.
What actually differs
Strip out the marketing and the two providers differ in exactly one place that matters for cost: how caching is billed.
| OpenAI, older models | OpenAI, GPT-5.6+ | Anthropic Claude | |
|---|---|---|---|
| Activation | automatic | explicit | explicit |
| Write premium | none | 1.25x | 1.25x at 5 min, 2x at 1 hour |
| Read discount | about 50% | 90% | 90% |
| TTL control | none | short | 5 minutes or 1 hour |
| Can it lose you money? | no | yes | yes |
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.
| Requests per month | Claude, 5-min cache | Claude, 1-hour cache | OpenAI, automatic |
|---|---|---|---|
| 2,000 | -21% | +18% | +43% |
| 5,000 | -21% | +52% | +43% |
| 10,000 | -8% | +64% | +43% |
| 30,000 | +47% | +71% | +43% |
| 100,000 | +67% | +74% | +43% |
| 1,000,000 | +74% | +75% | +43% |
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.
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.
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.
- 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.
- Route what does not need the top tier. Classification, extraction and query rewriting rarely do.
- Cache any stable prefix, with the TTL chosen from your real request spacing rather than the default.
- Batch anything nobody is waiting on, for roughly half price.
- 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.
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.
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.
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.
