Prompt caching cost reduction depends on five variables: the stable prefix size, uncached input price, cache-write price, cache-read price, and the number of requests that reuse the prefix before its time-to-live expires. A cache can reduce input spend when reuse is high, but a short-lived prefix, expensive write, storage fee, or frequent miss can erase the saving.

The safest way to measure it is to compare the same request shape with and without caching. Count cache writes, cache reads, misses, dynamic tokens, TTL storage, and output tokens separately. This guide turns provider documentation into one prompt cache break-even calculation instead of repeating a maximum-savings claim.

The short answer: cache a long, stable prefix when the provider's read price is lower than its ordinary input price and the prefix is reused often enough to pay for writes and storage. Keep changing user data after the cache boundary.

What prompt caching cost reduction actually means

Prompt caching stores or reuses a previously processed section of a prompt. That section is usually a stable prefix containing system instructions, tool definitions, schemas, or reference material. The dynamic user request comes after it. A cache hit avoids charging the stable tokens at the ordinary input rate, though the provider may charge for writing or storing the prefix.

Prompt caching is different from semantic caching. Prompt caching reuses a matching prompt prefix for the model. Semantic caching reuses an earlier answer for a meaningfully similar request. RAG retrieves documents at request time. These features can work together, but their hit rates and costs belong in separate columns.

TermWhat it means for cost
Cache writeTokens processed and stored for future reuse
Cache readStored tokens reused on a matching request
Cache missThe prefix fails to match or has expired
TTLHow long the cached state remains available
Dynamic suffixPer-user or per-request tokens billed normally
StorageProvider charge for keeping explicit cached content

OpenAI documents automatic prefix matching for eligible prompts and reports cached-token usage. AWS describes cache checkpoints as markers for a contiguous prompt subsection. Both models make prompt layout part of the cost calculation. (Source: OpenAI prompt caching, AWS Bedrock prompt caching)

Prompt caching cost by provider

Providers use related ideas with different billing units and controls. Do not copy a discount percentage from one provider into another provider's calculator.

ProviderCost and control facts to modelMain implementation risk
Anthropic ClaudeBase input, 5-minute writes, 1-hour writes, cache hits, and output are separate rates.A longer TTL can cost more, while changes earlier in the prefix invalidate later content.
OpenAI APIEligible common prefixes can receive discounted cached input; usage reports cached tokens.Inactivity clears caches, and a changed prefix reduces reuse.
AWS BedrockCache checkpoints, model-specific minimums, reduced read rates, and model-specific TTLs.A prefix below the model minimum may run successfully without being cached.
Google GeminiContext-cache tokens and storage time have separate model-specific prices.A low request cadence can leave storage cost larger than read savings.

Anthropic's current table lists Claude Sonnet 4.6 at $3 per million base input tokens, $3.75 for 5-minute cache writes, $6 for 1-hour cache writes, and $0.30 for cache hits. Those values are a dated example, not a permanent price. Recheck the official table before using them in a quote. (Source: Anthropic pricing)

OpenAI's documented implementation starts automatic caching at prompts longer than 1,024 tokens, uses a longest matching prefix, and exposes cached_tokens in usage. AWS lists a 1,024-token cache minimum for Claude Sonnet 4.6 and a default 5-minute TTL in its current model table. (Source: OpenAI prompt caching, AWS Bedrock prompt caching)

Google's Gemini pricing page separates context-cache price from storage price and labels changes by model and date. Treat gemini prompt caching cost as a model-specific query, not one universal number. The same rule applies to openai prompt caching cost, prompt caching cost claude, and prompt caching cost bedrock. (Source: Google Gemini pricing)

Prompt cache break-even formula

Let S be stable prefix tokens, D be dynamic tokens per request, P be ordinary input price per token, W be cache-write price, R be cache-read price, Q be total requests, writes be cache writes, hits be cache reads, and storage be TTL storage cost.

Without caching:

Uncached cost = Q × (S + D) × P

With caching:

Cached cost = S × (writes × W + hits × R + misses × P) + Q × D × P + storage

Here, misses = Q - writes - hits. The formula assumes one stable prefix and excludes output tokens. Add output cost to both sides when caching changes the number or length of responses.

For a Claude Sonnet 4.6 example, use S = 10,000, D = 1,000, P = $3/MTok, W = $3.75/MTok, and R = $0.30/MTok. One write followed by 900 hits and 99 ordinary misses makes the stable-prefix cost about $5.71, compared with $30.00 without caching. The difference is before TTL storage and dynamic-token costs. (Source: Anthropic pricing)

The equation exposes the common mistake. A cache read may be cheap, but every cache write still costs money. If the prefix changes on every request, the workload pays writes without collecting enough reads.

Prompt cache hit rate scenarios

The following table keeps the Claude example above fixed at 1,000 requests and 10,000 stable tokens. It uses one cache write, no storage charge, and treats every request that is not a hit as an ordinary read of the stable prefix. The values show stable-prefix cost only.

