Gemini 3.6 Flash and Gemini 3.5 Flash production inference lanes compared for speed and cost

Comparison

Gemini 3.6 Flash vs Gemini 3.5 Flash: Should You Move Production Workloads?

Jacey

Founder

July 21, 2026

18 min read

Last verified: 2026-07-21. Written by Jacey and including 216 API calls we ran on launch day; the method is described in full where those results appear. EvoLink operates an API gateway that routes to third-party models, including both models discussed here.

The short version

Move now if output tokens dominate your bill. Agent loops, long code generation and reasoning-heavy work land in the 26% to 29% cheaper range.
Small gain if your traffic is input-heavy. A document pipeline running roughly 20 input tokens per output token saves 7.1%, because the input price did not change at all.
Intelligence is flat. Independent measurement puts the two models at 50.1 and 50.2 on the same index. What moved is speed: 165 to 304 output tokens per second, and 2.7 to 1.3 minutes per task.
Test first if your workload is knowledge-heavy or generates front-end UI. Those are the two places the published evidence points the other way.
The thinking level moves your bill more than the model does. In our own testing, dropping from the medium default to minimal cut the cost of a pass by 73.6% with no loss of accuracy on our task set. Set it deliberately whichever model you run.
This is not a model-string swap. temperature, top_p and top_k are now accepted and then ignored without an error, and thinking_budget no longer exists.

The short answer, by workload

The value of this upgrade depends almost entirely on two things: the ratio of input tokens to output tokens in your traffic, and whether latency is currently a complaint.

Your workload	Verdict	Why
Multi-turn agents, tool-calling loops, long code generation	Move	Output and thinking tokens dominate, and that is the only part of the price that fell
Anything where task latency is the complaint	Move	Time per task roughly halved in independent measurement
Knowledge-heavy question answering	Shadow-run first	The one cross-generation knowledge score that is directly comparable moved down
Front-end and UI generation	Shadow-run first	Google documents two specific regressions here, both with a prompt-level fix
Document processing and RAG at roughly 20:1	No hurry	The saving is 7.1%, which is inside the noise of a normal month

If the question you are actually asking is whether to run Gemini 3.5 Flash-Lite instead, that is a different decision with a different answer, and we cover it in Gemini 3.6 Flash versus 3.5 Flash-Lite. Flash-Lite is a lower capability tier, not a newer version of the model you are running, so none of the numbers below transfer to it.

What actually changed

Gemini 3.6 Flash is not a new model generation. Its model card states that it is built on Gemini 3.5 Flash, which makes it a post-training update on the same base. That single fact explains most of what follows: capability moved sideways, while the things post-training and serving can move, speed and token efficiency, moved a lot.

Here are the practical details, taken from Google's model documentation.

Model ID: gemini-3.6-flash. One stable version, no preview suffix and no date stamp, so there is no aliasing decision to make.
Context: 1,048,576 input tokens and 65,536 output tokens, unchanged. Text, image, video, audio and PDF in; text only out.
Default thinking level: medium, selectable across minimal, low, medium and high.
Price: input stayed at $1.50 per million tokens. Output fell from $9.00 to $7.50, a cut of 16.67%. Cached reads are $0.15 per million. See Google's pricing page for the batch and priority tiers.

Those are the fields that matter for the decision on this page. For the full capability matrix and a first working request against the new model ID, see our Gemini 3.6 Flash guide.

One correction worth making, because it is circulating: the input price did not rise. Both gemini-3.5-flash and gemini-3.6-flash charge $1.50 per million input tokens. The claim of a hidden increase comes from comparing against a price from an earlier Flash generation.

What happens to your bill

Two separate things are supposed to reduce your cost: the output price is 16.67% lower, and the model is reported to use fewer output tokens for the same task. Compounded, output-side spend drops 30.8%.

That number is real, and it is also the reason so much coverage of this release overstates the saving. Input price did not move. So the closer your traffic is to input-heavy, the less of that 30.8% you actually see.

Gemini 3.6 Flash workload cost comparison showing why output-heavy AI workloads capture more savings than input-heavy pipelines

