Gemini 3.6 Flash Thinking Levels: What Each One Costs, Measured

• minimal cost 73.6% less than the medium default on our nine production-shaped tasks, and scored the same nine out of nine. If you never chose a level, this is the largest cost lever you have.
• Thinking tokens were 75% of the total bill at medium, counting input tokens. Answer length barely moved across all four levels, so almost every dollar of difference between levels is thinking.
• low does not spend a fixed budget. On all nine structured-extraction runs it emitted exactly zero thinking tokens, making it cost the same as minimal there, while still thinking on tool-calling and code tasks.
• Above low, more thinking did not buy more correct answers on our harder round. Scores went 2, 10, 10, 8 out of 15 across minimal, low, medium, high.
• The default is not wrong, it is just untargeted. medium is a reasonable middle setting for unknown work. Once you know the shape of your work, the level is worth setting deliberately.
• Every published benchmark for this model runs at high, while the API default is medium. Those are different bills and different latencies.

The short answer, by level

Here is what each level cost us for one pass through the same nine tasks, and where each one earned its money.

The number nobody publishes: answer tokens against thinking tokens

Every price comparison of this model that we could find on launch day treats output tokens as one number. That merges two quantities that behave nothing alike, and once you separate them, most of the confusion around this release resolves.

Here is one pass through our nine tasks, with the output side split into the tokens you can read and the tokens you cannot.

Read the answer-token column first. Across eight configurations, two models and four thinking levels, it stays between 977 and 1,162 tokens, and the highest figure in the column belongs to the cheapest configuration. The models produce answers of roughly the same length no matter how much they think first.

Now read the thinking column. It runs from zero to 8,288. That is the entire story of your bill.

Here is the same data as money, splitting each pass into what you paid for input, for the answer, and for the thinking, at Gemini 3.6 Flash's standard-tier rates of $1.50 per million input tokens and $7.50 per million output tokens.

At the default level, three quarters of what you pay is reasoning you never see, on tasks where the level made no difference to whether the answer was right. That is not a defect in the model. It is what happens when a general-purpose default meets a specific workload.

This also explains why "does the new model save tokens" gets contradictory answers in public. The claim is about output tokens, output tokens are mostly thinking tokens, and thinking token counts depend on the thinking level, which almost nobody states. A measurement without a stated level is not reproducible.

How we measured this

Two rounds, run on 2026-07-21, the day both models were released.

• Calls went through OpenRouter with the provider pinned to Google AI Studio, sent serially rather than concurrently. The gateway does not expose which region served the request, so we cannot state one.
• Costs are computed from Google's standard-tier list prices, not from the gateway's own billing. The gateway routes at a discounted tier, and mixing the two would make our figures incomparable with Google's published pricing.
• No sampling parameters were set. temperature, top_p and top_k are deprecated on Gemini 3.x and are accepted and then ignored, so setting them would have changed nothing while implying we had not read the documentation. If you still set them in production, the rest of this release's interface changes are covered in our Gemini 3.6 Flash release guide.
• Grading is rule-based, not human. Correctness is a supporting metric here, present to rule out the explanation that a cheap level looks cheap because it is quietly doing less work.
• Answer tokens and thinking tokens were recorded separately for every single call, which is what makes the tables above possible.

Why the published benchmarks do not answer this question

There is a documented reason nobody can look this up. The benchmark numbers in circulation are measured at levels that most production traffic does not run at, and the sources rarely say so.

• Artificial Analysis, currently the only independent source with a full breakdown of this model, measured at high thinking. The API default is medium.
• Google's own results table for Gemini 3.5 Flash-Lite was produced at high thinking, while that model's API default is minimal. Running the default configuration is not the experiment the table describes.
• In Google's comparison table, the DeepSWE row runs Gemini 3.5 Flash at medium and Gemini 3.6 Flash at high, so the two Gemini figures in that row are not a same-level comparison.
• Google's headline "up to 65% on DeepSWE" refers to a reduction in token usage, not to a score. The DeepSWE score is 49%.

None of that makes the published figures wrong. It makes them answers to a different question than "what will this cost me at the level I actually run".

Round one: the levels on ordinary work

