Compare Provider Caching Strategies for OpenAI, Anthropic, and Google

Introduction

When you build applications that make repeated LLM calls with overlapping content, choosing the wrong provider caching strategy can mean paying full price for tokens you've already paid for. OpenAI, Anthropic, and Google each implement caching differently — with distinct discount rates, write premiums, minimum token thresholds, and TTL windows that make one strategy optimal for a given prompt architecture and wasteful for another. By the end of this lesson, you'll be able to model each provider's caching economics using a shared configuration structure and compare expected savings across strategies for a given request pattern.

Key Terminology

• Cached Discount — the percentage reduction applied to the base input rate when tokens are served from a provider's cache; modeled as cached_discount in ProviderCacheConfig and used by the cached_cost_per_1k property to compute the effective per-call read cost.
• Write Premium — a surcharge above the base input rate charged when content is first written to a provider's cache; Anthropic's write_premium = 0.25 means initial cache population costs 25% more than standard input pricing, making it a cost investment recovered only across subsequent cache hits.
• Minimum Cacheable Tokens — the token count a prompt prefix must meet or exceed before a provider will cache it; stored as min_cacheable_tokens in ProviderCacheConfig, this eligibility gate is 1,024 for OpenAI and Anthropic but rises to 32,768 for Google's Context Caching.
• TTL (Time-to-Live) — the window in seconds before a cached entry is evicted by the provider; ttl_seconds determines how long a write-premium investment can be amortized across cache hits before the cache must be repopulated.
• Storage Cost — a per-hour fee that accumulates for as long as a cached context is retained, modeled by storage_cost_per_hour in ProviderCacheConfig; this cost is unique to Google's Context Caching and must be factored into ROI calculations for long-lived cache sessions.

Concepts

Provider Caching Is Not a Single API Knob

OpenAI, Anthropic, and Google each expose caching through a fundamentally different mechanism. OpenAI's prefix caching is automatic — any request whose leading tokens match a recently seen prefix is silently discounted at 50%, with no changes to the API call. Anthropic requires you to explicitly tag which content regions are cache-worthy using cache-control blocks; in exchange for that annotation work, the provider offers a 90% read discount, but charges a write premium on the first population. Google's Context Caching is a separate resource you create and manage through a dedicated API, persists for up to an hour, and accrues a per-hour storage fee for the duration.

The practical implication is that choosing a caching strategy is not a global preference — it is a decision that depends on your prompt architecture, request volume, and the pricing trade-offs of each mechanism. A model that compares them must represent all of these variables uniformly before it can produce a meaningful cost comparison.

The Write-Premium / Read-Discount Trade-off

The core economic tension in provider caching is between the cost to write a cache entry and the savings accumulated from reading it. OpenAI charges no write premium, so the first call costs standard input pricing and subsequent hits are simply cheaper. Anthropic inverts this: the first cache population costs more (the write premium), but cache hits return 90% of the base cost — a deeper discount than any other provider. Google sits in the middle at 75% read discount, but adds a storage fee that accumulates between requests regardless of whether hits occur.

The break-even question is: how many cache hits must occur before cumulative read savings exceed the write cost? The answer varies per provider and per workload. High-reuse workloads — where the same system prompt or document is sent across many requests — favor Anthropic's steeper discount even after the premium. Low-reuse or short-session workloads may never recover Anthropic's write cost, making OpenAI's zero-premium approach more economical despite its shallower discount.

Eligibility Gates, TTL, and the Scale Question

Not all prompts qualify for caching. Each provider enforces a minimum token threshold: OpenAI and Anthropic require at least 1,024 tokens in the shared prefix; Google requires 32,768 — a 32× higher bar that makes Context Caching viable only for very large, stable inputs like multi-document corpora or rich tool catalogs. Prompts that don't meet the threshold are never cached, so the write premium (where applicable) is never charged but neither is any discount ever earned.

TTL compounds this: OpenAI and Anthropic evict after five minutes, while Google holds context for up to an hour. A write-premium investment only recovers its cost if enough cache hits occur within the TTL window. Short TTLs favor high-frequency, bursty request patterns; longer TTLs allow the amortization of large, expensive cache writes across slower request streams.

A Shared Structure for Cross-Provider Comparison

To compare three strategies on equal footing, the lesson encodes all of these variables into a single ProviderCacheConfig dataclass — one field per economic parameter: input_cost_per_1k, cached_discount, write_premium, min_cacheable_tokens, ttl_seconds, and storage_cost_per_hour. Two computed properties, cached_cost_per_1k and write_cost_per_1k, translate these fields into per-call costs a downstream analyzer can sum across a request trace. The CacheStrategy enum tags each config as OPENAI_AUTO, ANTHROPIC_EXPLICIT, or GOOGLE_CONTEXT, and PROVIDER_CONFIGS instantiates all three with real-world pricing values. With this unified shape, the same request pattern can be replayed through each strategy to determine which produces the lowest effective token cost for a given prompt architecture (see Code Walkthrough).

Code Walkthrough

Now that you understand the structural differences between OpenAI's automatic prefix caching, Anthropic's explicit cache-control blocks, and Google's dedicated Context Caching API, the next step is encoding those differences so a single analyzer can compare them on equal footing.

The ProviderCacheConfig dataclass models every pricing variable that determines whether a strategy saves money: base input cost per 1K tokens, the discount rate on cached reads, the write premium charged when content is first written to the provider's cache, the minimum token count required for caching eligibility, TTL in seconds, and optional per-hour storage costs. CacheStrategy is an enum that tags which provider mechanism a configuration describes. Two computed properties — cached_cost_per_1k and write_cost_per_1k — translate these parameters into per-call costs the analyzer can sum across a request stream.

