Comparing Prefix Caching Rules Across Three Providers

The three providers below are Anthropic (Claude), OpenAI, and Claude served through Google's Gemini Enterprise Agent Platform, which is a useful third case because it runs the same models under a different operational wrapper.

How breakpoints are declared

Anthropic offers two modes. Automatic caching adds a single top-level cache_control field, and the system applies the breakpoint to the last cacheable block and moves it forward as the conversation grows. Explicit caching places cache_control on individual content blocks for fine-grained control Anthropic docs. The docs recommend automatic caching as the simplest start, particularly for multi-turn conversations.

OpenAI's model is different: caching is applied automatically on prompts that qualify, and you cannot and need not place a breakpoint OpenAI's announcement. The API caches the longest prefix previously computed, and the guide describes the cache as storing KV tensors rather than tokens OpenAI guide.

The portability rule: never hard-code cache_control at call sites. Put marker emission behind one function that takes the prompt parts and the provider name, and returns either markers or nothing.

How long the cache lives

Anthropic's default lifetime is 5 minutes, refreshed at no additional cost each time the cached content is used. A 1-hour tier exists at a higher write premium. Crucially, the lifetime is measured from the start of the request that writes or reads the entry, not from the end of its response, so a 4-minute streaming response leaves roughly 1 minute for the next request to arrive Anthropic docs. Technspire's analysis of the pricing mechanics reaches the same conclusion: long-streaming agent turns eat their own TTL Technspire.

OpenAI states caches are typically cleared after 5 to 10 minutes of inactivity and are always removed within one hour of last use OpenAI announcement.

Through Google's platform, the behavior follows Anthropic's documentation, with one operational addition worth knowing: caches are scoped to your Google Cloud project and cannot be used by other projects, and an administrator can disable explicit caching for a project, after which requests with caching enabled are rejected Google Cloud's Claude prompt caching page.

The portability rule: record a TTL assumption per deployment in configuration, and size your scheduling to it. If your job runs every 12 minutes, a 5-minute cache will miss on every run and you will pay the write premium forever.

Minimum prefix length before caching applies

OpenAI applies caching automatically on prompts longer than 1,024 tokens, caching the longest previously computed prefix starting at 1,024 tokens and increasing in 128-token increments OpenAI announcement.

Anthropic sets a per-model minimum, and it is not monotonic across generations. One implementation guide tabulates minimums ranging from 512 tokens on newer Opus and Fable models, 1,024 on Sonnet 5 and Sonnet 4.6, 2,048 on Opus 4.7, and 4,096 on Opus 4.6, Opus 4.5 and Haiku 4.5, and notes that a prefix under the minimum silently does not cache: you see a cache creation count of zero and keep paying full price Hidekazu Konishi's guide. Technspire's page repeats those per-model minimums Technspire.

The portability rule: assert the minimum in code. Before shipping, count the tokens of the stable prefix and compare against the smallest minimum among the models you route to, not just the model you tested on.

The table compiles the published rules. Read the "rule it implies" column as the thing to write into your own code.

The best rule from Anthropic's own documentation, as quoted by a walkthrough of the docs: place the breakpoint on the last block that stays identical across requests. For a prompt with a static prefix and a varying suffix such as a timestamp, per-request context or the incoming message, that is the end of the prefix, not the varying block the breakpoint walkthrough.

The hash is cumulative. It covers everything up to and including the breakpoint, so editing any block at or before the mark produces a different hash next time. Invalidation follows a hierarchy: tools, then system, then messages, and a change at each level invalidates that level and all later levels breakpoint walkthrough. Practically: changing a tool definition loses everything; changing tool choice or adding an image affects only the message blocks.

This is the same failure the Claude Code team built around. An engineer on that team described prompt caching as the architectural constraint the whole product is built on, and the team declares incidents when hit rates drop. Adding an MCP tool, putting a timestamp in the system prompt, or switching models mid-session can each invalidate the cache and multiply the cost of that turn Claude Code caching analysis.

The most common silent mistake is a dynamic system prompt. A timestamp at position zero means every request writes a new cache entry and reads none, with no error and no warning, just cache creation tokens on every call and read tokens always zero breakpoint walkthrough. Minh Le Duc's cost model puts a number on it: a timestamp in the system prompt cost 7.8x on an 80-turn session, not because the timestamp is expensive but because it forfeits the discount on every turn Minh Le Duc.