Gemini 3.6 Flash savings concentrate on the output side, so workload token ratios determine the production cost impact.

Input:output ratio	Typical workload	On 3.5 Flash	On 3.6 Flash	Change
20:1	Document processing, RAG	$39.00	$36.23	7.1% cheaper
5:1	General question answering	$16.50	$13.72	16.8% cheaper
1:1	Multi-turn agents with thinking enabled	$10.50	$7.72	26.4% cheaper
1:3	Reasoning-heavy work, long code generation	$28.50	$20.17	29.2% cheaper

Read the table like this. Each row prices one workload normalized to 1 million output tokens on 3.5 Flash, with input tokens set by the stated ratio, at standard-tier pricing. It assumes 17% fewer output tokens on the newer model and identical input tokens.

That 17% assumption deserves its conditions stated, because everything in the table rests on it. Google cites the figure rather than measuring it, and the source is Artificial Analysis. The absolute token counts published on that same page, 59 million against 75 million, work out to 21.3%. The two figures have not been reconciled publicly. We used the more conservative 17% throughout, so treat the table as the low end of the range rather than a promise.

Thinking tokens bill at the output rate. That is why the agent rows move most: on a multi-turn agent, the thinking budget is not a rounding error on the bill, it is a large share of it.

Then we measured it, and the table turned out to be optimistic. Our task set runs at roughly 1 input token for every 1.5 billed output tokens, which sits between the 1:1 and 1:3 rows, where the table predicts a saving of 26% to 29%. We measured 13.6% at the medium thinking level and 20.1% at high.

The whole gap is the token-efficiency assumption. At medium, the newer model billed 1.7% more output tokens than its predecessor, not 17% fewer, so almost all of the saving we got came from the price cut rather than from token efficiency. At high the reduction did partly appear, at 6.4% fewer output tokens. Method and full numbers are in the next section.

So read the table as the arithmetic implied by the vendor claim, and our figures as what one real workload actually produced. If your work resembles ours more than it resembles a benchmark set, plan on the lower number.

Same intelligence, roughly double the speed

Artificial Analysis got pre-release access and is currently the only independent source with a full breakdown. Their numbers, measured at the high thinking level:

Metric	3.6 Flash	3.5 Flash
Intelligence Index v4.1	50.1	50.2
Humanity's Last Exam	38.3%	40.2%
GPQA Diamond	92.8%	92.2%
SciCode	52.7%	53.1%
Long-context reasoning (AA-LCR)	69.7%	69.3%
Output speed	303.6 tok/s	165.4 tok/s
Time to first token	11.54 s	20.22 s
Average time per question	1.3 min	2.7 min
Average cost per question	$0.50	$0.59

Two conditions apply to every row. These were measured at the high thinking level while the API default is medium, so running the default configuration is not the same experiment. And the speed and latency figures are 72-hour medians taken on a model that was released the same day, which means the sample window is under a day and should be expected to move.

With that stated, the shape is clear and it is a tradeoff rather than a regression. Intelligence Index parity at 50.1 against 50.2 is a rounding difference. Reasoning and long-context scores nudged up. The one knowledge-heavy score that is directly comparable across the two generations, Humanity's Last Exam, moved down by 1.9 points. Meanwhile output speed rose 84% and time per question roughly halved.

So if what you wanted from this release was a smarter model, this upgrade was not built for you, and staying on gemini-3.5-flash costs you nothing on that axis. If what you wanted was the same quality of work finishing in half the time at a lower unit cost, that is exactly what shipped.

The knowledge-heavy caveat is worth one extra step rather than one extra worry. A 1.9-point move on one benchmark is a signal to check your own evaluation set, not a reason to skip the release.

The thinking level moves the bill more than the model does

Every published figure above describes the high thinking level, while the API default is medium. That gap is large enough to change a purchasing decision, so we ran our own test on launch day.

Gemini 3.6 Flash thinking levels accumulate progressively more reasoning tokens while the final production output stays compact

