Gemini 3.5 Flash delivers more than 3.6 and costs exactly the same today

Gemini 3.7 Flash delivers more than 3.6 and costs exactly the same today

Google launched Gemini 3.7 Flash on August 13, three weeks after 3.6 Flash. The announcement describes it as “our most intelligent workhorse model yet for coding and agents”, and the headline that traveled fastest was the price: $0.75 per 1M input tokens and $3.75 per 1M output — half what 3.6 Flash cost when it launched on July 21.

That number is real. The comparison it suggests, it’s not. And the difference matters if you’re about to move a workload.

The pricing page says something the announcement doesn’t

Google’s official pricing page lists Gemini 3.6 Flash with exactly the same rates, word for word:

$0.75 through December 31, 2026. $1.50 starting January 1, 2027.

Input, output, context caching, batch, flex — every row of 3.6 Flash is identical to 3.7 Flash. The 50% discount wasn’t applied to the new model. It was applied to the entire Flash tier.

Per 1M tokens Through Dec 31 2026 From Jan 1 2027
Input (3.6 and 3.7 Flash) $0.75 $1.50
Output (3.6 and 3.7 Flash) $3.75 $7.50
Context caching $0.075 $0.15
Cache storage (per hour) $0.50 $1.00
Batch input / output $0.375 / $1.875 $0.75 / $3.75

Two conclusions come from that, and neither is in the launch post.

First: there’s no cost argument left to stay on 3.6 Flash. Same price, and 3.7 wins in every published comparison against it. If you’re on 3.6 today, the decision is purely migration effort and regression risk — it’s not budget.

Second: $1.50 / $7.50 isn’t a price increase. It’s the price 3.6 Flash launched at four weeks ago. So the honest reading of this launch isn’t “a cheaper model”. It’s a better model at the same permanent price, with a four-and-a-half-month discount window slapped on top. If your cost model for next year assumes $0.75, you’re budgeting against a promotion, not against a price.

That’s what makes this go from news to an architecture decision. Any workload you move to Flash between now and December is sized against a number that doubles on a date Google already published.

The benchmarks, and which ones actually moved

All of these are figures published by Google. Against 3.6 Flash:

Benchmark 3.7 Flash 3.6 Flash Delta
FrontierCode 1.1 Main 43.6% 34.4% +9.2
DeepSWE v1.1 65.3% 49.0% +16.3
AutomationBench 30.4% 17.0% +13.4
GDP.PDF (expert PDF comprehension) 34.0% 22.0% +12.0
WebDev Arena (Elo) 1588 1538 +50

The jump in repetitive automation tasks (AutomationBench, almost double) and in software engineering agent tasks (DeepSWE, +16 points) is where the generation actually shifted. The Elo gain in WebDev Arena is the smallest move in the set and the one most likely to disappear into the noise of your own prompts.

Now read the same table against the vendor. Google published competitive columns, and Flash doesn’t sweep them. (These comparative figures come from the benchmark chart in the launch, reproduced by tech press; Google’s original graph is an image.)

Benchmark 3.7 Flash GPT-5.6 Terra Claude Sonnet 5
WebDev Arena (Elo) 1588 1523 1541
FrontierCode 1.1 Main 43.6% 41.3% 42.7%
AutomationBench 30.4% 23.6% 10.7%
DeepSWE v1.1 65.3% 69.6% 54.0%
Terminal-bench 2.1 85.8% 87.4%
Terminal-bench 3.0 14.9% 20.8% 14.6%
OSWorld-2.0 38.1% 50.2%
Agent’s Last Exam 26.3% 33.3%
Artificial Analysis Intelligence Index 56 57 55

The pattern is consistent: 3.7 Flash leads in web code generation and in high-volume repetitive automation, and falls behind frontier models in long, difficult agentic tasks — Terminal-bench, OSWorld, Agent’s Last Exam. “Workhorse” is the right word, and it’s a compliment, not a caveat. This is the model you point at ten thousand routine tasks, not the one you point at the single task nobody solved.

It’s worth saying outright: these are self-reported numbers, from a chart published the same day as the launch. There’s still no independent third-party evaluation.

Migrating from 3.6 Flash

Both models are GA (stable), not preview. The model string is gemini-3.7-flash. Google’s migration notes for the 3.x generation include some items that break requests, not just degrade them:

Remove sampling parameters. temperature, top_p, top_k, and candidate_count are deprecated across this entire generation. Google’s guidance is explicit that moving temperature off its default value of 1.0 can cause loops or degraded output in reasoning-heavy work. If your 3.5-era configuration still defines them, remove them instead of porting them.

Replace thinking_budget with thinking_level. It’s an enum of strings: low, medium, high. You can’t send both parameters in the same request. In 3.7 Flash the default is medium.

That default is also your first cost lever, and it’s easy to miss. Thinking tokens are billed as output tokens — at $3.75 today, $7.50 in January. A workload that runs well on low and is running on medium without anyone noticing is paying that difference on every call. Measure it before assuming the default works for you: run a representative sample of your actual prompts on low and medium, compare both quality and the reported output token count, and choose based on the numbers, not the label.

Multi-turn conversations changed shape. Pre-filled model turns are gone; use previous_interaction_id server-side. Each FunctionResponse object now has to carry call_id and name. Multimodal assets go inside response payloads. If you’re coming from 3.5 or earlier, the rules for preserving thought signatures also apply.

Specs for sizing: 1M token context window, up to 64k tokens output. Google didn’t publish knowledge cutoff for this model.

A clarification on what I did and didn’t do: these migration items come from the documentation Google published, not from a migration I executed. Verify each one against your own request payloads before shipping to production.

The three levers before January

If the workload is going to Flash anyway, there are three multipliers available, and they compound:

Batch mode — 50% less. Input drops to $0.375 and output to $1.875. Everything that doesn’t need a synchronous response (overnight test generation, bulk documentation, backlog triage, dataset labeling) goes here. It’s the biggest lever and the one most overlooked.

Context caching — 10 times cheaper on the cached portion. $0.075 per 1M versus $0.75. If every call sends the same system prompt, the same schema, or the same repository context, that prefix is being paid at full rate on every request. Storage costs $0.50 per 1M tokens per hour, so it’s worth it when the same prefix gets reused enough within that hour — do the math for your call volume instead of turning it on everywhere.

thinking_level: low where the task doesn’t need reasoning depth, like we said above.

Batch plus caching, applied to a workload that fits both, moves the effective price further than the promotion — and unlike the promotion, they don’t expire.

What to actually plan for

December 31 isn’t a marketing detail. It’s the number your cost model should be built around.

The practical version: size your architecture to $1.50 / $7.50 and treat the next four and a half months as a discount you’re receiving, not as a price you depend on. If the account only closes at $0.75, it doesn’t close — you’ve built a dependency on a promotional window with a published end date. If it closes at $1.50, then the promotion is upside, and you have until January to move to batch and caching everything that qualifies.

The other half of that plan is portability. Three weeks separated 3.6 Flash from 3.7 Flash. Whatever cadence Google is running, the model behind your endpoint is going to change again before the promotion ends, and quite possibly the price tier with it. Keeping the model string in configuration and not in code, and maintaining a small evaluation set that you can re-run against a new model in an afternoon, is what turns each of these launches from a migration project into a config change.


Have you already run your numbers for January, or is your cost model still propped up on the $0.75? Tell us in the comments — especially if you measured what thinking_level: low does to quality in your own workload, because that’s the lever with the least public data behind it.

1 Like