Gemini 3.6 Flash Migration: Five API Changes and One Silent Failure

TL;DR Migrating to gemini-3.6-flash or gemini-3.5-flash-lite involves five request changes. Four of them return HTTP 400, so you find out immediately. One of them does not: temperature, top_p and top_k are now accepted and ignored. If your pipeline relies on temperature=0 for stable output, it will keep returning 200 OK while the guarantee you were counting on is gone. Fix that one first, then the four loud ones.

Last verified: 2026-07-21

If you are swapping a model ID in a config file and expecting the rest to keep working, read the first section before you deploy.

The five changes, ranked by how you find out

Four of these five failures announce themselves. Your integration tests catch them, your error tracker pages you, you fix them in an afternoon. The first one is the one that reaches production.

The dangerous one: temperature, top_p and top_k are now ignored

Read that sequence carefully, because the order matters to you. Today the parameter is a no-op. Later it becomes an error. That means the period where you are most likely to be wrong about your own system is right now, while everything still returns 200.

Which pipelines break without an error

A silent no-op is only dangerous if you were depending on the parameter. Four common setups were:

• Determinism pipelines. Anything that sets temperature=0 to make repeated calls agree with each other: cache keys built from model output, deduplication passes, classification jobs that feed a downstream state machine. The setting is now inert, so whatever output stability it was buying you is no longer being bought.
• Golden-file and snapshot tests. Suites that pinned temperature=0 and diff the model's output against a stored expected string. These start flaking after the model swap, and the flake looks like a model quality regression rather than a config problem, which sends you debugging in the wrong direction.
• Structured output held together by low temperature. Teams that never adopted structured outputs and instead kept temperature near zero plus top_p tight so the model would reliably emit parseable JSON. Both knobs are now inert at once.
• Tuned per-route configs. Products that expose a creativity slider, or route "summarize" at one temperature and "brainstorm" at another. The slider still moves in your UI. It no longer moves anything in the model.

None of these produce a stack trace. They produce output that is slightly different from what you validated, in a system that reports itself healthy.

Your gateway will not warn you either

This is the part that catches even careful teams. Model gateways publish machine-readable metadata describing which parameters each model supports, and tooling reads that metadata to decide what to send.

What replaces temperature

Google's stated replacement is not another parameter. It is the system instruction: write the behavior you want as a rule the model reads, rather than as a sampling constant.

That is a real change in how you express intent, so translate rather than delete:

How to find every call site before you deploy

Search your codebase for the parameter names rather than trusting the config layer, because these values are usually set in several places by different people:

# Gemini-native and OpenAI-compatible spellings, plus the config objects that carry them
grep -rn "temperature\|top_p\|topP\|top_k\|topK\|candidate_count\|candidateCount" \
  --include="*.py" --include="*.ts" --include="*.js" --include="*.go" --include="*.java" .

# The wrappers that hide them
grep -rn "generation_config\|generationConfig\|GenerateContentConfig\|thinking_budget\|thinkingBudget" .

Check the results outside application code too: YAML and JSON config, prompt-management tools, notebooks, eval harnesses, and any Terraform or admin console that stores model settings. A knob set in a dashboard six months ago is exactly the kind of thing that survives a code review.

The four that fail loudly

These are simpler, because the API tells you. Fix them in whatever order your test suite surfaces them.

thinking_budget and thinking_level cannot both be present

Two defaults worth knowing while you pick a value, because they differ between the two models:

• gemini-3.6-flash defaults to medium.
• gemini-3.5-flash-lite defaults to minimal, which is tuned for throughput.

You can no longer prefill a model turn

Both of those goals move into the same two places as everything else: a system instruction that states the rule, or structured outputs when you need a machine-parseable shape. Search your code for any request builder that appends a final assistant or model message, especially retry and continuation logic, which is where prefills tend to be generated dynamically rather than written literally.

Every FunctionResponse needs call_id and name

candidate_count is gone

Before and after: a request that migrates cleanly

Here is a Gemini-native call carrying every deprecated field, and the version that survives the move.

# BEFORE: works on 2.5-era models, breaks or silently misbehaves on 3.6 Flash
config = {
    "temperature": 0,          # now ignored, no error
    "top_p": 0.95,             # now ignored, no error
    "top_k": 40,               # now ignored, no error
    "candidate_count": 1,      # unsupported in Gemini 3.x
    "thinking_budget": 8192,   # 400 if it meets thinking_level
}

# AFTER: intent moved from sampling constants into instructions
config = {
    "system_instruction": (
        "Answer in at most three sentences. Use plain declarative statements. "
        "Do not add a preamble, restate the question, or offer follow-ups. "
        "If the answer is uncertain, say so in one sentence."
    ),
    "thinking_level": "medium",
}

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["EVOLINK_API_KEY"],
    base_url="https://api.evolink.ai/v1"
)

response = client.chat.completions.create(
    model="gemini-3.6-flash",
    messages=[
        {"role": "system", "content": "Answer in at most three sentences. No preamble."},
        {"role": "user", "content": "Summarize this incident report."}
    ]
    # no temperature, no top_p: they would be accepted and ignored downstream
)

