Prompt Caching Pricing Compared: OpenAI 12-Hour, Anthropic, Qwen

Prompt caching lets a provider reuse the work it did on the start of your prompt, so repeated prefixes cost less. It is worth using when the same long prefix is sent at least three times inside the cache lifetime for OpenAI's 12-hour option, and at least twice for the 30-minute OpenAI and 5-minute Anthropic options. Anthropic's one-hour option also needs three. Below those counts, a cache write costs more than it saves. All break-even figures in this post are our arithmetic from published multipliers.

On 20 October 2026 OpenAI added a 12-hour cache option. Its changelog says "12-hour cache writes cost 2.5x the input token price". That is the headline. The useful question is how it compares with what Anthropic and Alibaba charge, and when a longer cache pays for itself.

Last verified 9 November 2026. Every price and multiplier below was read on the vendor page named in the sources line. Where a page does not say something, we say so.

What is prompt caching?

Prompt caching stores the intermediate result of processing a prompt prefix, so a later request with an identical prefix skips that work. OpenAI's guide says the stored data is "key-value (KV) tensors, not the tokens themselves". You pay a write price the first time and a much lower read price on each reuse.

Three properties decide whether it helps.

• The prefix must match exactly. Anthropic's documentation says "Cache hits require 100 percent identical prompt segments". OpenAI says "Cache reuse requires the entire rendered prefix to match."
• There is a minimum length. OpenAI lists 1,024 tokens for GPT-5.6 and later. Anthropic lists 512 tokens for Claude Haiku 5.5, Opus 5.5 and Sonnet 5.5. Alibaba lists 1,024 tokens.
• There is a lifetime. A cache entry expires, so reuse has to arrive in time. Lifetimes range from 5 minutes to 12 hours across the vendors below.

This post deals only with cost. For the wider price picture, see our API pricing trends post. For cost items that sit beside input tokens, see reasoning tokens.

What do OpenAI, Anthropic and Alibaba charge for caching?

Each vendor sets a write price as a multiple of its normal input price, and a read price as a smaller multiple. The table collects the multipliers from the vendors' own pages, read on 9 November 2026.

OpenAI. The guide describes write rates as "total write rates, not surcharges on top of ordinary input". So a 12-hour write costs 2.5 times input, not 3.5 times. For earlier models using prompt_cache_retention, the guide says "No additional cache-write charge". The 12-hour option uses prompt_cache_options.ttl set to "12h" and is, per the guide, available only in the Responses API.

OpenAI's 29 September changelog entry for GPT-6.1 Sol lists "$2 input, $0.10 cached input, $2.50 cache write" per million tokens. The changelog entry does not say which cache lifetime that write price applies to. $2.50 is 1.25 times $2, which matches the default multiple, but that match is our reading.

Anthropic. The documentation gives 1.25 times input for a 5-minute write and 2 times for a 1-hour write. Reads are 0.1 times input, with exceptions: 0.05 times on Claude Opus 5.5 and Sonnet 5.5, and 0.025 times on Claude Fable 5.1 and Mythos 5.1. Claude Haiku 5.5 uses the standard 0.1 times. Its announcement page lists cache reads at $0.01 and cache writes at $0.125 per million tokens for prompts up to 100,000 tokens, against input at $0.10. The page says nothing about cache lifetime, so the lifetimes above come from the documentation.

Alibaba. The Model Studio pricing page states "explicit cache creation is billed at 125% of the standard input price, and cache hits at 10%". Its separate Context Cache page then makes an exception that matters for this series. For qwen3.8-max, qwen3.8-max-0902 and qwen3.8-2.4t-a95b, creation stays at 125% "but the cache hit price is not 10%". For qwen3.8-flash neither ratio applies. For implicit caching, the unit price of cached tokens "is not 20%" of input on these models. The page points to the Model Studio console for the real figures.

We therefore do not give a break-even for Qwen3.8 models. The rate is not published on the pages we could read. Treat 125% and 10% as the general rule, not the Qwen3.8 rate. For the Qwen3.8 line-up and its list prices, see our Qwen 4 status post.

Is 12-hour prompt caching worth it?

It is worth it when the same prefix is reused at least three times in total across a window longer than the short cache lasts. Below that, the 2.5 times write price is not recovered.