Take an agent that sends a 20,000-token stable prefix (tool definitions, system instructions, reference docs) on every call, with a variable user message after it. Assume a Sonnet-tier model at 1,024-token minimum and a 5-minute TTL with a 1.25x write premium and a 0.1x read rate, the multipliers Anthropic publishes Technspire.

Three scenarios over 100 requests, all arriving within the TTL window:

The miss case is the one teams do not plan for, and it is worse than no caching at all. The break-even is low: Technspire frames it as the 5-minute tier paying for itself after one cache read, because 1.25x write plus 0.1x read is 1.35x against 2x for two uncached passes Technspire.

Now change traffic. If requests arrive every 12 minutes, a 5-minute cache never survives, and every call is a write at 1.25x. Moving to the 1-hour tier at a 2x write still beats repeated 5-minute writes, and the read refreshes the lifetime at the read price Technspire. That is the decision rule in one line: compare your inter-request gap to the TTL before choosing a tier, then verify with the token counts in the response.

On pricing levels generally, published comparisons of the cross-provider economics report cache reads between 0.025x and 0.1x of base input, and note that a write pays for itself after one reuse at the 1.25x tier and two at the 1-hour tier Firecrawl. Check current rates against the provider's own pricing page before forecasting.

Four habits make a provider swap a configuration change.

Order content by stability. Tool definitions first, then system instructions, then reference material, then conversation history, then the live user message. Any change invalidates that block and everything after it, so dynamic data must live at the very end Digital Applied. The same source reports one team moving dynamic working memory out of the system prompt into a user message at the end, taking a cache hit rate from 7% to 84% Digital Applied.

Route markers through one function. Something like this, where the provider decides whether anything is emitted at all:

def build_messages(parts, provider, ttl_seconds):
    # parts: ordered list of {"role": ..., "text": ..., "stable": bool}
    blocks = [{"type": "text", "text": p["text"]} for p in parts]
    if provider == "anthropic":
        last_stable = max(i for i, p in enumerate(parts) if p["stable"])
        blocks[last_stable]["cache_control"] = {"type": "ephemeral"}
    # openai and other automatic providers: no marker needed
    return blocks

The function reads the stable flag rather than trusting the caller to put markers in the right place. That makes the breakpoint reproducible across call sites and reviewable in one diff.

Put TTL assumptions in configuration. A key per deployment (provider, model class, TTL tier, minimum prefix tokens) means changing providers edits a config file. It also lets you fail fast when a scheduled job's interval exceeds the TTL.

Normalize cache metrics from each response. Anthropic reports cache creation and cache read input tokens separately, and total prompt size is the sum of the three fields, which means input_tokens is only the uncached remainder Technspire. OpenAI reports a cached tokens value inside the usage details OpenAI announcement. Map both into one internal record: read tokens, write tokens, uncached input, model, and a request ID. Then alert on the ratio of read to total input per route, not on the raw bill, because the bill moves with traffic while the ratio moves with structure.

If you route across several model families and would rather not maintain a per-provider adapter for each one, an OpenAI-compatible gateway such as Quanta Inference lets you keep one key and one request shape while you decide which provider sits behind it.

Run this before you switch providers or ship a new prompt layout.

• The stable prefix is contiguous and sits at the very start of the request.
• No timestamps, request IDs, session state or user names appear before the breakpoint.
• Token count of the stable prefix exceeds the smallest per-model minimum on every model you route to.
• Cache markers are emitted by one function and covered by a unit test that asserts marker position.
• TTL is set in configuration, and your request interval is shorter than it, or you use a longer tier.
• Tool definitions are versioned and do not change between deploys without a deliberate cache reset.
• Each response's cache read and cache write counts are logged and normalized into one metric.
• A dashboard shows read-to-input ratio per route, with an alert threshold.
• One test request runs twice in a row and asserts that the second reads from cache.

The last item is the cheapest test in the list and catches every silent failure described above. If the second call reports zero read tokens, something before the breakpoint changed, and no amount of prompt tuning will fix it.