Gemini Implicit Caching vs Claude Explicit Caching

Short version: Gemini caches for you, Claude caches when you ask it to. On Gemini 2.5 and newer models, implicit caching is switched on by default, costs nothing to set up, and discounts any repeated prefix it happens to catch. On Claude, you opt in with a cache_control field, pay a small premium to write the cache, and in return get a hit every time an identical prefix comes back inside the cache lifetime. Gemini wins on zero effort. Claude wins on predictability and control.

That difference matters more than it sounds, because cached tokens are where most of an agent's input bill goes. This comparison is built from Google's Gemini API caching docs, its pricing page and the Google Cloud context caching overview, plus Anthropic's prompt caching documentation, all checked on 20 October 2026. We haven't benchmarked hit rates ourselves, so every price and limit below comes from the vendors, and the cost examples are plain arithmetic on list prices. If you only use Claude, our step-by-step guide to Claude prompt caching goes deeper on breakpoints and TTLs.

Gemini vs Claude Caching at a Glance

Two rows decide most of the comparison. The guarantee row says Gemini's discount is opportunistic and Claude's is contractual within its time window. The manual cache objects row says that on Google's newest flagship, implicit caching is now the only kind there is, so "explicit vs implicit" on Gemini 4 Argon isn't a choice any more.

The Core Difference: Automatic Matching vs a Marked Prefix

Both systems do the same job under the hood: they keep the processed state of the front of your prompt so the next request with the same front can skip recomputing it. Google's docs describe the cached content as "a prefix to the prompt", and Anthropic's say the cache covers the prompt "up to and including" the block you mark. Neither changes the answer. Anthropic states that responses are identical with or without caching, and Google notes the model doesn't distinguish cached tokens from regular input tokens.

The difference is who decides what the prefix is. Gemini's implicit cache looks for repeated beginnings on its own and passes on the saving if it finds one. Claude only caches what you mark, either with one top-level field that lets the API place the breakpoint on the last cacheable block, or with up to four breakpoints you place by hand.

Honest answer: implicit caching is the better default for teams that never think about caching, and explicit caching is better for teams that do. If you run a long-lived agent with a big system prompt, the marked prefix gives you something you can design around and debug. If you run lots of small, unrelated calls, Gemini's free-by-default approach saves money you would never have chased.

How Gemini Implicit Caching Works

Implicit caching is enabled by default for all Gemini 2.5 and newer models, and Google says it works in both stateful mode (continuing with previous_interaction_id) and stateless mode. There's nothing to configure. When a request hits the cache, you're billed the lower cached-input rate for those tokens.

Minimum lengths

The Gemini API lists a minimum of 4,096 input tokens for Gemini 4 Argon, Gemini 3.8 Flash, Gemini 3.6 Flash and Gemini 3.1 Pro Preview, and 2,048 for Gemini 2.5 Flash and Pro. Google Cloud's Agent Platform page lists a higher implicit minimum of 6,144 tokens for a few models, including Gemini 3.8 Flash and 3.1 Pro Preview, so check the page for the platform you actually call.

How to raise your hit rate

Google gives two tips, and they're the whole playbook: put large, common content at the beginning of your prompt, and send requests with a similar prefix within a short time. On the Interactions API, Google adds that continuing a conversation with previous_interaction_id lets the system "more easily utilize implicit caching for the conversation history". If you've been rebuilding the full history client-side on every turn, switching to server-side state is the simplest caching upgrade available. We cover that API in our Gemini 4 Argon explainer.

How long entries last

The Gemini API page doesn't publish a lifetime. Google Cloud's overview is more specific: implicit caching keeps prefixes in memory, moves evicted ones to a durable tier on supported models (Gemini 4 Argon and Gemini 3.8 Flash among them), and expires a prefix "no later than 24 hours after it's created", with most entries evicted earlier. There are no storage costs for implicit caching.

Seeing it work

Cache hits show up as usage.total_cached_tokens in the Interactions API, in usage_metadata on generateContent, and as cachedContentTokenCount on Google Cloud. That number is your only feedback. Google doesn't document a field that explains why a request missed.

How Claude Prompt Caching Works

