Short answer
Neither is always cheaper. The practical winner depends mainly on:
- cache-hit rate and TTL,
- the model’s normal input/output prices,
- how stable and long your prompt prefix is,
- tokenization,
- and whether caching is automatic or explicitly configured.
Rule of thumb
- Claude is often cheaper for heavily reused prompts—multi-turn agents, tool-heavy workflows, and high-frequency RAG—because cached reads are typically priced at about 10% of normal input.
OpenAI is often safer for sporadic or unpredictable traffic, especially on models with no cache-write surcharge, because a cache miss does not impose an additional creation cost.- On newer OpenAI models that also use roughly 1.25× cache writes and 0.1× reads, the caching economics are effectively tied; model quality, token counts, and output costs then decide the result.
The cost mechanics
Using normal input cost as 1.0:
| Scenario |
Initial write |
Subsequent read |
| Claude, 5-minute cache |
1.25× |
0.1× |
| Claude, 1-hour cache |
2× |
0.1× |
| Older/common OpenAI pricing |
1× or no surcharge |
about 0.5× |
| Newer OpenAI pricing, where applicable |
1.25× |
about 0.1× |
Claude’s 5-minute cache becomes cheaper than sending the prefix normally after the first reuse. Its 1-hour cache generally needs about two reuses to pay back the higher write price.[1]
For example, over ten requests using the same prefix:
- Claude 5-minute caching:
1.25 + 9 × 0.1 = 2.15 normal-input units.
- OpenAI at 50% cached-input pricing:
1 + 9 × 0.5 = 5.5 units.
- Either provider at 1.25× writes and 0.1× reads: about
2.15 units.
Thus, Claude has a large advantage over OpenAI’s older 50%-discount arrangement when the prefix is reused many times. That advantage largely disappears when comparing it with newer OpenAI models using the same 90%-style read discount.
When Claude tends to win
Claude is usually attractive when:
- the same system prompt, tools, documents, or conversation history is reused many times;
- requests arrive within the cache lifetime;
- you can deliberately place cache breakpoints;
- the workload is a long-running agent or multi-turn session;
- the cached prefix is large enough for the savings to matter.
Its explicit caching controls can be useful for tool definitions and structured RAG prompts, whereas OpenAI’s automatic caching generally depends on a matching contiguous prefix.[1]
When OpenAI tends to win
OpenAI may be cheaper when:
- requests are infrequent and the cache often expires;
- the relevant OpenAI model has no cache-write surcharge;
- you want caching without adding cache-control logic;
- the OpenAI model has lower base input or output pricing;
- the model completes the task in fewer turns or produces fewer tokens.
A cache that is rewritten on nearly every request can be more expensive than no caching at all if the write multiplier is 1.25× or 2×. This is why a high nominal discount does not guarantee lower bills.
Do not compare cached-input prices alone
Your real cost is approximately:
cache writes
+ cache reads
+ uncached input
+ output tokens
+ reasoning tokens
+ tool/search charges
Tokenization can also change the result: if one provider represents the same text with substantially more tokens, an apparently equal per-million-token price is not actually equal for your workload. Output pricing may dominate as well, particularly for agentic applications.
Bottom line
- High reuse and tight request bursts: Claude often wins, especially against OpenAI models offering only a 50% cached-input discount.
- Low reuse, sporadic traffic, or minimal implementation effort: OpenAI is often the safer choice.
- Claude versus newer OpenAI models with 1.25× writes and 0.1× reads: caching itself is roughly a tie; choose based on total tokens, output costs, model performance, and cache lifetime.
For a production decision, run both providers on representative requests and measure actual cached-token hits, total input tokens, output/reasoning tokens, and completed-task cost. Pricing and TTLs are model-specific and change frequently.[2]