print(response.choices[0].message.content)

import OpenAI from "openai";

const client = new OpenAI({
  apiKey: process.env["EVOLINK_API_KEY"],
  baseURL: "https://api.evolink.ai/v1",
});

const response = await client.chat.completions.create({
  model: "gemini-3.6-flash",
  messages: [
    { role: "system", content: "Answer in at most three sentences. No preamble." },
    { role: "user", content: "Summarize this incident report." },
  ],
  // no temperature, no top_p
});

console.log(response.choices[0].message.content);

A migration order that catches the silent failure

The sequence matters, because the loud errors are easy and the quiet one is not. Do it in this order:

1. Inventory first. Run the greps above and list every place a sampling parameter is set, including config stores and dashboards. Write down which behavior each one was protecting.
2. Translate intent, do not just delete. For every temperature you find, decide what it was for and write the equivalent system instruction. Deleting without translating is how you ship a quality regression.
3. Fix the 400s. Swap thinking_budget for thinking_level, remove candidate_count, remove prefilled model turns, add call_id and name to every FunctionResponse.
4. Choose a thinking level on purpose, especially on Flash-Lite, where the minimal default is unsuitable for autonomous multi-step work. This is also the largest cost lever in the migration: on our task set, 3.6 Flash at minimal cost 73.6% less per pass than the same model at the medium default, and thinking tokens accounted for 85% of billed output at medium. Whether your workload survives the drop is the thing to test, not whether the saving is real.
5. Re-baseline your snapshot tests against the new model before you compare anything. Old golden files were produced under a parameter that no longer applies, so they are not a valid reference point.
6. Run your evals on both models over the same task set and compare output distributions, not just pass rates. Silent behavior changes show up as drift in format, length and verbosity before they show up as wrong answers.
7. Canary on real traffic and watch downstream parsers, not just the API error rate. If something is going to break quietly, it breaks in the code that consumes the model's output, not in the call itself.

Let Google's migration skill do the first pass

npx skills add google-gemini/gemini-skills --skill gemini-interactions-api --global

Then, in a coding agent, point it at your project:

It is worth running. It handles the mechanical work: finding deprecated fields, rewriting request construction, updating call sites, which covers most of step 3 above.

Retirement schedule: when the choice stops being yours

Computer Use: four official pages, two answers

One capability question cannot be settled from documentation right now. Whether these models support Computer Use is stated inconsistently across Google's own material:

• The Gemini API model documentation marks Computer Use as supported (preview) for 3.6 Flash, while the enterprise platform page for the same model lists it as not supported.
• For 3.5 Flash-Lite, the model pages say it is not supported, while the launch announcement and the Gemini 3 developer guide say it works.

Four official pages, two contradictory answers, no way to resolve it by reading. If Computer Use is on your critical path, probe it on your own account and endpoint before you commit, and keep a fallback model wired up. This section will be updated with a tested answer and the date it was observed. Every other change in this guide is documented consistently; this one is not.

What this means if you are re-picking a provider this week

A migration you did not schedule has landed on your sprint, and the work is a day or two of careful editing rather than a weekend rewrite. Since you are already touching every call site, this is a natural moment to look at how the model reaches you at all.

Two things are worth checking while you are in there:

• Can you run the old and new models side by side during the cutover? Step 6 above requires it. If your setup makes running gemini-3.5-flash and gemini-3.6-flash against the same task set awkward, that friction will be there for the next migration too, and there will be a next one: Google has said these rules apply to every model released from here on.
• How fast does a new model become callable for you? gemini-3.6-flash reached general availability with no preview suffix on day one. The gap between a model shipping and your code being able to call it is a cost you pay on every launch.

FAQ

Sources

• Using the latest Gemini models (Google AI for Developers): deprecated sampling parameters, thinking_level, candidate_count, prefill restriction, FunctionResponse requirements, migration skill command
• Gemini deprecations (Google AI for Developers): shutdown dates and recommended replacements
• Gemini API models (Google AI for Developers): model IDs, capability support matrix
• Gemini 3 developer guide (Google AI for Developers): Gemini 3 request behavior and capabilities
• Gemini 3.6 Flash on Gemini Enterprise Agent Platform (Google Cloud): enterprise capability listing and displayed parameter defaults
• Introducing Gemini 3.6 Flash, 3.5 Flash-Lite, and 3.5 Flash Cyber (Google): launch announcement and release date
• google-gemini/gemini-skills (GitHub): the official migration skill
• OpenRouter models endpoint (OpenRouter): gateway metadata listing temperature, top_p and seed as supported parameters for both models, observed 2026-07-21
• EvoLink model catalog, Gemini 3.6 Flash release tracker, Gemini 3.6 Flash vs Gemini 3.5 Flash, Gemini 3.5 Flash vs Gemini 3 Flash Preview migration guide, Gemini 3 Pro deprecation guide, EvoLink API base URL