Javlon Baxtiyorov
← Writing

Gemini 3.6 Flash Pricing & Cost: The Cache Math That Changes Everything

The sticker price is $1.50/$7.50 — but cached input is $0.15/1M, a 90% discount. Worked cost math showing ~79% savings on a real coding agent, plus when to route to Flash and when not to.

Gemini 3.6 Flash Pricing & Cost: The Cache Math That Changes Everything

The sticker price of Gemini 3.6 Flash is $1.50 per million input tokens and $7.50 per million output. That number is almost a lie of omission — because the line that actually decides your bill is the one Google buries in the pricing table: cached input at $0.15 per million, a 90% discount. Get the caching right and Flash becomes one of the cheapest capable models you can run. Get it wrong and you overpay by 10× for tokens you're sending over and over. Here's the real math, with worked examples.

$1.50input /1M
$7.50output /1M
$0.15cached input /1M (−90%)
1Mcontext window

The pricing, in full

Tier Price per 1M tokens
Input (uncached) $1.50
Input (cache hit) $0.15
Output $7.50
Context window 1,000,000 tokens

Compared to Google's own line-up, Flash slots in cleanly: cheaper than the Gemini 3.1 Pro flagship ($2–$4 in / $12–$18 out) and pricier than the Flash-Lite budget tier (~$0.25 in / ~$1.50 out). Against rivals it's mid-pack on sticker — Grok 4.5 is $2/$6, Kimi K3 is $3/$15 — but the cache line is where it separates.

Why the $0.15 cache line is the whole game

Most real LLM workloads re-send the same tokens on every call: a fat system prompt, tool definitions, a style guide, a chunk of codebase, a document you're answering questions about. Those prefix tokens don't change between requests — so paying full input price for them every time is pure waste. Context caching charges that stable prefix once at the cache-hit rate and only bills the new tokens at full rate.

The rule of thumb: the higher your ratio of repeated-prefix tokens to fresh tokens, the more the effective price collapses toward $0.15.

Worked example: a coding agent

Say you run a coding assistant with a 50,000-token stable prefix (system prompt + tool specs + the relevant files) and each turn adds 2,000 fresh input tokens and produces 1,000 output tokens. You serve 200 turns a day.

Without caching, every turn pays full input on the whole 52K:

Line Tokens/turn Rate Cost/turn
Input 52,000 $1.50/1M $0.0780
Output 1,000 $7.50/1M $0.0075
Total $0.0855

At 200 turns/day → $17.10/day ≈ $513/month.

With caching, the 50K prefix bills at the cache-hit rate; only the 2K fresh input pays full price:

Line Tokens/turn Rate Cost/turn
Cached input 50,000 $0.15/1M $0.0075
Fresh input 2,000 $1.50/1M $0.0030
Output 1,000 $7.50/1M $0.0075
Total $0.0180

At 200 turns/day → $3.60/day ≈ $108/month.

Same model, same output, ~79% cheaper — a $405/month difference on one modest agent, purely from not re-billing tokens that never changed. Scale that to production traffic and caching isn't an optimization, it's the difference between Flash being cheap and Flash being expensive.

Speed is a cost lever too

Gemini 3.6 Flash streams at ~303 tokens/second — the fastest of any model independently tracked. Throughput doesn't show up on the price sheet, but it shows up on your bill in three ways:

  • Agent loops finish sooner. A tool-calling agent that makes 20 round-trips spends most of its wall-clock waiting on generation. Double the tok/s, roughly halve the latency, and you can run more concurrent jobs on the same budget.
  • User-facing latency drops, which is the real product metric for chat and autocomplete.
  • Fewer timeouts and retries on long generations — and retries are tokens you pay for twice.

One honest caveat: that 303 tok/s is sustained streaming speed. Time-to-first-token can run ~11.5s at high reasoning effort, because the model thinks before it streams. For batch and streaming UIs that's a non-issue; for a hard sub-second first-token SLA, measure before you commit.

Enabling caching (the pattern)

The mechanics differ slightly by SDK version, but the shape is always: create a cached content handle for the stable prefix, then reference it on each call so only fresh tokens bill at full rate.

# Illustrative — check the current google-genai SDK for exact call names.
from google import genai

client = genai.Client()

# 1. Cache the stable prefix ONCE (system prompt + tools + files).
cache = client.caches.create(
    model="gemini-3.6-flash",
    config={
        "system_instruction": SYSTEM_PROMPT,
        "contents": [CODEBASE_CONTEXT],   # the 50K tokens you reuse
        "ttl": "3600s",                    # keep it warm across the session
    },
)

# 2. Each turn references the cache; only `message` bills at full input price.
resp = client.models.generate_content(
    model="gemini-3.6-flash",
    contents=[user_message],
    config={"cached_content": cache.name},
)

Two things that decide whether caching actually pays off: TTL (the cache has to still be warm when the next request lands — tune it to your session cadence) and prefix stability (change one token near the front and you invalidate the whole cache, so keep volatile content at the end of the prompt, not the start).

When to reach for Flash — and when not to

Route to Gemini 3.6 Flash when:

  • You have a large, stable prefix and high request volume — this is its home turf, and caching makes it cheap.
  • You need long context (up to 1M tokens) without jumping to a flagship's price.
  • Latency and throughput matter — streaming UIs, autocomplete, multi-step agents.
  • You're serving the 80% of traffic that doesn't need the absolute smartest model.

Don't, when:

  • The task needs top-tier reasoning (hard math proofs, research-grade analysis) — Flash scores 50 on the Intelligence Index; a flagship scores ~60, and that gap is real on the hard tail. Route those to a true flagship instead. (the flagship comparison →)
  • Your prompts are short and never repeat — no stable prefix means no caching win, and a cheaper Flash-Lite tier may serve just as well.
  • You need a sub-second first token under a hard SLA — measure TTFT first.

My take

Gemini 3.6 Flash is priced to be routed to, not deliberated over. The sticker rate is unremarkable; the cache-hit rate is the product. If your workload has the shape most production workloads have — a big reusable prefix and lots of calls — you can run a genuinely capable, million-token, fastest-on-the-board model for close to a fifth of what the naive integration costs. The teams that win on unit economics next year aren't the ones who picked the cheapest model. They're the ones who stopped paying full price for the same tokens twice.

For the full benchmark breakdown, see Gemini 3.6 Flash: Google's Speed Play.


Sources

Prices and speed reflect Google's published rates and independent measurement as of 22 July 2026 and will change. Always confirm against the current Google AI pricing page before sizing a bill.

Read next All writing →
← All writing Get in touch →