So Google quietly killed off three sampling parameters. `temperature`, `top_p`, `top_k`. Gone. Gemini 3.6 Flash and Gemini 3.5 Flash-Lite don’t want ’em anymore.
Docs call ’em deprecated and ignored【F1】. That’s the present tense situation. And down the road? Next model generations will throw an HTTP 400 right back at you if your requests still include those fields【F2】. Clock’s already running on this one, honestly.
Why solo builders should care
Tbh I didn’t notice for like three weeks.
Run a one-person shop here.
AI automation stuff, nothing fancy, and Gemini’s been my go-to for cheap text generation.
My pipelines had `temperature=0.7` hardcoded in there for ages.
Needed enough variation in the output so marketing copy didn’t all sound identical. After the Gemini 3.6 Flash update rolled through, those payloads still went through fine. Accepted, no errors. But here’s the thing — they were silently ignored【F1】. Same deterministic output every single time. Didn’t cost me anything extra. Didn’t break anything either. But that quiet little no-op? It’s sitting on a ticking bomb. Because when Google ships the next Gemini version, the API won’t just ignore those fields.
It’s gonna reject the whole request with a 400【F2】.
Every endpoint that’s still got those parameters tucked inside the payload goes dark overnight. No warning.
No deprecation grace period that anyone actually notified us about.
Can’t afford a week of downtime.
Nobody running this kind of operation can. A busted request chain means your newsletter doesn’t send. Your chatbot stops responding mid-conversation. Billing reminders don’t fire. Small stuff individually, sure. But it’s exactly the sort of friction that eats into margins we’re already surviving on by a thread.
Side note: I found out about this from a random GitHub issue thread, not from any official communication from Google. Their changelog buries it.
What actually changed under the hood
Dug through the Gemini docs.
They flat-out tell you to remove these parameters from all requests【F3】【F5】. Not subtle about it either. The “What’s new” section for Gemini 3.x models says these params are “no longer recommended”【F4】. And the Enterprise Agent Platform guide? Goes a step further. Lists the hardcoded defaults that are now baked in. `temperature: 1.0`, `topP: 0.95`, `topK: 64`. Any custom values you send? Straight into the void【F6】【F7】.
Right now the API plays nice on the surface. It accepts the fields. Doesn’t complain. Then discards them and hands you the default deterministic output anyway. Feels polite about it, kinda. But that’s a trap — future behavior flips the script entirely. Same fields trigger an HTTP 400 and the whole request dies【F2】【F8】【F13】.
Then there’s OpenRouter. Their endpoint page still shows some of those parameters for Gemini 3.6 Flash as of July 21, 2026. Looks like everything’s normal. But the gateway just forwards them along untouched, and the model tosses them same as always【F22】【F23】. Confusing if you’re using auto-generated SDKs and trusting the parameter list to reflect what actually works. Found this out the hard way at 2am last Thursday. Spent forty minutes debugging before realizing the docs were just stale.
Fix it now, not later
Don’t wait. Audit your codebase. Every single place that makes a Gemini API call. Check for `temperature`, `top_p`, or `top_k`.
A grep gets you most of the way there:
`grep -R “temperature” .`
Honestly that caught maybe 90% of my instances.
The other 10% were hiding inside config files and environment variable setups that I’d forgotten about months ago. Check those too. Shared config repos, infrastructure templates, anything that gets copy-pasted around your org.
Now here’s where it gets interesting. You still need variation in your output. Temperature’s gone. So what do you do? System instructions are the replacement. Gemini now expects you to control tone and phrasing variety at the prompt level rather than through sampling parameters. Prepend something like “Answer in a friendly tone with varied phrasing” to your system prompt and you get roughly the same effect that `temperature=0.7` used to give you. Not identical, but close enough that I haven’t noticed a meaningful drop in output quality for my use cases.
Won’t lie though.
Migrating the system prompt approach across fourteen different pipeline templates was tedious.
Each one needed slightly other wording since the output contexts vary.
Marketing blurbs need punchier instructions. Transactional emails need more formal guidance.
Took the better part of an afternoon.
One more thing worth flagging. If you’re routing through OpenRouter or any intermediary gateway, double-check what happens to those forwarded parameters after the next Gemini version drops. The gateway might accept them on its end and pass them through. But the underlying model rejects them with that 400. Could leave you in a weird state where the gateway reports success on the outbound side while the actual model call fails silently. Haven’t tested that scenario yet. And tbh I’m a little scared to.
