Gemini 3.6 Flash shifts the economics of Google's Flash tier

Google's Gemini API documentation, updated July 21, lists `gemini-3.6-flash` as a stable model with a 1,048,576-token input limit and a 65,536-token output limit. Google positions it for code generation, agentic execution, and spatial reasoning. The documented input set is broad: text, image, video, audio, and PDF are accepted, while the output is text. That combination makes the model relevant to systems that need to keep mixed source material and a long working context in one request rather than splitting preparation into a separate extraction model.

The operating envelope is more specific than the broad positioning. Google's model page lists support for caching, code execution, file search, function calling, Google Maps grounding, search grounding, structured outputs, thinking, and URL context. It also lists Batch, Flex, and Priority consumption options. That is a useful package for tool-using applications, but it is not an unrestricted multimodal endpoint: image generation, audio generation, and the Live API are marked unsupported. Computer use is listed as supported only in Preview, so teams should treat it as an integration surface requiring its own validation rather than a settled production guarantee.

The clearest comparison with Gemini 3.5 Flash is in published output pricing. Google lists the standard paid rate for Gemini 3.6 Flash at $1.50 per million input tokens and $7.50 per million output tokens, versus $1.50 input and $9.00 output for Gemini 3.5 Flash. The output rate is therefore about 16.7% lower, while the input rate is unchanged. That does not mean every workload becomes 16.7% cheaper: the result depends on the input-output mix, cached-context use, grounding calls, and whether a deployment uses Standard, Batch, Flex, or Priority service.

For technical users, the practical question is whether the new model can replace 3.5 Flash in the parts of an agent where generated text dominates cost and tool support matters. The documentation supports that as a reasonable evaluation target, especially for long-context and structured-output flows, but it does not remove the need for workload testing. Search and Maps grounding have separate published allowances and overage charges, and Preview computer use should be measured for reliability, latency, and safety in the intended environment. The source material establishes the documented capability and price surface; it does not independently prove quality or cost savings for a particular application.