Thinking level can change billed output more than the model switch itself, so production teams should set and evaluate it explicitly.

The setup: nine tasks in three groups, structured extraction from invoices, logs and product HTML; multi-turn tool calling over three to five steps against simulated tools; and code location and repair, where a bug description has to become a runnable patch. Inputs run between 1,000 and 4,000 tokens, so this does not cover long-context work. Each task ran three times against each of eight model and thinking-level configurations, 216 calls in total, sent serially through OpenRouter with the provider pinned to Google AI Studio. Answer tokens and thinking tokens were recorded separately, and everything is priced at Google's standard-tier list rather than the gateway's own billing. No sampling parameters were set, since they no longer do anything.

Configuration	Answer tokens	Thinking tokens	Thinking share	Cost per pass	Correct
3.6 Flash `minimal`	1,162	0	0%	$0.0158	9/9
3.6 Flash `low`	1,056	1,095	51%	$0.0232	9/9
3.6 Flash `medium` (default)	1,080	5,944	85%	$0.0598	9/9
3.6 Flash `high`	1,092	6,679	86%	$0.0653	9/9
3.5 Flash `medium`	1,078	5,827	84%	$0.0692	9/9
3.5 Flash `high`	1,113	7,185	87%	$0.0818	9/9

Three things stand out.

Thinking tokens are the bill. At medium and high they are 84% to 87% of everything you pay for on the output side. Answer length barely moves across the whole table. Which model you pick changes your cost far less than which level you pick.

minimal is not "think less", it is "do not think". Thinking tokens came back at exactly zero, a pass cost 73.6% less than the medium default, and the score was the same nine out of nine. If you are on medium because you never chose a level, that is the largest cost lever available to you, and it works on the model you are already running.

high cost only 9.3% more than medium here, because the extra budget went unspent: thinking rose from 5,944 tokens to 6,679. That is a fact about these tasks rather than about the model. On harder work that gap widens.

Where our numbers disagree with the other independent run

aibenchy ran 22 short benchmark questions after release and found the newer model 29.4% more expensive at medium and 9.7% cheaper at high. We found it cheaper at both levels, by 13.6% and 20.1%. The high results agree in direction. The medium results point opposite ways, and the reason is visible in one number: they measured 66.2% more thinking on the newer model at medium, we measured 2.0% more.

We are not going to call their result wrong. Two task sets produced opposite answers to the same question, and that is the finding worth carrying away: whether this model saves you tokens depends on what you run it on, not on the model alone. Google's own "17% fewer output tokens" names neither a thinking level nor a task set, which is why it reproduces on some workloads and not others.

What our test cannot tell you. Nine tasks were not hard enough to separate the levels on quality. Every configuration scored nine out of nine. So these numbers support a cost-based recommendation about which level to run, and they do not locate the point where quality starts to drop. Repeat runs also varied: thinking tokens moved by 6% to 51% between identical runs of the same task, which is why the figures above are three-run averages. A harder round aimed at finding the quality knee is running separately, and we will update this page with it.

The actionable part is simple: whichever model you run, set the thinking level explicitly and price the level you actually run, not the level the benchmarks were published at.

Two things Google says the new model does worse

Google publishes two specific weaknesses in its launch post, and both concentrate in the same place.

It explores before it edits. The model is more inclined than 3.5 Flash to run a diagnostic pass before changing code. On complex tasks that raises accuracy. On simple front-end tasks it produces extra exploration steps you did not need and did not want to pay for.

Human raters preferred the older model's visual output. On visual layout and styling specifically, evaluators favoured the earlier model. Google's stated mitigation is to write your design rules into the prompt rather than leaving styling to the model's defaults.

The model card also lists hallucination and occasional slow responses or timeouts among known limitations.

None of that argues against the upgrade. It argues for splitting the decision by surface. If you have an agent tier and a UI-generation tier, they are different workloads with different evidence, and there is no rule that says they have to run the same model ID.

Switching is not a model-string change

