Google just pushed Gemini 3.6 Flash and 3.5 Flash-Lite to general availability. While the new models target specific builder needs—cost-effective subagents and more efficient planning—the most significant change is the deprecation of temperature, top_p, and top_k. This isn't a minor API tweak; it forces a more disciplined, instruction-driven approach to prompting.
two new specialized tools
The July 21st release brought two distinct models into production, each with a clear purpose.
First, Gemini 3.6 Flash is positioned as an upgrade designed to address direct developer feedback about output verbosity. It features improved token efficiency and better capabilities for code and agentic planning, all at a lower price point than its predecessor. This is the model you use for general tasks where you need a balance of performance and cost, with less unwanted chatter in the response.
Second, Gemini 3.5 Flash-Lite is a purpose-built tool for a specific job: high-volume automation. It’s described as a low-latency, highly cost-effective option for “subagent” tasks. This signals a clear direction toward building more complex, multi-agent systems where smaller, faster, cheaper models can be spun up to handle discrete, repetitive parts of a larger workflow, while a more powerful model acts as the orchestrator.
the end of temperature tuning
The most impactful change for engineers using the API is the deprecation of the main sampling parameters. For gemini-3.6-flash and gemini-3.5-flash-lite, the temperature, top_p, and top_k parameters are now ignored. The familiar workflow of cranking up the temperature for more “creative” outputs or lowering it for more deterministic ones is gone.
The official guidance is to now use system instructions to control model behavior. To get deterministic responses, you must define explicit rules for the model to follow. This shifts the burden of control from tweaking API parameters to authoring more robust prompts. Instead of relying on a stochastic sampler to vary your outputs, you now have to explicitly architect the desired output structure, style, and constraints within your instructions.
what this means for your api calls
This change requires a practical shift in how you structure your code. You can no longer pass a generation_config object with sampling parameters and expect it to have an effect. The logic for controlling output must move into the system_instruction content.
Here’s a conceptual example of the shift. Previously, you might have done this to get a concise JSON output:
# Before: Relying on sampling parameters
import google.generativeai as genai
model = genai.GenerativeModel('gemini-1.5-flash') # An older model
response = model.generate_content(
"Extract the user's name and city from this message: 'Hi, I'm Alex from Toronto.'",
generation_config={
"temperature": 0.1, # Low temp for factual extraction
"top_p": 1.0,
"response_mime_type": "application/json",
}
)
Now, with the new models, you would achieve determinism through explicit instructions, not sampling config.
# After: Using explicit system instructions
import google.generativeai as genai
# New models ignore temperature, top_p, top_k
model = genai.GenerativeModel(
'gemini-3.6-flash',
system_instruction="You are a text processing utility. Your only function is to extract entities from user text. Respond with ONLY a valid, minified JSON object containing 'name' and 'city' keys. Do not add any commentary or markdown formatting."
)
response = model.generate_content(
"Hi, I'm Alex from Toronto.",
generation_config={
# Note: temperature, top_p, top_k are ignored here
"response_mime_type": "application/json",
}
)
This approach forces better prompt engineering hygiene and makes the model's expected behavior more explicit and auditable, as the instructions live alongside the code.
the takeaway
This release is more than a model version bump. It’s a statement about where API-driven generation is heading. The move away from sampling parameters toward explicit system instructions is a bet on structured prompting over probabilistic tweaking. For builders, this means the core skill is less about fiddling with API knobs and more about architecting clear, unambiguous instructions for the model to execute. It’s a shift toward treating the model less like a creative oracle and more like a deterministic function that you program with natural language.
Top comments (0)