3.5 Flash Costs 6x, and Agent Models Have a New Bill

AI 요약

• What happened: Google introduced gemini-3.5-flash at I/O 2026 and positioned it as a Flash model for agents and coding.
  • The official announcement highlights Terminal-Bench 2.1 at 76.2%, MCP Atlas at 83.6%, and GDPval-AA at 1656 Elo.
• Cost signal: official standard pricing is $1.50 per million input tokens and $9.00 per million output tokens.
  • That is 3x Gemini 3 Flash and 6x Gemini 3.1 Flash-Lite, which weakens the old shortcut that Flash means cheap.
• Builder impact: teams now need to price the retry, verification, harness, and search cost of an agent loop, not only the model's token rate.

Google announced the Gemini 3.5 model series at I/O 2026 on May 19, 2026. The first model in the line is gemini-3.5-flash. From the name alone, it looks like a familiar update to the Flash tier. But the announcement reads differently. Google describes 3.5 Flash as "frontier intelligence with action" and places it around complex long-running agent tasks, coding, tool use, and multistep workflows.

That shift in wording matters. For the last few years, the Flash label generally meant a model tier that was faster, cheaper, and easier to put behind high-volume requests. Developers could route difficult judgments to Pro or Opus-class models, then use Flash or mini models for classification, summarization, transformation, and cost-sensitive background work. Google is now redefining Flash as a model that can make agents finish real work. Its scorecard leads with agent and work benchmarks such as Terminal-Bench, MCP Atlas, and GDPval-AA rather than general chat metrics.

The problem is the price sheet. On Google's official Gemini API pricing page, gemini-3.5-flash standard pricing is $1.50 per million input tokens and $9.00 per million output tokens. On the same table, gemini-3-flash-preview is $0.50 input and $3.00 output. gemini-3.1-flash-lite is $0.25 input and $1.50 output. The exact multiplier depends on the baseline, but the reason developers reacted to "Flash got expensive" is straightforward. 3.5 Flash is 3x Gemini 3 Flash and 6x Gemini 3.1 Flash-Lite at standard token rates.

The core story is not simply that Google raised a price. The more interesting question is why Google kept the Flash name while changing both the price and the job the model is supposed to do. The answer is that agent cost is moving from the price of one token to the price of one execution loop.

Why Flash became an agent model

Google's official post calls 3.5 Flash its strongest agentic and coding model. The published numbers point in that direction: Terminal-Bench 2.1 at 76.2%, GDPval-AA at 1656 Elo, MCP Atlas at 83.6%, and CharXiv Reasoning at 84.2%. Google also says the model is 4x faster than other frontier models by output tokens per second. The examples in the announcement are closer to agent runs than ordinary chatbot sessions: migrating a legacy codebase to Next.js, two agents summarizing the AlphaZero paper and building a game, auto-classifying assets, and generating multiple UX directions in under 60 seconds.

Before taking those examples at face value, it helps to separate two things. A smarter model is not the same as a stronger harness. On the same day, Google's developer highlights packaged Antigravity 2.0, Antigravity CLI, Antigravity SDK, Gemini API Managed Agents, and AI Studio's Android flow into one developer story. 3.5 Flash is the model engine inside that product family. So Google's claim is less "one model became better" and more "a bundle of model, harness, sandbox, tool calls, and developer surface can increase throughput for long tasks."

That perspective also explains why the Flash name remains useful. In agent work, iteration speed matters almost as much as the quality of a single response. A model that plans, acts, checks failure, and retries quickly can have a better total cost than a model that tries to produce the perfect answer in one turn. Google's message that 3.5 Flash is faster than other frontier models aims exactly at that point. In agent execution, speed is not only a user experience feature. It is part of the unit cost of verification.

But that claim immediately leads back to cost. A fast agent model should make retries cheaper. If the token rate rises, teams need to recalculate whether "run it twice and add another verification pass" is actually cheaper. Coding agents, in particular, produce a lot of output tokens. Plans, file-reading summaries, patches, test-log interpretation, corrections, and final reports all turn into generated tokens. With 3.5 Flash output priced at $9.00 per million tokens, this is not a model to drop casually into every summarization or transformation step.

The 3x and 6x numbers need a clear baseline

The line that spread fastest in developer discussion is that 3.5 Flash is 6x more expensive. That can be true, but it is also too simple unless the baseline is named. Against Google's official pricing table, gemini-3.5-flash standard pricing is $1.50 input and $9.00 output per million tokens. gemini-3-flash-preview is $0.50 input and $3.00 output. Comparing those two gives exactly 3x.

