Gemini Kills the Temperature Knob, and It Won't Come Back
Google joins OpenAI and Anthropic in stripping sampler control from post-trained models, and production pipelines will feel it.
Buried in the migration notes for Google's latest Gemini models is a line that quietly ends a decade of LLM folk wisdom: on Gemini 3.6 Flash and 3.5 Flash-Lite, temperature, top_p, and top_k are "deprecated and ignored." Not discouraged. Ignored. Your carefully tuned temperature: 0.2 does nothing today, and in future model generations the same request will return an HTTP 400.
The deprecation applies to all future Gemini releases, and it comes with company: candidate_count is gone in the 3.x line, and the numeric thinking_budget has been replaced by a coarse thinking_level enum whose default dropped from high to medium. The pattern is unmistakable. Google is trading fine-grained numeric control for a handful of semantic switches, and it's not asking for your opinion.
Three vendors, one verdict
If this were just Google, you could write it off as API churn. It isn't. OpenAI's reasoning models — the o-series and the GPT-5 family — have rejected temperature, top_p, logit_bias, and friends with hard "Unsupported parameter" errors since o1 shipped, steering developers toward reasoning_effort and verbosity instead. Anthropic followed with Claude Sonnet 5, which returns a 400 on any non-default sampling value. Google is the last of the big three to fall in line, and its docs use nearly identical language to Anthropic's: the models are "optimized for the default settings," and if you want determinism, write it into the system prompt.
Three independent labs converging on the same restriction, within roughly a year of each other, is not a UX fad. None of them has published a real explanation, but the most credible hypothesis — floated in the Hacker News discussion of Google's change and consistent with everything we know about post-training — is that heavy reinforcement learning bakes in an expected sampling regime. A model whose long chain-of-thought behavior was trained and evaluated at one sampler configuration gets brittle when you shove it off that distribution. The sampler is no longer a knob in front of the model; it's part of the model. Handing it to users stopped being a feature and became a support liability.
There's a less charitable reading too: verifiable determinism knobs made cross-vendor benchmarking and regression testing easier, and semantic replacements like "add rules to your system instruction" are conveniently unfalsifiable. Both things can be true.
What actually breaks
The immediate damage isn't to prompt artisans who liked temperature: 0.7 for vibes. It's to production patterns that treated sampling as an API contract:
- Zero-temperature extraction pipelines. Thousands of structured-output workloads set
temperature: 0as a cheap proxy for reproducibility. On Gemini 3.6 Flash that setting is now a no-op, which means your pipeline's variance characteristics changed the day you bumped the model string — with no error to tell you. - Self-consistency ensembles. Sample N answers at high temperature, majority-vote the result. That technique needs diversity you can dial up. With sampler control gone (and
candidate_countunsupported), the pattern survives only through prompt-level variation, which is far less controllable. - Eval harnesses and research code. Reproducibility claims that hinge on pinned sampling configs are now vendor-dependent fiction for frontier API models.
- Abstraction layers. LangChain, LiteLLM, and every in-house wrapper that passes a default
temperatureto all providers will start throwing 400s as each vendor flips from "ignore" to "reject." OpenAI-side issue trackers have been full of exactly this failure since the o-series shipped.
The silent-ignore phase deserves particular scorn. An immediate 400, like Anthropic ships, is annoying but honest — CI catches it. Silently discarding a parameter changes production behavior with zero signal. Google confirmed on its own developer forum that pulling the sliders from AI Studio was intentional, while the API kept accepting the values it no longer honored. That's the worst possible transition design: the gap between "accepted" and "obeyed" is invisible until something downstream drifts.
Migrating without magical thinking
The mechanical part is easy — delete the keys:
# Before (Gemini 2.x era)
config = types.GenerateContentConfig(temperature=0.1, top_p=0.9, top_k=40)
# After (Gemini 3.x): strip sampling, steer with instructions and thinking_level
config = types.GenerateContentConfig(
system_instruction="Return only valid JSON. Choose the single most likely value for each field; never vary phrasing across identical inputs.",
thinking_config=types.ThinkingConfig(thinking_level="medium"),
)
The honest part is admitting what you lose. A system instruction saying "be deterministic" is a request, not a guarantee — an HN commenter's skepticism on this point is well placed. If your product genuinely requires reproducible outputs, your options are now: pin exact model versions and snapshot outputs, move determinism into post-processing (schema validation, canonicalization, retry-on-mismatch), or run open-weight models — Gemma, Llama, Qwen — where the sampler is still yours, with the caveat that those models increasingly ship narrow "recommended settings" for the same brittleness reasons.
Audit your wrapper libraries now, before Google flips ignore-mode to 400-mode. Grep for temperature in every generation config that touches a gemini-3 model string, and treat any hardcoded sampling default in shared client code as a latent outage.
The knobs aren't coming back
Sampling parameters were an artifact of the base-model era, when an LLM was a raw next-token distribution and shaping that distribution was legitimately the user's job. Post-trained reasoning models are a different artifact: the vendors tune weights, sampler, and thinking policy as one system, and they've concluded — with evidence we can't audit — that user-space sampling mostly made their models worse. They're probably right on average, and that "on average" is precisely the problem for anyone whose use case lived in the tails.
The realistic forecast: semantic controls (thinking_level, reasoning_effort, verbosity enums) become the standard surface for frontier APIs, and true sampler access becomes a differentiating feature of open-weight deployment. If your architecture depends on controlling the distribution rather than prompting the model, that's no longer a config option. It's a hosting decision.
Sources & further reading
- Using the latest Gemini models — ai.google.dev
- Gemini last models: temperature, top_p, and top_k are deprecated and ignored — news.ycombinator.com
- What's new in Gemini 3.5 Flash — ai.google.dev
- What's new in Claude Sonnet 5 — platform.claude.com
- Azure OpenAI reasoning models — learn.microsoft.com
- Was temperature and topP removal intentional? — discuss.ai.google.dev
Mariana covers the fast-moving world of machine learning and generative AI, with a particular focus on how these technologies are reshaping development workflows. When she isn't stress-testing the latest foundation models, she's usually at a local hackathon.
Discussion 0
No comments yet
Be the first to weigh in.