The formula is simple. Let W be the write multiple and R the read multiple, both as fractions of the normal input price. Without caching, N calls with the same prefix cost N units. With caching, the first call costs W and each later call costs R. Caching wins when:

W + (N - 1) x R  is less than  N
which gives  N  greater than  (W - R) / (1 - R)

This assumes every later call hits inside the lifetime, and ignores output cost. Results, rounded up to whole calls (our arithmetic):

Two reuses recover a 12-hour write. The real question is whether those reuses fall inside the shorter windows anyway. If calls arrive every few minutes, the default cache already hits and the 12-hour write is a waste. The longer option earns its price when gaps are measured in hours: a support agent handling tickets across a working day, or scheduled jobs that reuse the same policy document within 12 hours.

A worked example makes the gap concrete. Assume a 40,000-token stable prefix (tool definitions, system prompt and reference text) on GPT-6.1 Sol, at $2 input, $0.10 cached input and $2.50 for a default write, from the changelog. The 12-hour write is 2.5 times $2, so $5.00 per million tokens (our arithmetic). Assume 10 calls over six hours and, for this example, that each 30-minute entry has been evicted before the next call. OpenAI may retain entries longer, so measure actual hits.

• No caching: 10 calls at 0.04 million tokens at $2 is $0.80.
• Default cache, every call misses: 10 writes at 0.04 million tokens at $2.50 is $1.00. A cache that never hits can cost more than no cache, if writes are billed on every call.
• 12-hour cache: one write at 0.04 million tokens at $5.00 is $0.20, plus nine reads at 0.04 million tokens at $0.10 is $0.036. Total $0.236, about 70% below no caching.

This covers the prefix only. Messages and outputs cost the same in all three cases, and every later call must match the prefix exactly.

How much does prompt caching save?

For the models in the break-even table, a cache hit saves 90% to 95% of ordinary input cost. Fable 5.1 and Mythos 5.1 have a 97.5% read discount. Net savings also depend on write charges, and the saving grows with the number of reuses. Across a whole bill it saves far less, because outputs and uncached tokens are untouched.

The per-prefix ceiling comes straight from the read multiples. At 0.1 times input, a read saves 90%. At 0.05 times, it saves 95%. OpenAI's guide says reused tokens are "discounted up to 95%". Anthropic's Opus 5.5 and Sonnet 5.5 reads match that ceiling.

For the whole call, here is a second example on Claude Haiku 5.5, using prices from Anthropic's announcement page. Assume a 20,000-token prefix, below the 100,000-token threshold, so input is $0.10, a 5-minute write is $0.125 and a read is $0.01 per million tokens. Assume five calls inside five minutes.

• No caching: 5 calls at 0.02 million tokens at $0.10 is $0.010.
• Cached: one write at 0.02 million tokens at $0.125 is $0.0025, plus four reads at 0.02 million tokens at $0.01 is $0.0008. Total $0.0033, about 67% below.

The percentage is high but the amount is tiny, because Haiku 5.5 input is already cheap. Caching matters most on expensive models, long prefixes and volume. A prefix above 100,000 tokens is billed at the higher Haiku tier; we cover that cliff in our Haiku 5.5 pricing post.

A realistic estimate needs your own hit rate. Net input savings come from ordinary input, cache writes and cache reads. For a fixed prefix whose misses are billed as writes, the fractional saving is h x (1 - R) - (1 - h) x (W - 1), where h is the token hit rate, R the read multiplier and W the write multiplier (our arithmetic). Compare input spend with your total bill, where outputs often dominate. We give no blended percentage because we do not have your traffic.

What does caching look like for self-hosted models?

There is no write price when you host the model, but the cache still costs something: GPU memory. vLLM's automatic prefix caching "caches the KV cache of existing queries, so that a new query can directly reuse the KV cache if it shares the same prefix". The vLLM documentation says you enable it with enable_prefix_caching=True, or the --enable-prefix-caching flag on vllm serve. Check the default for your version.

The documentation states limits too: the feature "only reduces the time of processing the queries (the prefilling phase)" and "does not reduce the time of generating new tokens (the decoding phase)". It helps most with long documents queried repeatedly and with multi-round conversations. It does not help when new queries share no prefix with earlier ones.