Against gemini-3.1-flash-lite, the comparison changes. Flash-Lite standard pricing is $0.25 input and $1.50 output per million tokens. Compared with that tier, 3.5 Flash is 6x on both input and output. Flash-Lite is a separate tier optimized for high-volume agentic tasks, translation, and simple data processing, so a direct capability comparison would be misleading. For developers, however, it is a real routing candidate. Teams have to decide whether every step in an agent run deserves 3.5 Flash, or whether classification and transformation should stay on Flash-Lite while only planning, patching, or difficult repair steps move up.

The table shows more than a price increase. It shows Google's model tiers becoming more specialized. Flash-Lite still defines the low-cost floor for high-volume work. 3 Flash Preview keeps more of the older Flash feel. 3.5 Flash carries the Flash name but behaves like a high-performance work model for agent execution. The name is familiar, but the budget role has changed.

That makes routing more complicated. The old rule of thumb was roughly "use Pro for hard work and Flash for easy work." That rule is no longer enough. The better question is which phase of a long-running task you are in. Planning, parallel subagent decomposition, large diff generation, and test failure interpretation may be good 3.5 Flash candidates. File-list cleanup, log compression, simple English or Korean transformations, and duplicate removal may be fine on Flash-Lite or another cheaper model. Cost optimization is becoming less about choosing one model and more about decomposing an agent run into priced stages.

Google's counterargument is cost per completed task

Google says in the official announcement that 3.5 Flash can handle long-running agentic work at less than half the cost of other frontier models. If you only look at token prices, that sentence can feel strange. How can a more expensive Flash be cheaper? The answer is the comparison set and the accounting unit.

Google is not comparing 3.5 Flash with low-cost Flash-Lite. It is comparing the model with other frontier models. The accounting unit is also not price per token. It is the total cost of completing a task. A model that is cheap for one attempt can still be expensive if it fails more often, requires prompt repair, resends large context, or leaves a human to inspect test failures. Conversely, if 3.5 Flash uses pricier tokens but produces a correct patch and verification result in fewer loops, cost per completed task can fall.

That logic is reasonable, but it is not automatically true. Agent cost is shaped by at least three variables. The first is success rate. Benchmark scores have to survive contact with a real repository, real permissions, real CI, and real team rules. The second is token shape. Agents often spend heavily on output, intermediate reasoning, and log interpretation, not just input. The third is harness efficiency. Even with the same model, poor file selection, caching, tool-call policy, and failure recovery can waste a large amount of context.

That is why teams should read Google's "less than half the cost" line as a hypothesis to test rather than a price guarantee. Before putting it into a product, use existing agent-run logs as a baseline. Sample 30 similar tasks and run them through gemini-3.5-flash, a cheaper Flash-Lite combination, and the current GPT or Claude setup. Track token cost, success rate, human interventions, test pass rate, and how often review sends the work back. In coding-agent work, a large diff that looks successful can be the most expensive kind of failure.

Antigravity and Managed Agents change what a price sheet means

The interesting part of the announcement is that 3.5 Flash did not arrive as only a standalone model. The Google I/O 2026 developer highlights tied it to Antigravity 2.0, Antigravity CLI, Antigravity SDK, Gemini API Managed Agents, and AI Studio Android support. Google describes Antigravity 2.0 as a central surface for coordinating multiple agents in parallel, the CLI as a terminal-first execution surface, the SDK as a way to use the same harness in your own infrastructure, and Managed Agents as a layer that performs reasoning, tool use, and code execution in an isolated Linux environment through a single API call.

That structure can make model cost either more opaque or more manageable. It becomes more opaque because an agent run is not a single completion. The bill depends on how many plans were made internally, which files were read, how many subagents ran, and how much test output entered the context. It can also become more manageable because the harness standardizes the execution unit. A common agent harness may provide more consistent traces and budget boundaries than a team hand-assembling workers, sandboxes, traces, and retry policies.

The practical question is not just whether 3.5 Flash is good. It is where a team can control the budget. With direct model API calls, request tokens and rate limits are visible. With layers such as Managed Agents or Antigravity, the execution unit gets larger. Developers will want to know how many model calls, tool calls, search requests, and cache reads sit behind a single visible task. Google's pricing page also lists Grounding with Google Search, which after a free allowance is priced per 1,000 search queries. Once an agent uses search or Maps grounding, the bill includes more than model tokens.