Three results, in the order they matter.

low is adaptive, not a smaller fixed budget

This is the result we did not expect, and it is the most directly useful one on this page.

Round two: where quality actually breaks

Round one could not answer the quality question, because every configuration scored nine out of nine. Nine tasks were not hard enough to separate four levels. So we made them harder, and the answer that came back was not the one the levels imply.

So thinking level does not buy reasoning correctness, at least not in the range these tasks occupy. What it buys is something narrower.

Here is how the six configurations scored on those three tasks, five attempts each.

Cost per call excludes one anomalous request described in the next section; the totals with it included are given there.

The engineering consequence is more useful than a level recommendation. If your agent has to recover from unexpected states, build the retry and the verification into your application, and treat the thinking level as a cost setting rather than as the thing that makes recovery reliable.

Gemini 3.6 Flash low against Gemini 3.5 Flash-Lite

This comparison has no published data anywhere that we could find, and it is the one a cost-conscious team actually faces: for roughly the same money, do you run the stronger model with a little thinking, or the cheaper model thinking hard?

Which of those two pictures applies to you depends on your task mix, and that is the honest answer rather than a hedge. The two configurations are in the same performance band on both of our rounds. The price relationship between them is not stable across task sets.

Two more observations from the same data, both worth knowing before you default to Flash-Lite.

One anomaly we cannot explain

Which level for which task

This is the table to take away. Every row is supported by the two rounds described above, and the limits of that support are stated underneath.

Measuring this on your own traffic

Four steps, in the order that gets you an answer fastest.

1. Log thinking tokens separately today, before changing anything. Google's API returns the count in total_thought_tokens, alongside the level you set. If you only track total output tokens, you cannot tell a prompt regression from a level that decided to think harder this week.

   from google import genai
   from google.genai import types
   
   client = genai.Client()  # reads the API key from the environment
   
   response = client.models.generate_content(
       model="gemini-3.6-flash",
       contents=prompt,
       config=types.GenerateContentConfig(
           thinking_config=types.ThinkingConfig(thinking_level="minimal"),
       ),
   )
   
   log.info(
       "level=minimal thinking_tokens=%s",
       response.usage_metadata.total_thought_tokens,
   )

   Store the thinking count as its own field next to your existing output-token metric, and store the level you sent alongside it. Adding the two token counts together throws away the only signal that tells you which one moved.

2. Set the level explicitly, even if you set it to medium. An inherited default is a cost decision nobody made. It also means your bill can move when a default moves.
3. Replay one day of real traffic at minimal and at low, and compare outputs against your current ones rather than against a benchmark. On our tasks that comparison was worth between 61% and 74% of the bill, which is a larger effect than any model swap available in this tier.
4. Grade the tool-calling paths separately from everything else. That is the only place we found the level changing correctness, and averaging it together with extraction traffic will hide it.

Running that comparison across several models usually means a separate integration per vendor, and that integration cost is the most common reason teams skip the measurement entirely. Standardising on one OpenAI-compatible endpoint removes it, so the model string becomes the only thing that changes between runs.

import os
from openai import OpenAI

client = OpenAI(
    base_url="https://api.evolink.ai/v1",
    api_key=os.environ["EVOLINK_API_KEY"],
)

for model in ("gemini-3.6-flash", "gemini-3.5-flash-lite"):
    response = client.chat.completions.create(model=model, messages=messages)
    record(model, response.usage)

FAQ

Sources

• Gemini thinking documentation, Google, for thinking_level values, per-model defaults, the statement that response pricing sums output and thinking tokens, and the total_thought_tokens field
• Gemini API models documentation, Google
• Gemini API pricing, Google
• Introducing Gemini 3.6 Flash, 3.5 Flash-Lite, and 3.5 Flash Cyber, Google, 2026-07-21
• Gemini 3.6 Flash, Google DeepMind, for the documented model limitations
• Gemini 3.6 Flash and Gemini 3.5 Flash-Lite: Halving Time per Task, Artificial Analysis, 2026-07-21
• aibenchy, independent 22-question test run, 2026-07-21
• EvoLink first-party measurement, 2026-07-21: 406 calls across two rounds, with per-call records retained