جیمنی 3.5 فلیش لائٹ

A low-latency, cost-effective multimodal Gemini optimised for high-throughput, low-cost execution -- Google aims it squarely at subagents running one focused task inside a larger workflow, and at document parsing. It is the fastest model in the 3.5 series, at roughly 350 output tokens per second, and can be pinned to minimal or low thinking for cheap work or raised for harder tasks. Full multimodal input and a million-token context are retained.

Flash-Lite is the bottom rung of the current Gemini ladder, and Google is unusually specific about the shape of work it wants there: agentic search and document processing, high-volume production traffic, and the sub-agent role inside a larger system where one bigger model plans and many small ones execute. The post's own demonstration has 3.6 Flash acting as the master agent and 3.5 Flash-Lite generating twenty-five design concepts underneath it.

Against the previous Lite generation the lab reports a large step rather than a refinement: Terminal-Bench 2.1 at 54% against 31%, the eight-needle long context set at 72.2% against 60.1%, and real-world task execution on GDPval-AA v2 at 1140 Elo against 642. The comparison that matters more for a buyer is the one against a bigger, older model: Google reports 3.5 Flash-Lite ahead of 3 Flash on SWE-Bench Pro at 54.2% against 49.6% and on OSWorld-Verified at 74.0% against 65.1%, which makes it a faster and cheaper replacement rather than a downgrade.

The thinking control is the lever that makes it two models in one. Google's guidance is to pin it to the minimal or low levels for cheap, latency-bound, high-volume execution, and to raise the level when the same model is handed a multi-step sub-agent workload. Computer use is a built-in tool here as well, which is what lets it take agentic work at all rather than only classification and extraction.

What it is not is the model for the hardest request in a system. Google positions the Flash tier above it for demanding coding and knowledge work, and the Lite tier's whole argument is throughput and price per unit of work rather than the top of any table. Read the speed claim the same way: it is a decode rate measured on a sample of prompts, not a promise about any one long generation.