Gemini 3.6 Flash ignores three settings your app may still send

Google released gemini-3.6-flash and gemini-3.5-flash-lite as generally available API models on July 21, 2026. Starting with these models, the API accepts temperature, top_p, and top_k but ignores their values. An application can therefore receive a successful response while three settings its maintainers believe they control are doing nothing.

That silent behavior is only one part of the migration. A legacy generateContent request whose last non-empty turn has the model role already fails with HTTP 400, including when sent directly over REST. Google says future Gemini model generations will also reject the deprecated sampling fields. This article separates those outcomes, shows where the affected configuration tends to hide, and gives teams a practical basis for changing model IDs now or cleaning and re-testing the integration first.

One migration now has three different request outcomes

Google describes both exact model IDs as GA and ready for production use. Gemini 3.6 Flash defaults to a thinking_level of medium, while Gemini 3.5 Flash-Lite defaults to minimal. Those defaults matter during migration because the old sampling fields no longer have their expected effect while thinking_level remains supported.

Scroll sideways to see all 3 columns.

Request field or shape	Documented outcome	Time boundary
temperature, top_p, or top_k	Accepted but ignored on gemini-3.6-flash and gemini-3.5-flash-lite	Current exact models
Trailing non-empty model turn in a legacy generateContent request, including a direct REST payload	HTTP 400	Already enforced
Deprecated sampling fields on future Gemini model generations	HTTP 400	Later; Google has not named the first rejecting model or a date

The first row is the easy one to misread. The current GA models do not reject the three sampling fields. They disregard them, so a 200 response cannot confirm that the requested temperature or token-sampling limits took effect.

The second row concerns the conversation shape used by legacy generateContent requests, including direct REST payloads. Some integrations append a partial model response to make the next answer begin with a phrase, omit a preamble, or continue in a desired format. If that prefilled model turn is the last non-empty turn, the request is invalid now. The Interactions API does not use manually prefilled model turns; Google recommends a system instruction for behavioral guidance and structured outputs when the response must follow a schema.

The third row is a stated future failure with an unspecified start. Google has not said which future model generation will first reject temperature, top_p, and top_k or when that generation will arrive. Treat acceptance on the current exact GA IDs and rejection in future model generations as separate facts.

A no-op setting is more dangerous than a visible error

An HTTP 400 stops the request and points maintainers toward the payload. An ignored field leaves the system running while preserving a false explanation for its behavior. A shared configuration file may still say temperature: 0, an admin screen may still expose a creativity slider, and an evaluation record may still attribute an output change to a value the model never used.

That mismatch makes later debugging harder. If a team believes low temperature constrained wording, it may interpret variation as a prompt defect or an inference anomaly. If it believes top_k limited token choice, it may credit that setting for output quality that came from the model, system instruction, thinking level, or another part of the request.

This differs from the issue explained in Temperature Zero Doesn't Mean Deterministic. That article covers why a supported temperature=0 setting still does not guarantee identical production output. Here, the documented problem is simpler: on these two models, the temperature value is ignored altogether. Removing it corrects the request and the team's account of how the application works; it does not create determinism.

Search the payload path, not only the prompt

The affected fields may be far from the code that selects the model. Search shared generation configuration, provider adapters, SDK wrappers, and the final serialized request. Check raw REST payloads as well as calls built through an SDK, because Google has not established one universal behavior for every SDK version: a client might strip an old field, warn about it, or forward it unchanged.

Stored prompt templates can also carry generation settings beside the prompt text. Conversation-history builders and evaluation fixtures may preserve old payload fragments long after the production call site changes. Search those paths for the exact names temperature, top_p, top_k, thinking_budget, and candidate_count, then inspect generated requests rather than stopping at source-code matches.

For a move to Gemini 3.6 Flash, Google's migration guide says to replace thinking_budget with thinking_level set to medium or high, remove candidate_count, remove prefilled model turns, and audit function calling. Review conversation builders for a final non-empty model turn even when no literal prefill appears in a template; a helper may construct that turn from stored history. generateContent requests remain relevant whether they are sent through an SDK or directly to its REST endpoint, even though Google recommends the GA Interactions API for new projects.

Removing the old fields does not prove equivalent behavior

Deleting deprecated fields proves that the cleaned request no longer claims to set them. It does not prove that the new model will produce equivalent results for a particular workload. The old values may already have been ignored on the new model, but the model change, default thinking level, prompt handling, function-calling behavior, and surrounding adapter can still change what the application does.

