Google refreshed its Flash tier on July 21, 2026, and the workhorse model jumped a version to Gemini 3.6 Flash. If you’re running 3.5 Flash in production, here’s the short version: 3.6 Flash is a cheaper, more token-efficient drop-in replacement, and most teams should upgrade. Same model family, same 1M-token context, same input price. The output costs less per token, and the model writes fewer output tokens to finish the same job. For the full rundown on the new model, see what is Gemini 3.6 Flash.
The short answer
Upgrade. Gemini 3.6 Flash keeps the $1.50 per million input price, cuts the output price from $9.00 to $7.50 per million, and produces about 17% fewer output tokens than 3.5 Flash on the same tasks. It also scores higher on computer-use benchmarks (83.0 vs 78.4 on OSWorld-Verified) and takes fewer reasoning steps on multi-step workflows. The one reason to hold: you’ve pinned and validated 3.5 Flash in production and can’t re-run your evals yet.
Gemini 3.6 Flash vs 3.5 Flash side by side
Here’s the comparison that matters, straight from Google’s launch numbers. The details live on the Google blog post and the DeepMind Flash model page.
| Attribute | Gemini 3.6 Flash | Gemini 3.5 Flash |
|---|---|---|
| Model ID | gemini-3.6-flash |
gemini-3.5-flash |
| Input price (per 1M tokens) | $1.50 | $1.50 |
| Output price (per 1M tokens) | $7.50 | $9.00 |
| Output-token efficiency | ~17% fewer output tokens | baseline |
| Computer use (OSWorld-Verified) | 83.0 | 78.4 |
| Context window | 1M input tokens | 1M input tokens |
The input price didn’t move. The context window didn’t move. The changes are on the output side of the ledger and in how efficiently the model gets to an answer.
What actually improved
Four things changed, and they’re the reasons to migrate.
Fewer output tokens. Gemini 3.6 Flash produces about 17% fewer output tokens than 3.5 Flash for the same work. Output tokens include thinking tokens, so a more efficient reasoner writes less to reach the same answer. You pay for every output token, so this is a direct cost line, not a vanity metric.
Lower output price. Google cut the output price from $9.00 to $7.50 per million tokens. That’s a 17% price cut on the per-token rate, on top of the token-count reduction above.
Better computer use. On OSWorld-Verified, the benchmark for driving a real computer interface, 3.6 Flash scores 83.0 versus 78.4 for 3.5 Flash. If you’re building agents that click through UIs, fill forms, or operate tools, that gap shows up as fewer failed steps.
Fewer reasoning steps and tool calls. On multi-step agent workflows, 3.6 Flash reaches the goal in fewer reasoning steps and fewer tool calls. Each avoided tool call is a round trip you don’t pay for and don’t wait on, so this compounds with the token savings on anything agentic. Coding precision improved too, which matters if the model is editing files or generating diffs where one wrong token breaks the build.
None of this changes the shape of the API. It’s the same request format, the same modalities in (text, image, video, audio, PDF), the same text out.
What it means for your bill
The two cost effects stack. You get a lower price per output token AND fewer output tokens to pay for. They multiply, they don’t just add.
Here’s an illustrative example. Say a daily job generates 10 million output tokens on 3.5 Flash:
- On 3.5 Flash: 10M output tokens x $9.00 per 1M = $90.00 per day on the output line.
- On 3.6 Flash: 17% fewer output tokens is about 8.3M tokens, at $7.50 per 1M = $62.25 per day.
That’s roughly 31% off the output side of that workload, and you didn’t change a single prompt. Your input cost stays flat because the input price is identical at $1.50 per million and your prompts didn’t change. On agent workloads with lots of tool calls, the drop can be larger, since fewer round trips also trim total tokens across the run.
Your real number depends on your input-to-output ratio. Jobs that read a lot and write a little (classification, extraction) see a smaller total change because the savings are concentrated on output. Jobs that write a lot (drafting, code generation, long agent traces) see the biggest wins. For a full breakdown of rates, caching, and the thinking-token detail, see Gemini 3.6 Flash pricing and the official Gemini API pricing docs.
Is there any reason to stay on 3.5 Flash?
Yes, a narrow one. Be honest with yourself about which case you’re in.
The legitimate reason to pin 3.5 Flash is that you’ve already validated it in production and you can’t re-test right now. Maybe you have a locked evaluation suite tied to a compliance sign-off. Maybe you have prompt-tuned outputs that a downstream parser depends on, and a regression window isn’t open this sprint. Model swaps change outputs in subtle ways, and “cheaper” isn’t worth a silent break in a system you can’t re-validate today. In that case, stay pinned to gemini-3.5-flash until you have a testing window, then migrate deliberately.
To be clear: 3.5 Flash is not going away the day 3.6 ships. It’s still available through the API, and pinning to it is a valid short-term call. This is a “when,” not an “if.” For most teams without a hard validation lock, the money and the quality both point at upgrading now.
How to migrate
The mechanical part is one line. In your API call, swap the model ID:
- From
gemini-3.5-flash - To
gemini-3.6-flash
That’s the whole code change. The request body, auth, and endpoints are the same, so nothing else in your integration moves. For a complete request-by-request walkthrough, see how to use the Gemini 3.6 Flash API and the Gemini API docs.
The real work is verification, not the swap. Before you ship the new model ID to production:
- Re-run your evaluation suite against 3.6 Flash and compare quality scores to your 3.5 Flash baseline.
- Re-run your regression tests, since output shape and phrasing can shift between versions.
- Check anything that parses model output by exact structure (JSON keys, regexes, downstream schema validation).
- Watch latency and token counts on a sample of real traffic before rolling out fully.
If your outputs feed another service, treat the swap like any dependency upgrade: change it behind a flag, compare, then promote.
Regression-test the swap in Apidog
This is where Apidog earns its place in the migration. Apidog is an API client and testing platform, so it’s the natural spot to prove 3.6 Flash behaves before you trust it in production. It doesn’t run the model; it sends the requests and checks the responses.
A clean way to A/B the two models:
- Save your existing Gemini request. Build the
POSTcall to the Gemini API in Apidog, with your API key stored in an environment variable so it never sits in the request body. - Duplicate it. Change exactly one thing: the model ID, from
gemini-3.5-flashtogemini-3.6-flash. Everything else stays identical so you’re comparing like for like. - Add assertions. Assert on status code and the JSON fields your app actually reads, so a shape change fails loudly instead of leaking downstream.
- Compare responses and latency. Fire both, put the outputs side by side, and check that the 3.6 response still passes every assertion the 3.5 response did. Note the response time and token usage on each.
- Keep the assertions green over time. Save both as a test scenario and schedule it as a regression test so a future model or prompt change can’t silently break the contract.
That’s the honest workflow: duplicate the request, change only the model ID, and let the assertions tell you whether the swap is safe. Download Apidog if you want to run the comparison against your own Gemini calls.
FAQ
Is Gemini 3.6 Flash a drop-in replacement for 3.5 Flash? Mechanically, yes. You change the model ID from gemini-3.5-flash to gemini-3.6-flash and the rest of the request stays the same. You should still re-run your evals and regression tests before production, because output phrasing and structure can shift between versions.
Did the input price change? No. Input stays at $1.50 per million tokens on both models. Only the output price changed, from $9.00 to $7.50 per million.
Why is the model 3.6 but the Lite and Cyber variants are 3.5? Google bumped only the workhorse Flash model to 3.6 in this refresh. Flash-Lite and Flash Cyber shipped as 3.5 versions. The version numbers aren’t in lockstep across the tier, so read the model ID, not just the family number.
Will my bill definitely drop 31%? No, that figure is an illustrative example for an output-heavy workload. Your actual savings depend on your input-to-output token ratio. Output-heavy jobs save the most; read-heavy jobs save less because the discount lands on output.
Is 3.5 Flash still usable? Yes. It remains available through the API. If you’ve validated it and can’t re-test yet, pinning to it is a reasonable short-term choice. Plan the migration for your next testing window.
For the prior generation this model replaces, see what is Gemini 3.5.
For most teams, the math and the benchmarks agree: swap the model ID to gemini-3.6-flash, run your evals and a quick regression pass in Apidog, and take the cheaper, more efficient model. Keep 3.5 Flash pinned only where a validation lock forces your hand, and migrate the moment that window opens.
