Building With Gemini 3.6 Flash: Cheap, Fast AI

The most common mistake when shipping an agent pipeline to production is sending every step to the most expensive model. Now that Gemini 3.6 Flash has reached general availability, you have three genuinely distinct tiers to work with — and the right question isn't "which model is best," it's "which tier does this specific step actually deserve."

What Changed in Gemini 3.6 Flash

Gemini 3.6 Flash and Gemini 3.5 Flash-Lite are now generally available. By Google's own measurements, 3.6 Flash cuts agent token costs by up to 65% on long-horizon engineering tasks, driven by better token efficiency and stronger code and agentic planning capabilities. This is the production-ready version of the model we covered when it first launched in our piece on the Gemini 3.6 Flash, 3.5 Flash-Lite, and Cyber launch.

Flash-Lite serves a different purpose: it's built as a high-volume, low-latency "subagent" model — optimized for speed and cost, not deep reasoning.

Three Tiers, Three Different Jobs

The pricing gap between these models largely dictates which job you should hand to which one:

The gap between Flash-Lite and Pro is roughly 6–7x on input alone. In a pipeline making thousands of calls, that difference shows up as a real number on your bill by end of day — a theme we covered more generally in our piece on cutting LLM token costs.

A Model-Routing Pattern

What actually works in practice isn't picking one model — it's building routing by task type:

• Flash-Lite: the default for high-volume, repetitive subagent work. Categorizing a customer request, summarizing a short passage, running a simple validation check — all fit here.
• Flash: the default for mid-complexity reasoning and code tasks. Most agent steps can realistically stay at this tier — work that doesn't need "deep thinking" but does need a few chained steps.
• Escalate to Pro: when Flash returns a low-confidence answer, or the task explicitly requires multi-step planning. You typically wire this to either the model's own confidence signal or a simple retry counter.

A basic router might look like this:

def route_model(task_type, complexity_score):
    if task_type == "classification" or complexity_score < 3:
        return "gemini-3.5-flash-lite"
    elif complexity_score < 7:
        return "gemini-3.6-flash"
    else:
        return "gemini-3-pro"

# Example usage
model = route_model(task_type="code-generation", complexity_score=5)

You can hand-label complexity_score, or derive it from simple signals like task length or historical failure rate. The goal isn't a perfect classifier — it's calling the most expensive model only when the task genuinely needs it.

Wiring It Into the Gemini API

Nothing changes besides the model choice — you're hitting the same Gemini API endpoint and just swapping the model parameter. That makes it easy to shift between tiers without rewriting your pipeline; all the routing logic needs to do is decide the model name before the call goes out.

Measuring Whether It's Actually Saving You Money

Once routing is in place, the real work is verifying it's actually paying off. A simple approach: for each task type, log both the "what if we always used Pro" cost and the real, routed cost, then report the weekly delta. You'd expect total cost to drop as more tasks land on Flash-Lite — but if you don't track that ratio alongside accuracy loss, you might end up with a system that's cheap but wrong.

An Honest Caveat: Routing Adds Complexity

Worth saying plainly: a three-model routing system is always more complex than using a single model. For a small prototype or a low-volume internal tool, you probably don't need this — just use Flash and move on. Routing's real payoff shows up in production systems making thousands of calls a day, where a 60% cost reduction easily justifies the added engineering complexity.

If you're weighing Gemini against the other major models, our Gemini vs ChatGPT comparison is worth a look too — reading it alongside the cost-focused approach here gives a more complete picture.

A Concrete Scenario: A Support Ticket Pipeline

To make this concrete, picture an agent pipeline processing 10,000 customer support tickets a day. Each ticket first gets categorized (spam, refund request, technical issue), then a reply draft gets generated based on the category, and anything flagged as complex or sensitive gets escalated to a human.

Route everything through Pro, and just the categorization step costs roughly 10,000 calls × ~500 input tokens × $2.00/1M ≈ $10 a day — and that's before adding reply-draft generation on top, which compounds the bill quickly. Route the same pipeline with tiering instead: categorization drops to Flash-Lite (about $0.30/1M for the same job, nearly 7x cheaper), reply-draft generation goes to Flash since it's mid-complexity, and only the small slice flagged as "sensitive" (typically 5–10% of total volume) escalates to Pro. Categorization cost drops to nearly negligible, and Pro spend falls sharply too since far less volume reaches it — which is roughly where Google's claimed 65% cost reduction actually comes from.

The key point in this scenario is that high-volume, low-complexity steps like categorization make up most of the total cost — and those are exactly the steps Flash-Lite is best suited for.

Model-Routing Decision Table

Frequently Asked Questions

Why is it wrong to use Flash-Lite everywhere?

Because accuracy drops on tasks that require real reasoning. The cost advantage stops mattering the moment it's offset by wrong or inconsistent outputs — especially for anything shown directly to a user.

When is it actually worth setting up routing?

Once your daily call volume reaches the thousands, or a single model's bill becomes noticeable. On low-volume projects, the added complexity can cost more engineering time than it saves in dollars.

When should I go straight to Pro?

When the task clearly requires multi-step planning, long-context tracking, or high accuracy. Automatically catching low-confidence Flash responses and escalating them is more reliable than deciding by hand every time.

How often does pricing change?

Google has adjusted pricing across the Flash family more than once over the past year. Rather than hardcoding prices into your production system, it's worth periodically checking the current Gemini API pricing page.