Cache hit rateCache hitsStable-prefix costUncached baselineSaving before storage
10%100$27.34$30.00$2.66
25%250$23.29$30.00$6.71
50%500$16.54$30.00$13.46
80%800$8.44$30.00$21.56

At 10% reuse the saving is $2.66 against a $30.00 baseline, so a small TTL storage charge can consume most of it. At 80% reuse the $21.56 saving has more room before storage changes the decision. This is why prompt cache hit rate belongs in the cost ledger rather than appearing as a vanity dashboard metric.

The table is a public-data calculation using Anthropic's published multipliers and declared assumptions. It does not prove that a production application will achieve any particular hit rate. Your request cadence, prefix length, tenant isolation, and invalidation rules determine the result. Recalculate it when the provider changes rates or cache semantics. (Source: Anthropic pricing)

How to place a cacheable prompt prefix

Put content in descending order of stability. System instructions and shared tool definitions usually change less often than conversation state. A user message, retrieved result, timestamp, or tenant-specific permission should sit after the cache boundary when the provider's API supports that layout.

AWS processes cache checkpoints in an order that can include tools, system content, and messages. It warns that changing earlier content can invalidate later cache sections. Its documentation also says a prefix below the model's minimum can execute without creating a cache. (Source: AWS Bedrock prompt caching)

For Anthropic, provider-specific cache controls can use a 5-minute or 1-hour TTL. The longer option makes sense only when requests arrive often enough to pay for the higher write price. ProjectDiscovery's production write-up describes separate breakpoints for a static system prompt, static tools, and changing conversation context. That is a useful layout pattern, not a universal savings result. (Source: Anthropic pricing, ProjectDiscovery caching case)

Use one cache key per compatible tenant, model, tool schema, and instruction set. Mixing tenants or stale permissions into a shared prefix creates a correctness problem even when it improves the hit rate.

How to measure prompt caching cost

Record one row per provider request with these fields:

  • model and service tier;
  • stable prefix tokens, dynamic input tokens, output tokens;
  • cache-write tokens, cache-read tokens, and miss reason;
  • cache creation time, last hit, expiry time, and TTL;
  • provider-reported cost and the price-table version used for any estimate;
  • request outcome, latency, and tenant or workload identifier.

Langfuse warns that usage buckets must be mutually exclusive. For an OpenAI-style response, inclusive prompt tokens must be split into ordinary input and cached input before aggregation. Otherwise a dashboard can overstate spend while reporting a healthy hit rate. (Source: Langfuse cost tracking)

Keep prompt caching separate from semantic caching and RAG metrics. A cache hit can reduce input processing without reducing output tokens, tool calls, or retrieval costs. Measure those paths independently before announcing a percentage reduction. If the cached prefix sits inside an agent loop, roll the result up to AI agent cost per successful task, because a cheaper input that triggers more retries can raise the cost of a finished outcome.

FAQ

How do you do prompt caching?

Place a repeated prompt prefix at the cache boundary supported by your provider, then keep changing user content after it. Meet the model's minimum token requirement, select the appropriate TTL, and log cache writes, reads, misses, and expiry. The exact API field differs across OpenAI, Claude, Bedrock, and Gemini. (Source: AWS Bedrock prompt caching)

Does prompt caching reduce latency?

Prompt caching can reduce input processing work and may lower time to first token, but the result depends on provider, model, prefix size, request queue, and cache hit. Measure latency for matched cached and uncached requests. Do not treat a billing discount as proof of a latency improvement.

What is the prompt cache hit rate?

Prompt cache hit rate is cache-read requests divided by eligible requests, with the denominator defined clearly. Track eligible requests separately from requests whose prefixes were too short, changed, or expired. A high hit rate on a tiny prefix may save less money than a lower hit rate on a long prefix.

Is prompt caching cheaper than sending the prompt each time?

Prompt caching is cheaper when read savings exceed write, miss, and storage costs. The answer depends on prefix length, request frequency, TTL, and provider prices. Calculate uncached cost and cached cost for the same workload, then include dynamic input and output costs before choosing a cache policy.

How much does Claude prompt caching cost?

Anthropic bills cache writes, cache hits, and base input separately. Its current table lists Claude Sonnet 4.6 at $3 per million base input tokens, $3.75 for 5-minute writes, $6 for 1-hour writes, and $0.30 for hits. Those are dated values; recheck the official table before quoting them. (Source: Anthropic pricing)

How much does OpenAI prompt caching cost?

OpenAI applies a discounted cached-input rate automatically to eligible prefixes over 1,024 tokens and reports cached_tokens in the usage object rather than charging a separate write fee. The discount is model-specific, so read the current pricing page for the model you call. (Source: OpenAI prompt caching)

Related coverage

For trace and cache-event instrumentation, see our Langfuse vs Opik observability comparison. For the outcome-level rollup, see AI agent cost per successful task. For the self-hosted side of the same decision, see GPU cost per million tokens.

References