# Gemini context caching: the only cache that bills you for doing nothing
*Google charges no write premium and no read penalty. It charges rent. That inverts the entire decision — the question isn't how often you send requests, it's how many reads per hour you can put through a cache before the storage fee eats the discount.*
---
Anthropic and OpenAI both sell caching as a bet on timing: pay a premium up front, collect discounts if you come back soon enough. Google sells something structurally different. Creating a cache is free — you're [billed for the input tokens used to create it at the standard input token price](https://docs.cloud.google.com/gemini-enterprise-agent-platform/models/context-cache/context-cache-overview), with no multiplier. Reading it is 90% off, same as everyone.
What you pay for is *keeping* it. Explicit caching bills a per-token, per-hour storage charge for as long as the cache resource exists, whether or not anything ever reads from it.
That single difference changes every conclusion in this series. Cadence stops mattering. Inventory starts.
Vocabulary in [the glossary](/updates/llm-prompt-caching-what-it-is-and-key-terms-explained); the cross-provider chart is in [pricing 101](/updates/llm-prompt-caching-pricing-guide-and-cost-breakdown).
## Two mechanisms, and only one of them can hurt you
> **Cost shape:** implicit is free to hold and best-effort. Explicit is guaranteed and metered.
**Implicit caching** is [enabled by default for all Gemini 2.5 and newer models](https://ai.google.dev/gemini-api/docs/caching), passes savings on automatically, requires no code, and carries no storage fee. The trade is that it's opportunistic — Google's framing throughout is that implicit offers no cost-saving guarantee. Minimums are 2,048 tokens on the 2.5 line and 4,096 on the 3.x Flash models and 3.1 Pro Preview.
**Explicit caching** is a resource you create with a TTL, reference by name, and are responsible for deleting. It's the one that [guarantees savings](https://ai.google.dev/gemini-api/docs/generate-content/caching), and the one that charges rent.
One architectural note that catches teams mid-migration: **explicit caching is not supported in the Interactions API**, which is now GA and the recommended surface. [To use explicit caching you stay on the generateContent API](https://ai.google.dev/gemini-api/docs/caching) — currently labelled Legacy in Google's own navigation. If your roadmap includes moving to Interactions, your explicit caching strategy needs a plan that survives it.
## The break-even is reads per hour
> **Rule:** below roughly three reads per hour per prefix on the Pro tier, explicit caching costs more than not caching.
The arithmetic is simple and worth internalising, because it's the opposite shape to every other provider's. Divide the hourly storage rate by the per-token saving on a read:
**break-even reads/hour = storage rate ÷ (input rate − cached rate)**
Because the cached rate is a flat 10% of input across the lineup, that reduces to storage ÷ (0.9 × input). Run it against [published rates](https://ai.google.dev/gemini-api/docs/pricing):
| Model (Developer API, standard) | Input | Cached read | Storage/hr | Break-even reads/hr |
|---|---|---|---|---|
| Gemini 3.1 Pro Preview (≤200k) | $2.00 | $0.20 | $4.50 | **2.5** |
| Gemini 3.1 Pro Preview (>200k) | $4.00 | $0.40 | $4.50 | 1.25 |
| Gemini 2.5 Pro (≤200k) | $1.25 | $0.125 | $4.50 | **4.0** |
| Gemini 3.7 / 3.6 Flash | $0.75 | $0.075 | $0.50 | 0.74 |
| Gemini 3 Flash Preview | $0.50 | $0.05 | $1.00 | 2.2 |
| Gemini 2.5 Flash | $0.30 | $0.03 | $1.00 | 3.7 |
| Gemini 3.1 Flash-Lite | $0.25 | $0.025 | $1.00 | 4.4 |
All per million tokens, paid tier, standard processing, 2026-08-14. Several are preview models and 3.7/3.6 Flash carry promotional rates through 31 December 2026 — both input and storage double on 1 January 2027, which happens to leave the break-even unchanged.
Two readings of that table. The obvious one: **the Pro tier is where explicit caching pays**, because the absolute dollar gap per read is wide enough to clear $4.50 of rent. The counterintuitive one: **Flash-Lite has the worst ratio**, not the best. Cheap input means a small absolute saving per read against a storage fee that barely moves. On the low-cost models, lean on implicit caching and reserve explicit for genuinely heavy reuse.
Concretely, on 3.1 Pro with a 100k prefix: storage runs $0.45/hour and each read saves $0.18. At one read an hour you pay $0.47 against $0.20 uncached — more than double. At three reads you're finally ahead. At fifty reads an hour you're paying $1.45 against $10.00.
## The failure mode with no ceiling
> **The trap:** on every other provider a forgotten cache costs nothing. Here it costs until the TTL expires.
Anthropic and OpenAI caches evaporate on their own and cost you exactly the write you already paid for. A Gemini explicit cache is a resource with a meter attached, and the TTL [defaults to one hour if you don't set one](https://ai.google.dev/gemini-api/docs/generate-content/caching), with no minimum or maximum bounds on what you can set.
A forgotten 1M-token cache on 3.1 Pro:
- 1 hour — **$4.50**
- 1 day — **$108**
- 1 week — **$756**
With nothing reading it. Anthropic's docs note you cannot manually clear a cache; Google's give you [`caches.delete`](https://ai.google.dev/gemini-api/docs/generate-content/caching), and you need it. This is the only provider where cache lifecycle management is an operational requirement rather than a nicety.
Practical consequence: set the TTL to cover your actual burst of reuse rather than accepting the default hour, and delete on job completion in a `finally` block, not on the happy path. You can also [update the TTL or expiry](https://ai.google.dev/gemini-api/docs/generate-content/caching) on a live cache, which makes extend-as-needed a better default than provision-for-the-worst-case.
## Scenario one: the orchestrator waiting on sub-agents
> **Verdict:** the trap. Idle time is exactly what you're billed for.
This is where porting an Anthropic mental model costs real money. On Anthropic, long gaps are the argument *for* buying a longer TTL. On Gemini explicit caching, long gaps are the argument *against* caching at all — an orchestrator that dispatches work and waits 12 minutes is paying rent through every one of those minutes and reading nothing.
Eight orchestrator turns over 90 minutes is 5.3 reads/hour, which clears the 3.1 Pro break-even of 2.5 — but not by much, and only if the cache is scoped tightly to the 90 minutes and deleted afterwards. Accept the default 1-hour TTL on a run that finishes in 20 minutes and you've paid 40 minutes of rent for nothing.
The better answer for most orchestrators is implicit caching plus a stable prefix. You lose the guarantee and keep the free ride.
## Scenario two: the fast sub-agent
> **Verdict:** implicit, almost always.
Tight loops generate high read rates, which is exactly what the storage fee wants. But sub-agents are usually short-lived, and the storage fee is charged on wall-clock time regardless — a sub-agent that fires 40 requests in 90 seconds and exits has a superb read rate and a cache resource that will keep billing until its TTL expires unless you delete it.
Since implicit caching is on by default, costs nothing to hold, and rewards exactly this traffic shape ([Google's advice is to send requests with similar prefixes in a short amount of time](https://ai.google.dev/gemini-api/docs/caching)), the explicit machinery is mostly overhead here. Reach for it only when the sub-agent's prefix is large, shared across many concurrent workers, and long-lived enough to justify the lifecycle code.
## Scenario three: the chatbot
> **Verdict:** depends entirely on whether the context is shared.
A **single-user chatbot** is the classic loser. One user against a 50k-token context generates a handful of reads an hour while storage runs continuously. Below the break-even, you're subsidising the discount.
A **multi-user chatbot over shared context** — same document set, same system instructions, many concurrent sessions — is the classic winner, and it's the case Google names first: [chatbots with extensive system instructions](https://ai.google.dev/gemini-api/docs/generate-content/caching). Aggregate reads across all users against one cache resource and the rent amortises to nothing. Ten users at 15 queries a day each is well past any break-even in the table.
The determining variable isn't the product shape. It's **how many readers share one cache resource.** One cache, many readers, is the only configuration where explicit caching reliably wins.
## Scenario four: high-volume single-shot extraction
> **Verdict:** the unambiguous win, and the only scenario where explicit is obviously right.
Thousands of documents an hour against a fixed instruction block and schema. Reads per hour are enormous, so the storage fee amortises into irrelevance — at 500 reads/hour on 3.1 Pro with a 100k prefix, rent is $0.45 against $90 of avoided input cost.
Three things to get right.
**Scope the cache to the job.** Create at batch start, delete at batch end, set the TTL to the expected run length rather than the default hour. The whole risk here is a pipeline that fails halfway and leaves the resource behind.
**Cached content is a prefix.** Google is explicit that [the model makes no distinction between cached and regular input tokens; cached content is a prefix to the prompt](https://ai.google.dev/gemini-api/docs/generate-content/caching). Instructions and schema go in the cache; the document goes in the per-request content. Same discipline as everywhere else.
**Watch the Cloud Storage interaction.** If you're caching objects held in a GCS bucket, [don't modify those objects until the cached content expires or is deleted](https://docs.cloud.google.com/gemini-enterprise-agent-platform/models/context-cache/context-cache-overview) — updates can render the cached contents unusable. Extraction pipelines that refresh source files mid-run can invalidate their own cache without any obvious signal.
## What to log, and the number that isn't there
`cachedContentTokenCount` on Vertex, `usage.total_cached_tokens` via the Interactions API, and `usage_metadata` from the cache service's create, get, and list operations.
Now the important part: **none of those is the storage fee.** Storage accrues against a cache resource on wall-clock time. It appears on no per-request counter, in no response object, and in no request log. It is structurally invisible to request-level observability — which is precisely why teams find it on the invoice rather than in the dashboard.
The metric that matters therefore can't be derived from request logs alone. You need a join: reads per hour per cache resource, against the set of live resources from `caches.list()`. An orphaned-cache audit — resources with zero reads in the last hour — is a five-line script and the single highest-value piece of instrumentation on this provider.
## Free writes, expensive shelf space
Google made the trade that looks most generous at the point of adoption. Nothing costs extra to create; implicit caching is on by default and genuinely free; the read discount matches everyone else's.
The bill arrives for storage, and it arrives on a dimension no other provider has, tracked by no counter you're already watching. Which produces a rule you can hold in your head and a discipline you have to build: **below roughly three reads an hour, don't cache explicitly — and whatever you do cache, delete.**
That closes the series. [The glossary](/updates/llm-prompt-caching-what-it-is-and-key-terms-explained), [pricing 101](/updates/llm-prompt-caching-pricing-guide-and-cost-breakdown), [Anthropic](/updates/llm-prompt-caching-anthropic-how-to-and-pro-tips), [OpenAI](/updates/llm-prompt-caching-openai-how-to-and-pro-tips).
*Coolhand Labs tracks inference pricing across providers — including the per-hour storage dimension that most model catalogs have no field for. [See what we track](https://coolhandlabs.com/inference-apis).*