You send the same 40,000-token prompt 1,200 times a day — and pay for it 1,200 times. Google Gemini can store that prefix once and charge a fraction on every reuse. That is context caching, and it is the cheapest input tokens in the modern LLM stack.
This guide explains context caching Gemini pricing end to end: how implicit caching differs from explicit caching, what the $0.075 per million cached tokens actually buys you, when storage fees matter, and how the same workload compares to Bedrock and OpenRouter. Every figure is reproducible in the AI cost calculator.
What Gemini context caching actually does
Context caching stores a repeated prefix — system instructions, tool schemas, retrieved documents — so the model does not re-process it from scratch on each request. You send the prefix once (or the platform detects it), then send only the variable part.
- Cached tokens are the stored prefix tokens you reuse on every request.
- Uncached tokens are everything else in the request.
- Storage is the per-hour cost of keeping an explicit cache alive.
The platform charges cached tokens at a deep discount, uncached tokens at full rate, and storage separately when you create an explicit cache.
Gemini 3.8 Flash pricing: the numbers that matter
Gemini 3.8 Flash is the clearest example of how Google prices caching, because the discount is 90%:
| Token class | Per 1M tokens | What it means |
|---|
| Uncached input | $0.75 | Every token outside the cached prefix |
| Cached input | $0.075 | Every token read from cache |
| Storage | Per MTok-hour | Explicit caches only; minimum billing window applies |
| Output | $3.75 | Every generated token, cache or not |
Two implications follow. First, cached input is an order of magnitude cheaper than uncached input. Second, output is 50× cached input — so caching helps only if input dominates.
A workload you can recognise
Support assistant on Gemini 3.8 Flash: 40,000-token prefix, 2,000 tokens of conversation per request, 500 output tokens, 36,000 requests a month.
| Scenario | Input cost | Output cost | Total |
|---|
| No cache | $1,134 | $68 | $1,202 |
| 80% cache hit | $356 | $68 | $424 |
| 100% cache hit | $162 | $68 | $230 |
At an 80% implicit hit rate the bill falls 65%. No writes, no TTL arithmetic. That simplicity is the entire pitch of implicit caching.
Implicit vs explicit caching: different products
Google offers two mechanisms with opposite cost shapes. Choosing the wrong one is the most common mistake.
Implicit caching: automatic, free to enter, no control
- You change nothing. Google detects a repeated prefix and bills cached tokens at $0.075.
- No write premium, no storage fee, no API change.
- You do not control the hit rate. It depends on prefix reuse, routing, and platform behaviour.
- Best for: steady traffic with a stable prefix, where you can tolerate a best-effort hit rate.
Explicit caching: a resource you create and own
- You create a cache with a token count and a time-to-live (from minutes to hours).
- You pay cached rates on every read plus storage per token-hour, with a minimum billing window.
- You control exactly how long the prefix lives, which matters for bursty traffic.
- Best for: large stable corpora, spiky traffic, predictable budgets.
Rule of thumb: if traffic is steady, start implicit. If you need a guaranteed hit rate, go explicit and pay for storage.
Explicit caching: the storage math
Explicit caches charge storage per million token-hours. The calculation is straightforward but easy to underestimate:
storage_cost = cached_tokens x storage_rate x hours
Example: 40,000 tokens at $4.50 per MTok-hour for 24 hours
= 0.04 x 4.50 x 24 = $4.32 per day
That storage cost replaces the write premium you would pay on Bedrock. Whether it is cheaper depends entirely on how long the cache lives and how often it is read. A cache that is read 1,000 times in a day is worth a few dollars of storage. A cache that is read twice is not.
Minimum billing windows also apply: even if you delete the cache after one minute, you pay for the full minimum window. Check the current minimum in the pricing documentation before you commit.
When explicit caching beats implicit
- The corpus is large and stable enough that a guaranteed cache justifies a storage line item.
- Traffic arrives in bursts with long gaps, so implicit reuse would be discarded between bursts.
- You need a predictable hit rate for budgeting rather than a best-effort one.
- You serve a few tenants with very different prefixes that would collide in implicit mode.
- You run multi-region workloads where implicit routing splits traffic.
If none of these apply, implicit caching is simpler and cheaper.
How context caching compares to Bedrock
Bedrock charges a 1.25× write premium and expires every five minutes. Gemini implicit mode charges no write premium at all. That one difference decides most comparisons:
- Steady, high volume: Bedrock's explicit cache can win if you keep writes infrequent — but writes still cost.
- Irregular or low volume: Gemini implicit wins. No premium, no storage, nothing to manage.
- Output-heavy: Neither helps. Output is $3.75 on Flash and $10 on Sonnet 5; caching only discounts input.
Model both at your measured hit rate in the head-to-head breakdown before choosing.
How to verify you are actually getting hits
- Read the usage object on every response. Cached token counts must be non-zero.
- Log hit rate by route and by prefix version. Averages hide broken routes.
- Test with a repeated prefix first, then with a changed prefix. Confirm the cache invalidates.
- Budget with your measured hit rate, not the marketing discount.
Without this check you will assume 90% savings and see 10%.
FAQ
How much does Gemini context caching cost?
Cached input on Gemini 3.8 Flash is $0.075 per million tokens versus $0.75 uncached — a 90% discount. Explicit caches add storage per token-hour.
Is implicit caching free?
There is no write premium or storage fee for implicit mode. You pay the cached rate only when Google serves a hit. The trade-off is control, not price.
Do I need to change my code?
For implicit mode, no. For explicit mode, you create a cache resource and reference it. Start implicit, move to explicit only if you can name the reason.
Does caching help with long documents?
Yes, if the document repeats. One long document sent once is not a caching use case; the same document sent 1,000 times is.
Related reading
Your next step: find your prefix size in the logs, then run it through the free AI cost calculator at 0%, your measured hit rate, and 100%. The spread tells you whether caching is an optimisation or a distraction.
Gemini 3.7 Flash and other models: the same pattern
Gemini 3.7 Flash uses the same caching structure as 3.8 Flash: $0.75 uncached, $0.075 cached, $3.75 output. The difference is in quality and latency, not in pricing mechanics. When comparing Flash variants, run the same workload through both and measure pass rate, not just price.
For Gemini 2.5 Pro, the pattern shifts: higher base rates, larger context windows, and the same 90% cached discount. The math is identical — only the numbers change. Always pull current rates from the Google pricing page before you model, because promotional rates change monthly.
Multi-tenant caching: the collision problem
If you serve multiple tenants with different system prompts, implicit caching can collide. Tenant A's prefix and Tenant B's prefix may share a common segment (a shared instruction block), and Google may cache the shared segment for both. That is usually fine — it saves money. But if the shared segment contains tenant-specific data, you have a privacy problem, not a cost problem.
- Never put tenant-specific data in a cached prefix. Keep it in the variable part.
- Test with distinct prefixes. If two tenants see different cached token counts for the same prefix size, something is off.
- Log prefix hashes. A hash per request lets you detect unexpected reuse.
FAQ additions
Can I cache a conversation history?
Yes, if the conversation is long and the prefix is stable. But conversation histories change every turn, so the cache hit rate drops fast. Cache the system prompt and tool schemas, not the conversation.
What happens if my prefix changes mid-session?
The cache misses, and you pay a fresh write. If your prefix changes frequently, caching may cost more than it saves. Measure before you commit.
Final step: log your prefix size and hit rate for one week, then run the numbers through the free AI cost calculator. The spread between 0% and 100% is your risk.
