Gemini 3.6 Flash and 3.5 Flash-Lite Ignore Temperature, Top-P, and Top-K

Google's Gemini 3.6 Flash and Gemini 3.5 Flash-Lite ignore temperature, top_p, and top_k, according to Google's current migration guide. Existing Gemini requests could send those sampling parameters, which are model-request settings intended to influence token selection. For developers migrating Gemini integrations, a request can remain syntactically valid while losing controls an application expected. Google says the named models are generally available and ready for production use, so the change concerns current deployment targets rather than a preview-only behavior.

The three parameters are deprecated. Google says Gemini 3.6 Flash and Gemini 3.5 Flash-Lite ignore them and tells developers to remove them from all requests. The guide also says that future model generations will return HTTP 400 when the parameters are supplied. The immediate issue is therefore not a current request failure: code that sends these fields can keep receiving a response even though those fields no longer affect the named models.

The migration changes a request without changing its shape

temperature, top_p, and top_k are sampling controls: settings used to influence how a language model selects its next tokens. They are different ways of constraining or varying that selection, and an integration may have set them deliberately when it was built. Google's documentation does not say every Gemini application uses them, or quantify the change for a particular prompt. It does establish that code which does use them needs a migration even if its payload and response format have not otherwise changed.

That distinction matters for testing. A check that an API call succeeded cannot establish whether an application still has the output behavior it expected from those settings. Google's documentation supports a narrower conclusion: after removing the deprecated fields, developers should test the prompts, output constraints, and model version they actually deploy. The documentation does not make an explicit response rule a numerical substitute for the former sampling configuration.

Google points to explicit instructions for response rules

Google says that a system instruction, an instruction supplied with a model request that sets rules for the response, can improve determinism for a specific use case. The migration guide also directs applications that formerly used prefilled model turns to system_instruction or structured outputs when they need to specify output format.

Those controls address different parts of an application request. An explicit instruction can state how a response should behave, and a schema can constrain an output's structure. Neither claim establishes that they recreate the probability distribution produced by temperature, top_p, or top_k; Google does not make that equivalence claim. Google's migration guidance is more modest: remove the deprecated parameters, use explicit instructions or structured outputs where an integration needs them, and verify the resulting behavior on the target model before treating the migration as complete.

What I'm building

Delegate tasks. Get software.

Give Vroni a GitHub issue, bug report, spec, or rough idea. It reads the repo, plans the change, writes code, runs checks, and works toward a review-ready pull request.

Take a look at vroni.com