Gemini 3.6 Flash and 3.5 Flash-Lite: Fewer Knobs, More Managed Control
Gemini 3.6 Flash and 3.5 Flash-Lite: Fewer Knobs, More Managed Control
Google's newest Flash release makes more sense when you put three comparisons next to one API change.
On the current Artificial Analysis Intelligence Index, Gemini 3.6 Flash scores 50 and Gemini 3.5 Flash scores 50. The newer model produced roughly 59 million output tokens instead of 75 million across that evaluation, while its standard output price fell from $9 to $7.50 per million tokens. At the same time, Google made three familiar controls—temperature, top_p, and top_k—do nothing on direct calls to its newest models.
That combination is more revealing than a launch chart. Gemini 3.6 Flash is not evidence of a broad generational intelligence jump. It is an efficiency-and-behavior revision: similar aggregate capability in one independent snapshot, fewer tokens, and a cheaper output meter. Google separately reports selective gains in coding and agent tests, including fewer execution loops.
The API changes point in the same direction. Google is moving optimization away from token-distribution knobs and toward provider-defined controls: thinking levels, schemas, tool protocols, server-side interaction state, managed routing, and context compaction. The model is becoming one part of an execution contract that Google increasingly defines across its API and managed-agent surfaces.
That is also why Gemini 3.5 Flash-Lite and the gated Gemini 3.5 Flash Cyber belong in the same story. Flash-Lite turns thinking effort into a throughput choice. Flash Cyber turns repeated model calls, CodeMender orchestration, access screening, and validation into the product. The headline is two new API IDs. The durable change is that the harness now defines more of what “the model” means in production.
A release board, not a simple model ladder
Google announced the family in one combined launch post, then made gemini-3.6-flash and gemini-3.5-flash-lite generally available on July 21, according to the Gemini API changelog. Both accept text, images, video, audio, and PDFs and return text. Their dedicated model pages list a 1,048,576-token input ceiling and 65,536-token maximum output: 3.6 Flash specs and 3.5 Flash-Lite specs.
The three names announced together do not have the same release status:
| Model | Standard input / output | Default thinking | Release shape |
|---|---|---|---|
gemini-3.6-flash | $1.50 / $7.50 per 1M | Medium | GA API model; new Antigravity default |
gemini-3.5-flash-lite | $0.30 / $2.50 per 1M | Minimal | GA API model for high-volume work |
| Gemini 3.5 Flash Cyber | Not published | Not published | Coming to a limited CodeMender pilot |
Google's pricing page also lists Batch and Flex at half the standard input and output rates, with higher Priority rates. Those tiers matter for a fleet, but they do not change the core comparison: 3.6 keeps 3.5 Flash's $1.50 input price and cuts its output rate by 16.7%.
The model cards add useful restraint. Gemini 3.6 Flash is based on 3.5 Flash, while 3.5 Flash-Lite is based on 3.1 Flash-Lite. Google gives both a March 2026 knowledge cutoff but does not disclose parameter counts or detailed architectures. The company presents them as derivatives of earlier Flash models, not as a disclosed new foundation generation.
The 50-to-50 upgrade
The cleanest independent launch-day signal is not a dramatic intelligence gain. It is a different cost curve.
The source pages are worth reading directly because these figures can move: Gemini 3.6 Flash on Artificial Analysis and Gemini 3.5 Flash on Artificial Analysis. At the time of writing, the result is roughly 21.3% fewer output tokens and 30.2% less evaluation cost for the same composite score.
That does not mean 3.6 has no quality gains. Google's migration guide says it performs better on complex agentic, coding, spatial, and multimodal work; uses fewer steps, turns, and tool calls; spirals less in execution loops; and makes fewer unwanted edits. The same guide admits that human evaluators preferred older models on some visual layout and styling tasks. That mix sounds like a tuned worker, not a universal upgrade.
Google's own evaluation disclosure reports larger selective gains, including SWE-Bench Pro at 58.7 versus 55.1, OSWorld-Verified at 83.0 versus 78.4, and the one-million-token MRCR test at 54.0 versus 26.6. Those are vendor-run launch evaluations, not independent replications, so they should shape a test plan rather than close the case.
There are two potential efficiency dividends. Google says 3.6 uses 17% fewer output tokens than 3.5 Flash on its Artificial Analysis comparison. Combine that claimed volume reduction with the 16.7% output-rate cut and, holding quality and everything else constant, output spend falls about 30.8% per task. The current independent evaluation cost is directionally similar, but it is a separate snapshot with its own inputs and cache behavior.
Google removed the knobs from the request—and added them to the system
The most consequential migration change is easy to miss because today's failure mode is silence.
For direct calls to 3.6 Flash and 3.5 Flash-Lite, Google says temperature, top_p, and top_k are deprecated and ignored. A dashboard can therefore show a carefully tuned temperature while the model behaves as if that setting does not exist. Google says a future model generation will turn the same fields into HTTP 400 errors.
The managed-agent surface is stricter today. Antigravity's limitations list says those three fields—and stop_sequences and max_output_tokens—already return HTTP 400. This is another reason to canary raw-model and managed-agent integrations separately: they share an underlying checkpoint without sharing every request rule.
Other controls change immediately. A request ending in a non-empty model-role turn for response prefilling now returns HTTP 400. candidate_count is unsupported across Gemini 3.x. thinking_budget gives way to the string-valued thinking_level. Function responses in the legacy generateContent path need both call_id and name.
The control surface moved upward. Builders still steer the system, but increasingly through Google-specific semantics and runtime configuration rather than token sampling.
| Old control | Behavior now | Migration |
|---|---|---|
temperature, top_p, top_k | Direct models ignore them; Antigravity rejects them now; future raw generations will reject them | Remove them, use supported semantic controls where applicable, and validate behavior with evals |
| Model-turn response prefill | HTTP 400 | Use structured outputs or explicit system instructions |
thinking_budget | Replaced | Choose thinking_level for the deployed task |
candidate_count | Unsupported in Gemini 3.x | Run and score separate requests when multiple candidates are required |
| Client-held turn history | Still possible, but not the preferred state model | Use previous_interaction_id with the GA Interactions API |
This is not the end of developer control. It is a change in the level where control lives:
sampling distribution -> thinking effort
response prefill -> schemas and system instructions
local turn assembly -> server-side interaction state
raw model call -> model + tools + routing + compaction
The upside is a smaller set of controls tied to the jobs developers actually care about. The downside is abstraction leakage. A multi-provider layer can normalize a temperature field; it cannot pretend that Google's thinking levels, thought signatures, Interactions state, tool protocol, and managed-agent routing are interchangeable with another provider's system.
Silently ignored fields are especially dangerous because they create configuration theater. Remove them now and make CI reject stale generation configs. RohitAI's recent analysis of API aliases and migration debt made the same operational point from a different provider: a model migration is often a contract migration wearing a new ID.
The agent ID stayed put while the model moved
Antigravity makes the new contract concrete.
The managed-agent identifier remains antigravity-preview-05-2026. Yet Google's latest-model guide says Gemini 3.6 Flash is now the default model behind that agent, and the Antigravity documentation says the underlying model can be changed through agent_config.
An application can therefore keep the same outer agent string and receive a different default model, different behavior, different output volume, and different failure patterns. That is not inherently bad—managed services exist to improve underneath stable interfaces—but it changes the minimum viable audit log.
effective agent identity =
agent ID
+ resolved model
+ thinking level
+ agent configuration
+ enabled tools
+ compaction policy
+ client version
Log that tuple for every consequential run. Canary the raw gemini-3.6-flash path separately from Antigravity because the managed agent adds a Linux sandbox, a planning loop, tools, persistent files, and automatic context management. A raw-model pass does not validate the harness, and a managed-agent pass does not isolate the checkpoint.
The same documentation says Antigravity automatically compacts context at roughly 135,000 tokens. That is sensible for long-running work, but it means the advertised one-million-token model capacity and the agent's active conversational state are not the same product surface. A summary produced during compaction can preserve the plan while dropping a constraint that mattered. You have to test the transition, not merely trust the maximum window.
Flash-Lite has two price tags
Google calls Gemini 3.5 Flash-Lite its most cost-efficient GA model and the lowest-cost model in the 3.5 family. Both statements can be true while a common inference is false: 3.5 Flash-Lite is not cheaper per token than 3.1 Flash-Lite.
For standard text, image, and video workloads, the input price rises from $0.25 to $0.30 per million tokens, a 20% increase. Output rises from $1.50 to $2.50, a 66.7% increase. On those workloads, the new model only wins economically if higher throughput, better tool reliability, fewer retries, or a higher completion rate offsets that premium. Audio input has a different comparison because 3.1 Flash-Lite charged $0.50 per million.
There is also an invisible second price tag: thinking effort.
The API defaults 3.5 Flash-Lite to minimal thinking, which is appropriate for extraction, routing, and high-volume parsing. But Google's published Flash-Lite evaluation ran the headline benchmark rows at high thinking. Those scores describe a different operating point from the production default. A buyer cannot infer minimal-thinking quality, latency, or task cost from a high-thinking launch table.
Keep stable extraction, classification, and routing workloads on the older Lite route when its lower token price and measured acceptance rate still win.
Use the new Lite tier for high-volume document and subagent work after measuring completion, tool reliability, latency, and cost per accepted task.
Route multimodal reasoning, coding, multi-step tools, and tasks that fail prematurely on Lite to the stronger worker rather than raising every request to high thinking.
One launch-day documentation conflict deserves a test rather than a guess. The combined latest-model guide says Flash-Lite has the full built-in-tool suite and separately says Computer Use is supported. Its dedicated model page says Computer Use is not supported. Until Google reconciles those pages, capability-probe the endpoint and keep Computer Use out of a production dependency contract.
One million tokens can admit the prompt without preserving the job
A context limit answers one question: will the API accept this much input? It does not answer whether the model will retrieve the right fact at the far edge, whether a managed agent will keep every turn active, or whether a compacted summary will preserve the constraint that decides success.
Google's own MRCR disclosure makes the distinction visible. At one million tokens, 3.6 Flash scores 54.0 and Flash-Lite 21.3 in their respective vendor evaluation tables. Those are not failure rates, and the Lite run used high thinking, but neither number supports the idea that a 1M acceptance limit delivers perfect full-window recall.
For a real agent, memory architecture remains product work. Keep source-of-truth state outside the prose transcript. Store decisions, constraints, completed actions, test results, approvals, and unresolved risks as explicit artifacts. Test needles near the beginning, around likely compaction boundaries, and after several tool loops. A million-token label does not retire retrieval, checkpoints, or state summaries.
Flash Cyber is the controlled experiment, not a third GA tier
Gemini 3.5 Flash Cyber shows the same managed-stack strategy in a higher-risk domain.
Google describes it as a lightweight specialist built on 3.5 Flash and fine-tuned to find, validate, and patch vulnerabilities. It has no public model ID, price, quota, context limit, region list, SLA, or dedicated model card. The DeepMind announcement says it will be available soon through a limited CodeMender pilot for governments and trusted partners, with access expanding over time. The current CodeMender preview documentation still lists 3.5 Flash, 3.1 Pro Preview, and 3 Flash Preview—not Flash Cyber. Do not design a public product around it yet.
The benchmark headline belongs to the whole system rather than only the checkpoint. Google reports 83.2% on CyberGym when CodeMender may call Flash Cyber up to five times for one final report. Google's own chart places that result below GPT-5.6 Sol at 83.6%, Mythos 5 at 83.8%, and GPT-5.5-Cyber at 85.6%; the competitor values are marked as provider self-reports.
CyberGym Level 1 contains 1,507 historical vulnerabilities across 188 OSS-Fuzz projects. The agent receives a vulnerability description and unpatched code and must produce a proof of concept that triggers before the patch but not after it. That is a useful known-vulnerability reproduction test. It is not a blind zero-day discovery benchmark or a safe-patching score.
The interesting product claim is horizontal search. A lightweight specialist can examine more code paths, run multiple attempts, and feed candidate findings into a deduplicating orchestration layer. That shifts the useful metric from one-call accuracy to unique validated vulnerabilities per compute dollar, elapsed hour, and reviewer hour.
It also shifts the safety boundary. Google says one internal evaluation ran without safety guardrails, and its CodeMender tooling can navigate repositories, change files, and execute commands. For that deployment shape, access screening and refusal behavior are not enough. Authorization, target scope, isolated execution, secret and network controls, tamper-evident traces, patch provenance, regression tests, human approval, and rollback are part of the safety case. RohitAI's analysis of long-horizon agent failures explains why the full session—not one answer—becomes the security boundary.
The acceptance test I would run before migrating
Treat these releases as new execution tiers, not string replacements.
Start with routing rather than replacement. Keep old Lite routes where they still win on accepted-task cost. Move high-volume, failure-sensitive work to 3.5 Flash-Lite only after testing the deployed thinking level. Use 3.6 Flash where better planning, multimodal reasoning, or Google's reported reduction in loops pays for the larger rate. Put Antigravity behind its own eval because it is a different system.
The RohitAI read: Google is moving control above the sampler
Three changes in this release will outlast the model names.
First, thinking level is becoming part of the effective SKU. “Gemini 3.5 Flash-Lite” is not one performance point. Minimal and high thinking can produce different latency, cost, task completion, tool behavior, and benchmark quality. Procurement tables and observability systems that store only the model name will compare unlike products.
Second, managed agents need execution manifests. Container images have digests and applications have lockfiles because mutable defaults destroy reproducibility. Agent runs need the equivalent: outer agent ID, resolved checkpoint, thinking level, tools, permissions, compaction policy, client version, and relevant server configuration. Antigravity's default change is an early, clean example of why.
Third, configuration linting becomes a reliability control. Ignored sampling fields are more dangerous than an immediate error because they let teams believe an experiment is active. The eventual HTTP 400 is not the first migration event; silent loss of control is. Catching inactive configuration in CI is part of operating the model safely.
My expectation is that future Gemini releases will deepen this approach. Thinking levels, structured outputs, tool schemas, thought signatures, and Interactions state will become the stable control contract. Model IDs will matter, but managed routing will change more often than outer agent identifiers, forcing resolved-model observability into normal production practice.
Flash Cyber shows how Google may apply the same approach in higher-risk domains: offer specialists through vetted, instrumented workflows before exposing raw endpoints. Their value will be judged at campaign level—validated results per dollar and reviewer-hour—because the scaffold can contribute as much as the checkpoint.
Final take
Builders should take the efficiency win and refuse the abstraction shortcut. Benchmark complete workflows, record the resolved execution stack, keep state outside the transcript, and route by accepted outcome rather than model branding.
Fewer tokens can lower the bill. Fewer knobs can simplify the interface. Neither reduces the need to know what actually ran.
FAQ
Is Gemini 3.6 Flash generally available?
Yes. Google lists gemini-3.6-flash as a stable, production-ready Gemini API model as of July 21, 2026. It supports multimodal input, text output, thinking, structured outputs, function calling, grounding, caching, code execution, File Search, URL context, and Computer Use in preview. It does not support the Live API or native audio and image generation.
Is Gemini 3.5 Flash-Lite cheaper than 3.1 Flash-Lite?
No, not per standard text, image, or video token. The 3.5 model costs $0.30 per million input tokens and $2.50 per million output tokens, versus $0.25 and $1.50 for 3.1 Flash-Lite. Its economic case depends on higher throughput, better completion, or fewer retries—not a lower token floor.
Does Gemini 3.5 Flash-Lite support Computer Use?
Google's documentation conflicts at launch. The latest-model guide says Computer Use is supported, while the dedicated Flash-Lite model page says it is not. Test the actual endpoint and avoid making it a hard production dependency until Google reconciles the pages.
Is Gemini 3.5 Flash Cyber available through the Gemini API?
No public model ID or generally available API route has been announced. Google says the model will enter a limited-access CodeMender pilot for governments and trusted partners, with possible expansion later.
What breaks when migrating to the new Flash models?
Remove temperature, top_p, and top_k because direct model calls ignore them and future generations will reject them; Antigravity already returns HTTP 400 for these fields. Remove model-turn prefills, which now return HTTP 400. Replace thinking_budget with thinking_level, remove candidate_count, update function-response fields, and test stateful flows against the Interactions API.