Code snippetpython
1from dataclasses import dataclass
2from enum import Enum
3
4class CacheStrategy(Enum):
5    OPENAI_AUTO = "openai_auto"
6    ANTHROPIC_EXPLICIT = "anthropic_explicit"
7    GOOGLE_CONTEXT = "google_context"
8
9@dataclass
10class ProviderCacheConfig:
11    strategy: CacheStrategy
12    input_cost_per_1k: float
13    cached_discount: float
14    write_premium: float = 0.0
15    min_cacheable_tokens: int = 0
16    ttl_seconds: int = 300
17    storage_cost_per_hour: float = 0.0
18
19    @property
20    def cached_cost_per_1k(self) -> float:
21        return self.input_cost_per_1k * (1.0 - self.cached_discount)
22
23    @property
24    def write_cost_per_1k(self) -> float:
25        return self.input_cost_per_1k * (1.0 + self.write_premium)
26
27PROVIDER_CONFIGS = {
28    CacheStrategy.OPENAI_AUTO: ProviderCacheConfig(
29        strategy=CacheStrategy.OPENAI_AUTO,
30        input_cost_per_1k=0.03,
31        cached_discount=0.50,
32        min_cacheable_tokens=1024,
33        ttl_seconds=300,
34    ),
35    CacheStrategy.ANTHROPIC_EXPLICIT: ProviderCacheConfig(
36        strategy=CacheStrategy.ANTHROPIC_EXPLICIT,
37        input_cost_per_1k=0.015,
38        cached_discount=0.90,
39        write_premium=0.25,
40        min_cacheable_tokens=1024,
41        ttl_seconds=300,
42    ),
43    CacheStrategy.GOOGLE_CONTEXT: ProviderCacheConfig(
44        strategy=CacheStrategy.GOOGLE_CONTEXT,
45        input_cost_per_1k=0.00125,
46        cached_discount=0.75,
47        min_cacheable_tokens=32768,
48        ttl_seconds=3600,
49        storage_cost_per_hour=0.0000044,
50    ),
51}

PROVIDER_CONFIGS instantiates all three strategies with real-world pricing values. OpenAI applies a 50% discount on cached reads with no write premium, but requires at least 1,024 shared prefix tokens to qualify and evicts after five minutes. Anthropic offers a steeper 90% read discount in exchange for a 25% write premium on the first cache population — a trade-off that rewards workloads where the same content block is reused across many requests. Google's Context Caching operates at a different scale entirely: the 75% discount applies only to contexts of at least 32,768 tokens, cached sessions can persist for up to an hour, and a per-hour storage fee accumulates for as long as the context is retained. Passing these three configs into the ProviderCacheAnalyzer built later in this chapter lets you replay the same request trace through each strategy and determine which produces the lowest effective token cost for your prompt architecture.

Confirm that cached_cost_per_1k for the Anthropic config evaluates to 0.015 * 0.10 = 0.0015 and write_cost_per_1k evaluates to 0.015 * 1.25 = 0.01875 — if both match, the computed properties are correctly wired and PROVIDER_CONFIGS is ready to feed the ROI analyzer.

Do's and Don'ts

Having walked through the material above, the following Do's and Don'ts distill it into practice.

Do's

1. ✓Do include write_premium in every first-write cost calculation via write_cost_per_1k — Anthropic charges 25% above the base input rate on the first cache population, so the 90% read discount only wins after enough cache hits amortize that upfront cost; skipping the premium makes Anthropic look universally cheaper than OpenAI's no-premium 50% discount and breaks ROI comparisons.
2. ✓Do verify min_cacheable_tokens against your prompt's shared-prefix length before selecting a strategy — Google's Context Caching requires at least 32,768 tokens to qualify for its 75% discount, while OpenAI and Anthropic both gate at 1,024; a prompt architecture below 32,768 tokens renders CacheStrategy.GOOGLE_CONTEXT ineligible regardless of its discount rate.
3. ✓Do use the cached_cost_per_1k and write_cost_per_1k computed properties to feed ProviderCacheAnalyzer — these translate cached_discount and write_premium into per-call costs using a consistent formula (input_cost_per_1k * (1 - cached_discount) and input_cost_per_1k * (1 + write_premium)); re-deriving that math inline risks sign-convention drift that silently misprices one strategy against another across a request trace.

Don'ts

1. ✗Don't omit storage_cost_per_hour when projecting Google Context Caching savings — the $0.0000044/hr fee accumulates for the full retention window (up to 3,600 seconds in the config), and for long-lived or high-volume sessions it can erode or eliminate the savings that the 75% read discount appears to offer when only the per-token rates are compared.
2. ✗Don't treat Anthropic's 90% read discount as a strict win over OpenAI's 50% — the 25% write premium means Anthropic's first-write write_cost_per_1k (0.01875) runs 25% above its own base input rate, so the strategy is only economical on workloads where the same cache_control block is reused frequently enough that the 90% read discount amortizes that upfront write premium across many requests.
3. ✗Don't hardcode provider identity as a string when keying into PROVIDER_CONFIGS — CacheStrategy is an enum precisely so the analyzer can index each ProviderCacheConfig unambiguously and replay the same request trace across all three strategies without branching on raw string comparisons that break when a new strategy variant is added.