This is the part that catches teams, and it is the reason a same-day "just change the model name" recommendation is now wrong. Starting with this release, and explicitly for all models after it, several parameters changed behaviour. The full list is in Google's API changelog; the ones that break production quietly are these.

temperature, top_p and top_k are ignored, and no error is raised. Google's documentation states that a future model generation will return HTTP 400, but today the values are simply dropped. If you rely on temperature=0 to keep an extraction or classification pipeline deterministic, that guarantee disappears with no log line, no exception and no alert. The replacement approach is to put the rule in the system instruction.

There is a second-order version of this worth checking. OpenRouter's model metadata still lists temperature, top_p and seed among supported parameters, so a gateway will accept your value and forward it, and the model will ignore it. Anyone tuning temperature today to improve output quality is tuning a no-op.

thinking_budget is replaced by thinking_level. The old numeric budget becomes a string enum. Sending both in one request returns a 400.

Three smaller ones. candidate_count is unsupported on Gemini 3.x. A request whose final message carries the model role now returns 400, which removes response prefilling. And every FunctionResponse must now carry both call_id and name.

For the line-by-line version, including Google's own automated migration tooling and the retirement schedule for the models this replaces, see our Gemini 3.6 Flash migration guide. One caution if you search for this yourself: guides written for earlier Gemini upgrades, including our own on moving from Gemini 3 Flash Preview to Gemini 3.5 Flash, still describe sampling parameters as working, because on that model pair they did. The deprecations above start with this generation.

A practical note on testing the two side by side: because both model IDs are exposed through one OpenAI-compatible endpoint on EvoLink, you can point base_url at a single gateway and switch the model string to A/B them against your own prompts, without standing up a second integration first. That is the cheapest way to answer the knowledge-heavy and UI questions above for your own traffic.

Before you flip the switch

The published numbers narrow the question. Four measurements close it.

Log answer tokens and thinking tokens separately. A total-token metric will not tell you why your bill moved, because only one of the two components is behaving differently between these models.
Pin the thinking level explicitly. Do not inherit medium by accident, and price the level you actually run rather than the high level the published benchmarks used. On our task set this was worth more than the model change: minimal cost 73.6% less than the medium default at the same accuracy. Check whether your own work tolerates it before assuming the same.
Shadow-run your real prompt mix, not a benchmark set. This matters most if your traffic is knowledge-heavy, which is the one axis where the comparable score moved down.
Grep before you cut over. Search your codebase for temperature, top_p, top_k, thinking_budget and candidate_count. The first three fail silently, which means your tests will pass and your outputs will drift.

FAQ

Is Gemini 3.6 Flash a renamed Gemini 3.5 Pro? That speculation circulated after launch. The highest-voted community response rejected it, arguing there is no indication of a renamed Pro model and that this is a Flash upgrade. The model card supports that reading: it states the model is built on Gemini 3.5 Flash. We are recording the speculation, not endorsing it.

Is gemini-3.5-flash being shut down? The retirement dates Google has announced are 2026-10-16 for gemini-2.5-flash and gemini-2.5-flash-lite, and 2027-05-07 for gemini-3.1-flash-lite. No retirement date has been announced for the models released on 2026-07-21. There is no announced deadline forcing this decision, so you can take the time to measure.

Did the input price go up? No. Both models charge $1.50 per million input tokens at standard tier. Only the output price changed, from $9.00 to $7.50.

Can I keep using temperature=0 for deterministic output? No, and this is the failure mode to watch. The parameter is accepted and ignored without an error. Move the constraint into the system instruction and verify the output rather than the request.

Is 3.6 Flash meaningfully cheaper for RAG? At roughly 20 input tokens per output token, the published figures imply a saving of 7.1%. It is real but small, because the input side of your bill did not change. Treat that as the ceiling rather than the estimate: on our own tasks the effective saving came in below what the same arithmetic predicted, and our test did not cover long-context retrieval at all. RAG teams should treat this release as a latency improvement first and a cost improvement second.

Which model ID should I use? gemini-3.6-flash. There is a single stable version, with no preview suffix and no date-stamped variant to choose between.