XT.PT The API → This story
Filed

Updated 06:46
Reporting
Prelo
Verified by Roger Morais
3 min · 481 words
News The API

Gemini retires the temperature knob: ignored today, an HTTP 400 tomorrow

Google's newest Gemini models drop the oldest sampling controls in the LLM API convention; determinism guidance moves into the prompt.

Filed04 Aug 2026, 05:22 UTC Length3 min · 481 words ReportingPrelo
Gemini

On July 21, a line in the Gemini API changelog retired the oldest knobs in the LLM API convention: "The sampling parameters temperature, top_p and top_k are now deprecated." The change lands with the general availability of gemini-3.6-flash and gemini-3.5-flash-lite, and Google's model documentation is explicit about scope: "Starting with Gemini 3.6 Flash and Gemini 3.5 Flash-Lite, the following API changes apply to these models and all future Gemini model releases."

Ignored today, fatal tomorrow

The migration shape is the story. Per the Gemini model documentation, the API currently ignores the parameters on the new models — requests that send them still succeed. But the same document warns: "In future model generations, supplying these parameters returns an HTTP 400 error."

That two-phase design punishes exactly the code that looks healthiest. A client that pins temperature: 0 for reproducible evals kept getting 200s after July 21 — it just silently lost the control it thought it had. The hard failure arrives later, bundled with a model upgrade, far from the commit that caused it. Google's guidance is blunt: remove the parameters from all requests now.

Determinism moves into the prompt

What replaces a numeric decoder control? Prose. The documentation's substitute guidance:

To improve determinism, define a system instruction with explicit rules for your specific use case.

Google, Gemini API documentation

That is a real philosophical shift: sampling stops being a client-side dial and becomes a server-side implementation detail, with the developer's remaining influence expressed through instructions and structured output — things the model interprets, not parameters the decoder obeys. It is worth saying that the numeric dial was always weaker than it looked: Anthropic's own Messages API reference — which still accepts all three parameters, describing temperature as the "Amount of randomness injected into the response" with a default of 1.0 — concedes that "even with temperature of 0.0, the results will not be fully deterministic."

The portability cost

The three parameters have been the closest thing to common ground across LLM providers; abstraction layers and eval harnesses pass them through as a matter of course. With Gemini's newest models ignoring them and future ones rejecting them outright, any wrapper that sends temperature unconditionally now needs per-provider, per-model-generation logic — and any benchmark that documented "temperature 0" as its reproducibility method needs a new sentence for Gemini results.

Google's changelog gives no reason for the deprecation. The same July 21 entry describes Gemini 3.6 Flash as offering "improved token efficiency and code/agentic planning capabilities at a lower price point than 3.5 Flash, resolving developer feedback around output verbosity" — models whose output behavior is tuned server-side, which is consistent with a vendor no longer wanting client fingers on the decoder. But that reading is ours; the documents state the what, not the why.

Primary sources: Gemini API changelog, Gemini latest model documentation, Anthropic Messages API reference, read 2026-08-04.

Corrections and source documents: contact the desk
Read next →
Read next
AI regulation · 4 min

OpenAI's compliance-day post says a lot about safety, and nothing about copyright

The API · 3 min

A refusal is a 200: the Claude stop_reason that breaks lazy clients