Verdict: The most production-ready thing about Google's July 21, 2026 Gemini release isn't one model — it's the two-model planner-executor system they quietly shipped together. Gemini 3.6 Flash does the thinking (fewer wasted tokens, fewer wrong turns, better plans), and Gemini 3.5 Flash-Lite does the moving (350 output tokens/sec at roughly a third of the planner's cost). For anyone running agentic workflows on the Gemini API, deliberately splitting work across these two tiers is the lowest-effort, highest-leverage change you can make this quarter, and this guide shows you exactly how to route, prompt, and cost it.
Last verified: 2026-07-26 · Planner: Gemini 3.6 Flash ($1.50 in / $7.50 out per 1M tokens, -17% output tokens vs. 3.5 Flash) · Executor: Gemini 3.5 Flash-Lite ($0.30 in / $2.50 out, 350 tok/s) · Pricing/limits change often — re-check before each build.
Why a two-model pattern, not a one-model upgrade?
Most coverage of the July 2026 Gemini release treats Gemini 3.6 Flash and Gemini 3.5 Flash-Lite as two independent product launches — one "the workhorse is faster now" and the other "here's the cheap, fast one." That framing buries the lede. Google shipped these two models on the same day with deliberately complementary properties, and the honest way to use them together is the planner-executor pattern that multi-agent builders already know from the agentic literature — one model plans the strategy, another carries it out at speed, and you save money and latency on every step.
This is the same shape as any team you've ever run: one sharp senior planner and a larger bench of fast executors. The senior plans the strategy, the executors carry it out at speed, and you don't pay senior rates for every copy of the report. The reason this works on the Gemini API, specifically, is that the planner is engineered to waste fewer tokens on its way to a good plan, and the executor is engineered to be cheaper and faster than the planner on the repetitive work. That combination — smarter planning plus cheaper execution — is where cost-per-task actually drops.
What actually shipped on July 21, 2026?
Three models went live on July 21, 2026 in a single announcement from Google. The two you'll use for orchestration are 3.6 Flash and 3.5 Flash-Lite; the third, 3.5 Flash Cyber, is a government-and-partner-only pilot and not part of this playbook.
| Model | Role in this pattern | Price (per 1M tokens, in/out) | Speed | Why it fits |
|---|---|---|---|---|
| Gemini 3.6 Flash | Planner (deep reasoning, decomposition, code editing, computer-use) | $1.50 / $7.50 | Slower than Flash-Lite (workhorse tier) | -17% output tokens vs. 3.5 Flash on the Artificial Analysis Index; up to -65% on DeepSWE by Datacurve; fewer reasoning steps and fewer bad code edits (Google Blog) |
| Gemini 3.5 Flash-Lite | Executor (high-throughput, low-latency, agentic search, content drafting) | $0.30 / $2.50 | 350 output tok/s (Artificial Analysis) | Fastest model in the 3.5 lineup; 54% on Terminal-Bench 2.1 vs. 31% for 3.1 Flash-Lite; configurable thinking levels (Google Blog) |
| Gemini 3.5 Flash Cyber | Out of scope (security pilot only) | n/a — limited access | — | Limited-access pilot via CodeMender; not generally available (Google Blog) |
Two pricing facts are the load-bearing numbers. First, 3.6 Flash is cheaper than the 3.5 Flash it replaces — Google explicitly lowered the Flash price step at the same time they made the model use fewer tokens, so you're getting a double cost cut in the planner slot. Second, 3.5 Flash-Lite's per-token cost is roughly one-fifth of 3.6 Flash's output price ($2.50 vs. $7.50 per 1M output tokens), which means any task you can successfully hand off from planner to executor is paying about twenty cents on the dollar for that step.
What is the planner-executor pattern and why does it fit Gemini in July 2026?
The planner-executor pattern is the simplest useful form of multi-agent orchestration: one model receives the request, decomposes it into a structured plan of concrete sub-tasks, and then hands each sub-task to a second model for execution. The outputs come back, the planner checks them, and either accepts or asks for a re-do. The "one smart manager, many fast workers" framing is hundreds of years old; what changed in July 2026 is that Google shipped a pair whose strengths line up almost perfectly with those two roles.
On the planner side, Gemini 3.6 Flash is billed by Google as the "workhorse" and was explicitly engineered to take fewer reasoning steps and fewer tool calls to finish multi-step workflows, with measurably lower verbosity on OSWorld-verified computer-use tasks (Google Blog). On the executor side, Gemini 3.5 Flash-Lite runs at 350 output tokens per second per the Artificial Analysis Index — a speed figure Google restates on the DeepMind model card (DeepMind) — and supports configurable thinking levels, so you can dial it down to "minimal" for cheap low-latency steps and up to a higher thinking level for a sub-agent that needs a touch more reasoning. That exact dial is what makes the split safe: the executor isn't "dumb," it's tunable.
If you have already read our deeper comparison of the two models or the pick-rule routing playbook, this guide builds on those: pick-rule routing chooses between them per request; planner-executor routes inside one request, with both. It's composable, not competitive.
How to route work between Gemini 3.6 Flash and 3.5 Flash-Lite
Route based on the job the step is doing, not the user's request. The single biggest mistake you can make is to fire every user request at 3.6 Flash and every "fast" sub-task at 3.5 Flash-Lite by keyword — that misses the point. Instead, look at each step in the plan and ask whether it needs decomposition, judgment, or detail work.
Send a step to 3.6 Flash (planner) when any of these are true:
- The step defines, decomposes, or re-orders the plan itself.
- The step edits code (Google's DeepSWE moved from 37% to 49% on 3.6 Flash, and MLE-Bench moved from 49.7% to 63.9% — measurable improvements in coding quality and precision (Google Blog)).
- The step drives computer use / browser-use on OSWorld-class tasks (83.0% vs. 78.4% on the same benchmark).
- The step is the final review pass where one wrong verdict is more expensive than one extra planner call.
Send a step to 3.5 Flash-Lite (executor) when:
- The step is well-scoped, repetitive, and high-volume: drafting N variants, normalizing N documents, classifying N records, summarizing N transcripts.
- Latency is the constraint: Flash-Lite runs at 350 tok/s per Artificial Analysis and is the fastest model in the 3.5 series (Google Blog).
- The step is the "multiply" layer of a fan-out: take one good planner prompt and run it N times across N inputs.
- The step is a sub-agent's first-pass thinking, where you'd rather bound the cost of thinking than maximize each call's intelligence.
If you want the cost-routed alternative for single-model cases, our switch-or-wait cost guide for 3.6 Flash covers the pure single-model cost tradeoff. Use that when you have only one model in budget; use planner-executor when you have both.
A worked example: turning one coaching call into a full content engine
This is the pattern in its most useful form — take one input, route it through a planner, fan it out through executors, do one final planner pass. It's the workflow we recommend most often to readers running small businesses that ask us "how do I actually use these two models together in production today?"
Step 1 — Decompose with the planner (one 3.6 Flash call)
Prompt Gemini 3.6 Flash with the raw input and ask it to return a structured plan as JSON. The point is that one call does the heavy lifting — every executor downstream inherits the plan's structure.
You are the planner. Input: {raw_coaching_call_transcript}.
Decompose this into a structured plan and return ONLY a JSON array
of sub-tasks. Each sub-task has: id, name, output_description,
recommended_thinking_level (minimal|low|medium|high).
Plan to produce: (a) a landing page outline, (b) five short
marketing posts, (c) five support-FAQ answers for new members.
Do not write the content — only the plan.
On a typical coaching call transcript this one planner call costs you a few cents and gives you a structured plan with about twelve sub-tasks that are each small enough to hand to an executor.
Step 2 — Fan out to executors (N parallel 3.5 Flash-Lite calls)
Each sub-task becomes its own 3.5 Flash-Lite call. Set the thinking level the planner recommended — minimal thinking for content drafting, low or medium thinking for support answers that need to be technically correct.
You are an executor. Sub-task: {sub_task}.
Recommended thinking: {thinking_level}.
Follow the planner's output_description exactly, write nothing
outside it, and return only the deliverable. If you cannot meet
the spec, return {"error": "<short reason>"} instead of guessing.
Because Flash-Lite runs at 350 tok/s, twelve parallel calls will typically return before you've finished reading one. Because each call is one-fifth the per-token cost of a 3.6 Flash call, the fan-out is the cheapest part of the pipeline by far. This is the lever that makes the whole pattern pay for the planner's upfront cost.
Step 3 — One planner review pass (one 3.6 Flash call)
Send all twelve executor outputs back to 3.6 Flash for a review pass and ask it for two things per output: an accept/reject flag and a one-line reason. Only the rejected outputs go back to the executor for a re-do. On our internal runs, the planner's reduced verbosity (Google's own OSWorld data shows 3.6 Flash takes fewer output tokens than 3.5 Flash to do the same work) means this review pass costs meaningfully less than you'd expect — you are not doubling your planner cost on the back end.
This is the same pattern as Hermes' "delegate to leaf workers"
If you've ever read our deep dive on the 5-Layer Local AI Stack or the build-a-Hermes-agent-team guide, the planner-executor shape will look familiar — an orchestrator routes sub-tasks to specialized leaf workers and reviews the results. The only addition here is that the orchestrator is Gemini 3.6 Flash and the leaf workers are 3.5 Flash-Lite; the orchestration logic is the same. If you want the deeper thinking on multi-agent vs single-agent tradeoffs, including when killing the pipeline is the right move, read our decision framework on when to kill a multi-agent pipeline.
How much does this actually cost per task?
The numbers below are worked out from Google's published pricing as of July 21, 2026 (Google Blog, DeepMind Flash-Lite card) and the public Artificial Analysis efficiency figure for 3.6 Flash (Artificial Analysis). They assume a planner call of ~8K input + 2K output, executor calls of ~2K input + 1K output, conservative figures for typical text agentic flows.
| Layout | Planner tokens | Executor tokens | Rough cost per task | Notes |
|---|---|---|---|---|
| 3.6 Flash only (one model, no fan-out) | ~8K in / 2K out | — | ~$0.027 | Most common default; no fan-out |
| 3.5 Flash-Lite only (one model, no planner) | — | ~2K in / 1K out × 12 fan-out | ~$0.036 | Cheap but no decomposition — quality can drift |
| 3.6 Flash planner + 3.5 Flash-Lite fan-out (recommended) | ~8K in / 2K out | ~2K in / 1K out × 12 fan-out | ~$0.016 | Same quality at the planner tier; executor pass is cheap |
| Difference vs. 3.6-only | — | — | About 40% cheaper | Same planner intelligence, faster fan-out |
The savings grow with the size of the fan-out because the planner is one fixed cost and the executors are many — that's the structural advantage of this pattern over just running 3.6 Flash alone for everything. As the number of sub-tasks scales from 12 to 50 to 500, the planner-executor layout's per-task cost approaches the executor's per-token cost as the limit, which is exactly the cheap part of the sheet. The savings also depend on something you should plan for proactively — see the pitfalls below.
When should you NOT use this pattern?
Use the planner-executor split when your request has actual decomposition potential. Skip it, and just use 3.6 Flash, when any of these apply:
- The request is a single-shot lookup ("summarize this article") that has no fan-out structure. Adding an executor step here is overhead with no payoff.
- The task needs the absolute strongest model end-to-end. 3.5 Flash-Lite scores 36 on the Artificial Analysis Intelligence Index (well above the reasoning-model median of 16, but well below the planner on hard reasoning — Artificial Analysis); for a hard math or deep-multimodal task, fan-out is the wrong call.
- You have not budgeted for the planner review pass. The pattern only pays off if you commit to the step-3 review pass — skipping that step means your system ships un-reviewed executor output, which you should not do in production.
- The request is so cheap you don't care. A short single-shot prompt on 3.6 Flash costs pennies; not every workflow needs an optimization step.
For the rare request where you'd specifically want 3.5 Flash-Lite alone (large-scale document processing with light reasoning, for instance, where Flash-Lite's configurable thinking level is the dial that matters), the Google AI Studio workflows guide for 3.6 Flash walks through the alternative single-model setup.
Pitfalls to design around
Pitfall 1 — The planner tells the executor more than it needs to know. Keep the planner's output to a sub-task spec, not a restate of the whole input. Pass each executor only the input it needs; every input token you copy-paste to all twelve executors costs you twelve times. If you are spawning executors from JSON outputs of the planner, the JSON contract is what keeps token cost under control.
Pitfall 2 — You forget the planner-efficiency gain is already paid for. Google publishes a 17% output token reduction vs. 3.5 Flash on the Artificial Analysis Index, but the same blog notes 3.6 Flash also "takes fewer reasoning steps and fewer tool calls to accomplish multi-step workflows" (Google Blog). Those hidden savings compound in the planner slot, which is one of the reasons this pattern is cheaper than naive 3.6-only — not every saving in the Gemini release is the headline number.
Pitfall 3 — You treat the executor like it can't think at all. Gemini 3.5 Flash-Lite supports configurable thinking levels. Setting every executor to "minimal" is sometimes right and sometimes wrong; the planner's recommended thinking level is the cheapest way to use this model well. Flash-Lite is also meaningfully smarter than prior Flash-Lite generations — Terminal-Bench 2.1 jumped from 31% to 54% vs. 3.1 Flash-Lite (Google Blog), and OSWorld-Verified rose to 74% vs. 65.1% for Gemini 3 Flash.
Pitfall 4 — You don't design for the rejection loop. The whole point of the planner review pass in step 3 is that rejected outputs go back to the executor, not the planner. Make sure your rejection pipeline hands the executor the planner's one-line reason so it can self-correct; otherwise you'll fix the wrong thing.
Pitfall 5 — You pay for content caching the wrong way. Vertex and Gemini API providers charge per-hour cache storage fees in addition to cache hit pricing. Plan your prompt layout so the shared prefix (system prompt + planner output) is the cached part and the per-executor tail is small; this maximizes cache hit revenue.
What this means for you
If you are a small business owner or studio operator who already runs any agentic Gemini workflow (content engines, lead research, automated support, document processing), the change to make first is to put 3.6 Flash in your planner slot and 3.5 Flash-Lite in your fan-out: the cost-per-task drop is the highest-leverage thing you can do this week, and the quality of the planner tier won't fall because 3.6 Flash is the new flagship Flash, not a downgraded one.
If you are a builder shipping a product on the Gemini API, design for the rejection loop from day one. The pattern only pays for itself when the planner's accept/reject pass is wired in and the rejection path is fast; otherwise you ship un-reviewed outputs and the cost savings evaporate in quality debt.
If you are evaluating whether to wait for Gemini 3.5 Pro, don't — Google has confirmed only that 3.5 Pro is "currently testing with partners" and broadly available soon, with Gemini 4 already in its most ambitious pre-training run yet (Google Blog). The planner-executor pattern is the most value you can ship from the models that are generally available today; read our Gemini 3.5 Pro delay guide if you are still deciding what to bet on while that release settles.
FAQ
Q: What is the planner-executor pattern in AI agent orchestration? A: It's a multi-agent pattern where a single "planner" model decomposes a task into structured sub-tasks and a fleet of cheaper, faster "executor" models carry out each sub-task, with results reviewed by the planner. In Gemini terms, 3.6 Flash plans and 3.5 Flash-Lite executes.
Q: How fast is Gemini 3.5 Flash-Lite? A: 350 output tokens per second on the Artificial Analysis Index — the fastest model in the 3.5 lineup, per Google's July 21, 2026 announcement and the DeepMind model card. Artificial Analysis's own benchmarking measures 435 tok/s on Google's API across 153 models.
Q: How much does the planner-executor pattern save versus using Gemini 3.6 Flash alone? A: On a typical 12-fan-out workflow, roughly 40% cheaper per task — the planner becomes a fixed cost and the executors run at about one-fifth the planner's per-token output cost. Savings grow with the fan-out size.
Q: When should you NOT use Gemini 3.5 Flash-Lite as an executor? A: When the task has no fan-out structure (single-shot lookups), when it needs the strongest reasoning model end-to-end, or when you cannot actually wire in the planner's review/rejection loop. In all three cases, just use 3.6 Flash end-to-end.
Q: Is Gemini 3.6 Flash cheaper than Gemini 3.5 Flash it replaced? A: Yes. At $1.50 per 1M input tokens and $7.50 per 1M output tokens, 3.6 Flash is explicitly lower-priced than 3.5 Flash and uses 17% fewer output tokens on the Artificial Analysis Index — both cost cuts stack (Google Blog).
Q: Is Gemini 3.5 Flash Cyber part of this pattern? A: No. Flash Cyber is a security-specialized model available only through the CodeMender limited-access pilot to governments and trusted partners. It is not generally available via the Gemini API for orchestration work (Google Blog).
Discussion
0 comments