Claude gives you two ways to switch caching on. Automatic caching is one top-level cache_control: {"type": "ephemeral"} field: the API places the breakpoint on the last cacheable block and moves it forward as the conversation grows. Explicit breakpoints put cache_control on specific blocks, up to four per request, so you can cache a system prompt separately from a growing history. Automatic mode uses the same infrastructure, prices and minimums as manual breakpoints.

The prefix is strict

The cache covers tools, then system, then messages, in that order, and the match has to be exact. Change a tool definition and everything after it is invalidated. Put a timestamp inside the cached block and you write a fresh cache on every call without ever reading one. The lookback for earlier cache entries reaches 20 blocks.

Lifetime and cost of writing

Entries last 5 minutes by default and refresh free each time they're used. Add "ttl": "1h" for an hour. The catch is the write premium: 1.25x the base input price for the 5-minute cache and 2x for the 1-hour cache. Anthropic's pricing page says caching pays off after one cache read for the 5-minute duration, or after two reads for the 1-hour one.

Minimums and feedback

The current Claude models (Opus 5.5, Sonnet 5.5, Haiku 5.5 and Fable 5.1) cache prompts from 512 tokens, eight times lower than Gemini's 4,096. Shorter prompts are silently not cached. Every response reports cache_creation_input_tokens and cache_read_input_tokens, and Anthropic's cache diagnostics feature can return a cache_miss_reason such as system_changed or tools_changed when you pass the previous message ID. That one feature makes Claude's cache far easier to debug.

Pro tip: On Claude, a 1,000-token system prompt is worth caching. On Gemini 4 Argon it's below the 4,096-token floor, so it never caches no matter how often you send it.

What Happened to Gemini Explicit Caching?

Gemini did have a Claude-style option, and on older models it still does. Explicit context caching lets you create a cache object with caches.create (or POST v1beta/cachedContents), give it a TTL, and reference it by name with cached_content. The TTL defaults to one hour with no minimum or maximum on the Gemini API, and you can update only the TTL or expiry afterwards. Google describes it as the option with a "cost saving guarantee", at the price of "some added developer work". It's still in Beta on v1beta endpoints.

It has two costs implicit caching doesn't: a reduced rate on cached tokens plus storage billed per hour. On Gemini 3.8 Flash, cached input is $0.075 per 1M tokens and storage is $0.50 per 1M tokens per hour through 31 December 2026. A 50,000-token cache kept for an hour costs about $0.025 in storage at that rate.

And it's going away at the top end. Google's docs say explicit caching is not supported for Gemini 4 Argon "and onward", and it isn't supported in the Interactions API either. The Gemini 4 Argon migration checklist tells you to remove any calls that create or reference cached_content. So the honest framing in October 2026 is: explicit caching is a Gemini 3.x and 2.5 feature on the legacy generateContent API, and implicit caching is Google's direction.

Pricing Side by Side

Here are the cache prices for the models most people compare, per 1M tokens, standard tier, from each vendor's pricing page on 20 October 2026.

Per hit, the flagships are closer than you'd think. Gemini 4 Argon at its intro price and Claude Sonnet 5.5 both charge $0.10 per 1M cached tokens, and Opus 5.5 matches Argon's post-December $0.20. Both vendors also discount cache reads on their Batch tiers: Gemini 4 Argon's batch cache price is $0.05, and Anthropic says its caching multipliers stack with the 50% Batch discount. For the full model-level price picture, see our Gemini 4 Argon vs Claude Opus 5.5 comparison.

A Worked Example: The Same Agent on Both

Take an agent with a 50,000-token stable prefix (tool definitions, a long system prompt and a reference document) that makes 20 requests a few seconds apart. Count only the prefix, assume the first request misses and the other 19 hit, and use list prices. This is arithmetic, not a measurement.

On paper the two approaches land within a few cents of each other, and both cut the prefix bill by roughly 90%. The real difference is the word "assume". With Claude, if the 19 follow-ups arrive inside the 5-minute window with a byte-identical prefix, you get those hits. With Gemini, Google tells you there's no guarantee, so the realistic range for Argon runs from about $0.20 up to the full $2.00. In return, Gemini never charges you a write premium for a cache you didn't reuse, and Claude does.