That is why this announcement belongs in AI infrastructure, not only model news. In the agent era, cost does not end at one line on a model price table. Model, harness, sandbox, search, file context, cache, retry policy, and verification steps all add up. Google is trying to integrate that bundle inside its own ecosystem. OpenAI is moving in a similar direction with Agents SDK and Codex. Anthropic is doing the same through Claude Code and agent tooling. The competition is shifting from "who released the smartest model" to "who can make execution cost more predictable."

The community tension is real

Early Reddit reactions split into two broad camps. The positive read is that 3.5 Flash looks more like an agent update than a chat update. Terminal-Bench, MCP Atlas, and OSWorld-style scores are front and center, and if the model is fast enough to make extra retries or verification passes feel cheap, the workflow itself changes. That view lines up with Google's announcement logic. The point is not whether the model is slightly cheaper or pricier than another chat model. It is whether the agent loop can be redesigned.

The skeptical read focuses on two issues. First, Google's benchmark claims do not automatically guarantee product quality. In long-running agent work, failure often shows up as stuck tools, polluted context, an unreviewably large diff, or tests that pass while maintainability gets worse. Second, there is a mismatch between the Flash name and the new price intuition. Some developers see 3.5 Flash as no longer suited to casual high-volume Flash workloads and more like a priced work model for agent execution.

Both reactions have a point. Google's future is clear: model output is giving way to harnesses that act, verify, and act again. In that future, fast models matter. But if the fast model is also more expensive, developers have to split work more strictly. Rather than letting the agent use one model for everything, teams need to decide which steps require an expensive model, which steps can use a cheap model, which steps should be deterministic code, and which steps should remain human review.

What development teams should check now

The first thing to inspect is the token distribution of existing agent runs. Many teams only track total tokens. That is no longer enough. Input, output, cache, search, and tool-call logs should be separated. With a model such as 3.5 Flash, whose output price is high, a model that writes long explanations may be expensive even when it feels transparent. An agent that produces a long plan and reflection at every step can look auditable while quietly raising the bill. A harness that emits short structured events and only the necessary diff can lower cost on the same model.

The second step is putting success rate next to the price sheet. A 6x token rate can be rational if success rate doubles and human review time falls sharply. If the success-rate gap is small, a cheaper model combination may win. The important metric is not "the benchmark is high." It is "this finishes our task queue at a lower total cost." Bug fixes, refactors, documentation, data cleanup, and customer research should be sampled separately because the token mix and failure modes are different.

Third, model routing needs to move into the agent planner. A product where the user's selected model runs every step is simple, but it is expensive. A better pattern is to use 3.5 Flash for planning and risky code edits, Flash-Lite for log compression and file-candidate filtering, and a more conservative reviewer model for final checks. If you are building an agent product, the internal policy engine may become more important than the model picker in the UI.

The last issue is harness dependency. Google Antigravity and Managed Agents clearly reduce infrastructure that developers otherwise have to build themselves: isolation, state, subagents, tool execution, AI Studio, Android, and Firebase flows. That is attractive. But cost, logs, retention, permissions, and data boundaries move into Google's execution model. Enterprise teams should not treat "easier to run" and "easy to control" as the same statement.

Conclusion: Flash means something different now

Gemini 3.5 Flash carries an unusual label inside Google's model lineup. It is Flash, but it is not merely cheap. It is fast, but its price makes it hard to use casually as the default for high-volume simple work. Google is instead presenting it as the default engine for agent execution, backing that claim with Terminal-Bench, MCP Atlas, GDPval-AA, Antigravity, and Managed Agents.

So the real news is not that Gemini received another model update. It is that Google is pulling the Flash tier into the center of the agent economy. The question left for developers is simple: is 3.5 Flash an expensive model, or is it a cheaper execution loop because it reduces failure and retry? The answer will not come from Google's announcement. It will come from each team's own task logs.

For now, the conservative default is to be selective. Do not make 3.5 Flash the default for every request just because the name says Flash. Put it into long-running coding, tool-use, and multistep tasks, compare it with Flash-Lite and cheaper model routes, and judge the result by cost per completed task rather than token price alone. That is how the new bill for agent models should be read.

Sources

• Google official announcement: Gemini 3.5
• Google I/O 2026 developer highlights
• Gemini API official pricing
• Reddit discussion: Gemini 3.5 Flash feels more like an agent update than a chat update
• Reddit discussion: Gemini 3.5 model series announcement
• Reddit discussion: Google just dropped Gemini 3.5 Flash