Our inference, not vLLM's statement: on a fleet of replicas, a hit needs the request to land on a replica that holds the prefix. Round-robin balancing spreads a session across replicas and wastes the cache. Routing on a session or prefix key keeps related requests together. This is one of the quieter reasons a cluster underperforms, which we discuss in why the cluster is rarely the bottleneck.

Self-hosted caching saves GPU time, so it raises the requests a fixed fleet can serve. It does not appear on an invoice. To value it, compare requests per GPU-hour with and without the cache.

How do you structure prompts for cache hits?

Put everything stable first and everything that changes last. Because the match is on the whole prefix from the start, one changed token early in the prompt invalidates everything after it.

OpenAI's guide gives the rules directly: "Put stable developer instructions and shared reference material first", put timestamps and other dynamic content at the end, and "Append new messages rather than rewriting earlier turns". Anthropic's documentation says the cache follows the order tools, then system, then messages, and "Changes at each level invalidate that level and all subsequent levels".

Practical rules that follow:

1. Order the prompt by how often it changes. Tool definitions first, then system instructions, then shared reference material, then conversation history, then the new user message.
2. Keep tool definitions byte-stable. Do not reorder tools or regenerate schemas on every request. OpenAI says to preserve "tool definitions, ordering, and schemas", and to set tool_choice to "none" rather than deleting tools.
3. Keep volatile values out of the prefix. Timestamps, request IDs, user names and random example order all break the match. Move them to the end.
4. Append, do not rewrite. Editing an earlier turn or summarising history in place changes the prefix. Summarise at deliberate boundaries instead.
5. Mark breakpoints where the content stops changing. On Anthropic, cache_control goes on the last block whose prefix is identical across requests. Anthropic allows up to 4 breakpoints.
6. Mind the lookback. Anthropic states a lookback window of 20 blocks. In long conversations, an old breakpoint can fall out of range.
7. Log the usage fields. Each vendor reports cached and written tokens. Alert when the hit rate falls.

Agent sessions are the biggest win. An agent loop resends the tools, the instructions and the growing history on every step. The stable portion is large and the reuse count is high.

What goes wrong in practice?

Most failures are silent: the answer is right and the bill is higher than planned.

The last row deserves a note. A cache lives with one provider, or one replica on a self-hosted fleet. Our inference: falling back to another provider means a cold cache and fresh writes there. That is a fair cost of resilience, but budget for it.

Where Swfte sits

Swfte Connect offers one API across many providers, which is where prompt-caching decisions get awkward: each provider has its own multipliers, lifetimes and parameters. Connect supports bringing your own keys from any provider, or using Swfte's pooled access. When a provider is out of funds, rate-limited or down, Connect can fall back to another provider in the chain. When a workspace reaches its usage cap, Connect moves its requests to a cheaper model.

Fallbacks and model downgrades can both lose cache hits. A fallback lands on a provider with a cold cache. A downgrade changes the model and so the cache. Both are sensible choices for resilience and budget, and both mean your cost per call can differ from the break-even tables above on the days they trigger.

We have not verified whether provider-specific cache parameters pass through Connect unchanged, and we make no claim about it. Test it first: send the same long prefix several times and read the cached-token fields. If you run your own models, Connect treats models not in its catalogue as bring-your-own-key with an optional base URL. A custom OpenAI-compatible endpoint, such as your own vLLM server, can sit behind routing, failover, usage caps, cost tracking and an audit event stream. Dedicated deployment is available on request.

Related: API pricing trends 2026, reasoning tokens and the hidden cost of LLM pricing, why the cluster is rarely the bottleneck, Claude Haiku 5.5 pricing and small-model routing.

Sources: OpenAI, API changelog · OpenAI, Prompt caching guide · Anthropic, Claude Haiku 5.5 · Claude docs, Prompt caching · Alibaba Cloud, Model Studio pricing · Alibaba Cloud, Context cache · vLLM, Automatic prefix caching, accessed 9 November 2026.

Prices and multipliers are the vendors' published figures on 9 November 2026 and will change. Break-even counts and worked examples are our arithmetic on assumed workloads, not measurements. Alibaba's Qwen3.8 cache-hit prices are not published on the pages we read, so we give none.