Re-run representative production work with the exact model ID and the cleaned request. “Representative” should follow the work the business accepts, rejects, edits, or escalates. A support workflow needs the difficult ticket types and policy exceptions that reach human review, while an extraction workflow needs the document variants and missing-field cases that determine whether downstream records are usable.

Compare accepted business output first. Then inspect structured-output validity, function and tool behavior, retries, latency, input and output token counts, and failure categories. A schema-valid answer can still contain an unacceptable decision; a correct final answer can still require enough retries or tool calls to make the workflow slower or more expensive. Keep these measures separate so a formatting improvement does not conceal a business-quality regression.

Capture failures at the boundary where they occur. Distinguish an HTTP validation error, malformed structured output, failed function call, tool error, timeout, exhausted retry, and human rejection. That separation prevents adapter or fixture defects from being counted as model failures, a problem discussed in Put your AI model bake-off on trial. The useful evidence is production-shaped, but this migration does not need a leaderboard; it needs enough replay to support the model decision for the actual workflow.

Do not assume that passing results under the old model form a fixed reference answer. Some tasks allow several acceptable outputs, while others depend on exact schema values or business rules. Preserve the acceptance criteria and review notes that made earlier results usable, then compare the new run against those criteria. That tells the team whether the integration still does the job, even when the wording changes.

Pin the exact model and keep product surfaces separate

Use gemini-3.6-flash or gemini-3.5-flash-lite explicitly during migration and record which one produced each evaluation run. A moving alias can change independently of the application, making a later comparison ambiguous. The model page identifies gemini-3.6-flash as the stable API ID; that is a clearer test target than a product label or a downstream rollout name.

API status, API surface, and downstream product availability are different facts. Google calls these two model IDs GA, while another product may expose one gradually or use its own policy label. The Interactions API is also GA and recommended for new projects. Its generation_config can carry the deprecated sampling fields, but it does not use manually prefilled model turns. Legacy generateContent calls, whether sent through an SDK or directly to REST, can carry both the deprecated fields and the invalid trailing model turn described here.

The Gemini Interactions API explainer covers how that API stores state and represents multi-step work. It is useful when the migration also changes API surface. A switch to Interactions should still be evaluated separately from the model change, or the team will have trouble identifying whether a result came from the model, request cleanup, state handling, or all of them together.

Google's launch post emphasized efficiency and capability, and much of the Hacker News discussion followed the same price-and-performance framing through conflicting personal anecdotes. Reuters independently confirmed the July 21 release. Neither launch coverage nor community experience answers whether a specific application's old request is valid or whether its accepted outputs remain usable; the developer guide and local replay answer those questions.

Migrate when you can inspect the final request

Change the model ID now if the team can inspect the final serialized request, remove the deprecated fields and invalid trailing turns, account for the supported thinking settings, and replay representative work before wider release. Pin the exact ID during that evaluation and monitor the same business acceptance and failure categories after deployment. This removes a known compatibility problem before a later model rejects the request.

Hold the model-ID change if provider-specific generation configuration is still hidden behind shared adapters, if the SDK's handling of deprecated fields is unknown, or if no representative acceptance baseline exists. Use that time to make the outgoing payload visible, clean the request, and establish the replay set. Holding should be a short dependency decision with an owner and an exit condition, because Google has already said future generations will reject these fields even though it has not supplied the model or date.

For teams with production integrations that carry provider-specific generation configuration, BaristaLabs can help trace the payload and test the migration against real accepted outputs through our process automation work. Contact BaristaLabs about a Gemini request migration when the model decision depends on evidence from the working integration rather than an isolated prompt sample.

Sources

• Google AI for Developers: Using the latest Gemini models: GA status, defaults, deprecated sampling fields, turn validation, and migration guidance; page last updated July 23, 2026 UTC.
• Google AI for Developers: Gemini 3.6 Flash model page: exact stable model ID and API model status.
• Google: Introducing Gemini 3.6 Flash, 3.5 Flash-Lite, and 3.5 Flash Cyber: July 21 launch timing and Google's efficiency framing.
• Reuters: Google updates lightweight Gemini models, but flagship still delayed: independent confirmation of the July 21 model release.
• Hacker News discussion: Gemini 3.6 Flash: community discussion referenced for its conflicting anecdotes and price/performance focus, not as performance evidence.