That reference document in the stable prefix is often scraped web content. If you build prefixes from docs or competitor pages, Firecrawl turns them into clean markdown first, which keeps the cached block both smaller and identical from run to run.

How to Get Cache Hits on Both

The good news is that one prompt layout serves both vendors. Every rule below comes straight from the two sets of docs.

1. Front-load the big, stable content. Tools, system instructions, long documents and examples go first. Google's top tip and Claude's prefix order (tools, system, messages) agree.
2. Keep it byte-identical. No timestamps, request IDs, shuffled tool lists or per-user greetings inside the cached part. Put anything that changes after it.
3. Clear the minimum. 4,096 tokens on Gemini 4 Argon and 3.8 Flash, 512 on current Claude models. A prefix just under Gemini's floor gets no discount at all.
4. Send the next request soon. Claude's default window is 5 minutes. Google only says "a short amount of time", so treat short as the rule.
5. Use server-side state on Gemini. previous_interaction_id helps implicit caching catch the conversation history.
6. Mark the end of the stable block on Claude. Automatic mode is fine for chat; a manual breakpoint on the last unchanging block is better when a dynamic block follows.
7. Watch the usage fields every run. Cached tokens near zero on a long, repeated prompt means something in the prefix is changing.

Context engineering and caching pull in the same direction here: a well-structured context with a stable core and a small changing tail is also the cheapest one to send. We explain that mindset in what context engineering is.

Want a second pair of eyes on a real prompt? Paste it into an agent with this audit prompt.

Agents and Long Runs: Where Each One Shines

Claude's documentation is written for agent loops. Anthropic's cost guide says to turn on prompt caching "before any other lever" and reports that in its own traffic, agent loops read a median of 84% of input from cache. That's Anthropic's figure, not ours, but it shows the scale: a 40-turn task resends its first turn 40 times. Claude also gives you the tools to protect that hit rate, from the 1-hour TTL for agents that pause between steps to cache diagnostics when a turn suddenly costs more. Claude Code, Anthropic's own coding agent, caches automatically, which we touch on in Claude Code vs Google Antigravity.

Gemini shines where you don't control the loop. Long-decode runs on Gemini 4 Argon re-send their growing input across server-side hops, and Google's long-decode guide notes that the repeated input is discounted by implicit caching without any work from you. The same applies to a busy chatbot with one shared system prompt across many users in the same project: the cache can warm up on traffic you never coordinated.

Privacy, Isolation and Turning It Off

Both caches are walled off from other customers. Google Cloud isolates cached data by project number and never shares it across projects, and recommends scoping cached data to each user session in multi-tenant agents. Anthropic isolates caches per workspace on the Claude API (per organization on Bedrock and Google Cloud), never across organizations.

The control is different, though. On Google Cloud you can disable the durable tier or implicit caching entirely, and the zero data retention page explains how. On Claude, nothing is cached unless you ask, and entries can't be cleared manually; they expire after their 5-minute or 1-hour lifetime.

Which One Should You Use?

The Verdict

Claude's explicit caching is the better system for engineers. You decide what's cached, you know how long it lives, a 512-token minimum means even modest prompts qualify, and diagnostics tell you what broke. The write premium is small and pays for itself after one hit on the 5-minute cache.

Gemini's implicit caching is the better default. It's free, it's on, and on Gemini 4 Argon the hit price matches Claude Sonnet 5.5. Its weakness is the lack of a promise: you can make hits likely, but you can't make them certain, and prompts under 4,096 tokens never qualify.

My take: design every prompt for caching regardless of vendor (stable content first, changing content last), then let the vendor's model do the rest. On Claude, add the breakpoint. On Gemini, check total_cached_tokens and move to server-side state. Either way, the layout is the part that actually saves money.

Caching cuts the cost of the prompt you send. The research that goes into that prompt still takes time, and Genspark is the general-purpose agent we'd use to gather docs and sources before you build the prefix.

Keep Reading

• How to use Google Antigravity with Gemini 4 Argon
• 25 best Claude Opus 5.5 prompts for coding
• Claude Opus 5.5: what's new, specs and when to use it