Slashing Gemini API Costs With Context Caching

Here is the part worth acting on today. If your application re-sends the same large context on every call, a long instruction block, a reference document, a whole codebase, you are billed full input price for tokens the model has effectively already ingested. Caching changes the price on those repeated tokens. On Gemini 3.1 Pro the standard input rate is $2.00 per million tokens. A cached read of that same content is $0.20 per million. That is the 90% number, and it applies to the cached segment of each request, not your whole bill.

There are two ways to get there. One needs no code at all and is already running on your paid project. The other needs a few lines of SDK setup and a small ongoing fee, but gives you a result you can predict and budget for. Most teams should confirm the free one is working first, then reach for the paid one only when the numbers justify it.

Who this is for

You are running production traffic against the Gemini API, your input token counts dwarf your output token counts, and a big chunk of that input is the same on every request. Retrieval pipelines with a fixed knowledge base, coding agents that re-read a repository, document-QA tools, and long-system-prompt chat apps all fit this shape. If your inputs are short and rarely repeat, caching will not move your bill much, and you can skip to the decision section to confirm that.

As of May 2026 the Gemini API offers two caching modes. They both target the same problem and both deliver roughly a 90% discount on repeated input, but they behave very differently in practice. The difference comes down to who controls the cache and who pays to keep it warm.

One practical note before the numbers: implicit caching has a small per-model minimum (roughly 2K-4K tokens); explicit caching has no stated minimum. Treat caching as something that helps in proportion to how much context you repeat, and validate the actual savings against your own usage metadata rather than assuming a cutoff.

Here are the explicit-cache rates that matter, pulled from Google's published pricing and verified on June 9, 2026. The headline model is Gemini 3.1 Pro, where the gap between standard input and cached read is largest in absolute dollars. The Flash models are cheaper across the board, which changes the math on whether explicit caching is worth the storage fee at all.

Read the Pro row first. A cached read costs one tenth of the standard input rate, which is where the 90% figure comes from. The cache write of $0.50 per million is a one-time charge when you create the entry, so it amortizes to almost nothing once the content is read more than a few times. Storage is the line that bites: $4.50 per million tokens per hour means a 1M-token cache held for a full day costs about $108 in storage alone, whether or not you read it. That is why TTL discipline matters, and why explicit caching is a poor fit for content you touch only occasionally.

The Flash rows tell a different story. Flash input is already cheap at $0.50 and $0.25 per million, and the cached reads drop to $0.05 and $0.025. The absolute savings per read are small, so the $1.00-per-hour storage fee eats into them quickly. On Flash, implicit caching usually captures the realistic upside without you paying to hold anything. Reserve explicit caching for the Pro tier and for genuinely high-reuse Flash workloads.

Take a concrete workload: a 100K-token system prompt that your app re-sends on every request, run across 1,000 requests on Gemini 3.1 Pro. The naive cost is easy. That is 100,000 tokens times 1,000 calls, or 100 million input tokens, billed at $2.00 per million. Round number: about $200, just for the repeated prompt.

Now wire up explicit caching with a one-hour TTL. You write the 100K-token prompt to a cache once, which is a fraction of a million tokens at the $0.50 write rate, so the write costs roughly $0.05. Each of the 1,000 requests then reads that 100K-token context at the cached rate of $0.20 per million, which works out to about $20 in reads total. Holding 100K tokens in storage for the hour at $4.50 per million per hour costs around $0.45. Add it up and you land near $20.50 against the original $200. That is the 90% saving, made of real line items rather than a marketing round number.

The shape of this math is what you should internalize, not the exact total. Read cost scales with how many times you reuse the content, so high reuse is what makes caching pay. Storage cost scales with how long you hold the entry, so a stale cache you forgot to expire is pure waste. The write fee is trivial. Keep the TTL just long enough to cover your burst of reuse, and the savings hold.

Explicit caching is three moves: create the cache, reference it on each request, then read the usage metadata to confirm what was billed at the cached rate. All of it runs through the unified google-genai SDK. Start by creating the entry with your shared context and a TTL.

# pip install -U google-genai
from google import genai
from google.genai import types

client = genai.Client()

# The shared context you re-send on every request
system_context = open("company_handbook.txt").read()

cache = client.caches.create(
    model="gemini-3.1-pro-preview",
    config=types.CreateCachedContentConfig(
        display_name="handbook-cache",
        contents=[system_context],
        ttl="3600s",  # 1 hour, keep it tight
    ),
)

print(cache.name)  # reference this on later requests

With the entry created, every subsequent call points at the cache name instead of resending the full context. Only your per-request question is billed at the standard input rate. The cached block is billed at the cached read rate.

# Reuse the cache across many requests
response = client.models.generate_content(
    model="gemini-3.1-pro-preview",
    contents="What is the PTO carryover policy?",
    config=types.GenerateContentConfig(
        cached_content=cache.name,
    ),
)

print(response.text)

# Confirm what got billed at the cached rate
usage = response.usage_metadata
print("cached tokens:", usage.cached_content_token_count)
print("prompt tokens:", usage.prompt_token_count)

That last block is the one practitioners skip and regret. The cached_content_token_count field tells you exactly how many tokens were billed at the discounted rate on each call. If that number is zero when you expected a hit, your cache reference is wrong, the entry expired, or the content drifted. Log it in staging and reconcile against your bill before you trust the savings in production.

Explicit caching is not a free upgrade over implicit. You are adding a storage meter that runs whether or not you read the entry. The decision is a straight comparison: does the value of your discounted reads over the cache lifetime exceed what you pay to hold it? Use this checklist to settle it before you write any code.

If your traffic is bursty and naturally repetitive on its own, implicit caching already grabs most of the upside for nothing, and adding explicit caching can actually cost more once storage is counted. The honest default is: let implicit caching run, instrument cached_content_token_count, and only introduce explicit caching for the specific high-reuse, Pro-tier paths where the ledger clearly favors it.

Caching does not live in a vacuum. The reason it matters so much on Gemini is that the model already carries a very large context window, so the kind of workload where you stuff an entire codebase or document set into the prompt is realistic in the first place. Pair a long context window with a 90% read discount and the economics of whole-repository analysis change.

One independent, illustrative comparison makes the point. Analysts have estimated that a large-codebase analysis workload that might cost on the order of $90,000 on a top-tier competitor model can drop to roughly $3,500 on Gemini 3.1 Pro by leaning on its long context window plus caching. Treat that figure as directional rather than a quote you can hold either vendor to. It depends heavily on token volume, reuse pattern, and how aggressively caching is applied, and it comes from independent third-party analysis, not from Google or the competing vendor.

The takeaway is not that one vendor is always cheaper. It is that on input-heavy, repetitive workloads, caching turns input volume from your dominant cost into a rounding error, and that shifts which model is the rational choice for a given job. If you are weighing options, the Gemini versus ChatGPT comparison covers the broader trade-offs beyond price.

Google, Gemini, Google AI Studio, and Vertex AI are trademarks of Google LLC. This article is not affiliated with, sponsored by, or endorsed by Google LLC.