Google deprecated `temperature`, `top_p` and `top_k` in one changelog line on July 21, 2026. I sent requests that set all three to a model released a month later, and the API accepted them without a single word of warning.
The changelog entry is one sentence: "The sampling parameters temperature, top_p and top_k are now deprecated." It names no replacement. The models page does not mention the deprecation at all.
So the interesting question is not what the changelog says. It is what the API says, because that is what an application actually talks to.
The newest model still advertises the parameters Google retired
Asking the API about gemini-3.7-flash, which went generally available on August 13, 2026, returns the deprecated parameters as advertised defaults:
{ "name": "models/gemini-3.7-flash", "version": "3.7-flash-08-2026",
"inputTokenLimit": 1048576, "outputTokenLimit": 65536,
"temperature": 1, "topP": 0.95, "topK": 64, "maxTemperature": 2,
"thinking": true }
The same request against gemini-2.5-flash, a model that predates the deprecation, returns the identical four sampling fields with identical values. From the API surface alone there is no way to tell that anything was deprecated between them.
A deprecated request and a supported one look identical from the caller's side
A generateContent call carrying {"temperature":0.9,"topP":0.8,"topK":40} returned HTTP 200 with a normal candidate, on gemini-2.5-flash and on gemini-3.7-flash alike. No warning field in the body. Nothing in usageMetadata. And no deprecation header: the response carries x-gemini-service-tier, server-timing, the usual caching and security headers, and nothing that mentions the parameters at all.
So a deprecated parameter and a supported one are, from the caller's side, indistinguishable. The request that a linter or a migration script could flag looks exactly like the request that is fine.
The behaviour question stayed open, and the quota is why
Whether temperature still shapes the output distribution on the newest model is open, and I am not claiming it either way. Free-tier quota returned HTTP 429 across most of a sampling run, so the comparison I wanted, the same prompt many times at temperature 0 against temperature 2, does not have enough successful calls behind it to mean anything.
The probe is in the repository at docs/news-research/gemini-temperature-probe.mjs, and every response it collected, including the failures, is archived beside it in gemini-temperature-raw.json. Run it against your own key and you will have a larger sample than I do.
Evidence and limits
Tested on August 20, 2026 against v1beta with a free-tier key, at no cost and with no paid tier enabled. Two models, text generation only, no batch and no cached content. The claim here is narrow on purpose: it is about the API surface and the documentation disagreeing, not about how either model behaves.
The changelog entry was confirmed to still read the same way on the day this published. If Google had withdrawn the deprecation in the meantime, the release would have failed instead of publishing this.
Treat a deprecated knob as frozen, whatever the API keeps accepting
No shutdown date has been announced, so this is not urgent in the way a dated removal is. The practical difference is that a removal with a date can be scheduled, while a deprecation with no date and no API signal can only be watched.
Two things are worth doing now. Record where your code sets these parameters, so the eventual removal notice is a search rather than an audit. And treat a deprecated knob as frozen: if your prompts currently depend on tuning top_k, that dependency is now on a documented dead end, whatever the API keeps accepting. The whole check takes about a minute against a free key, which is less time than it will take to find those call sites later.