Gemini 3.8 Flash thinking levels: low vs medium vs high (and why minimal is gone)

Gemini 3.8 Flash ships with three thinking levels: low, medium, and high. The setting controls how much internal reasoning the model does before it answers, and on this model it moves three numbers at once: latency, output tokens, and your bill. Google built 3.8 Flash to “work harder” on complex tasks by design, so the level you pick matters more than it did on 3.7 Flash. If you’re new to the model, the Gemini 3.8 Flash overview covers the launch. This guide is only about the dial.

Two details trip teams up in the first hour. The default level on 3.8 Flash is medium, not high (Gemini 3 Pro defaults to high, which is where the confusion comes from). And minimal, which configs written for Gemini 3.7 Flash still send, is no longer accepted: the request fails validation before a single token is generated. Google documents both on the What’s new in Gemini 3.8 Flash page.

Below: what each level does, what it costs per task, how to set it in both API shapes, a per-route strategy, and a repeatable test that shows the token and latency delta before you ship.

Thinking levels at a glance

The cost and time columns are Artificial Analysis averages from running their Intelligence Index at each level, at Google’s intro per-token prices. They’re independent numbers, not Google’s, and they measure a benchmark workload, not your prompts. Use them for ratios, then measure your own routes.

What each level does

Every 3.8 Flash response can include thinking tokens: reasoning the model generates before the visible answer. You pay for them as output tokens ($3.75 per million at the intro rate through 2026-12-31, $7.50 from 2027-01-01), and the API reports them separately as usageMetadata.thoughtsTokenCount. The thinking level tells the model how much of that reasoning to do.

• low keeps thinking short. First token arrives fastest and the output bill stays small. Google positions it for latency-sensitive work: simple instruction following, chat, and high-throughput endpoints.
• medium is the balance point and the default. Google calls it out as the setting for complex code and agentic tasks, which is most of what people run a Flash-class model for.
• high tells the model to reason as deeply as it can. Google reserves it for the hardest multi-step problems.

What makes this different on 3.8 Flash is the model’s new default behavior. On complex tasks it “executes extra reasoning steps, and calls tools iteratively” and “verifies its work along the way”. Google says plainly that it “can use more tokens on longer running and complex tasks, by design” and that “the model might use more tokens to maximize performance, especially at higher effort levels”. The thinking level is the throttle on that behavior. Lowering it is Google’s own first suggestion when token usage climbs; the second is staying on 3.7 Flash, which remains fully supported.

One constraint to internalize: thinking_level is an enum, not a budget. The integer thinking_budget from earlier models is gone on Gemini 3, so you can’t ask for “at most 2,000 thinking tokens”. You pick a level and then verify what it costs on your prompts, which is why the test at the end of this guide matters.

The default is medium, not high

Omit the field and 3.8 Flash runs at medium. That catches two groups.

Teams that prototyped on Gemini 3 Pro expect high by default and get medium-depth answers without noticing. Teams that stripped thinking_budget during a 3.7 Flash upgrade and didn’t replace it with a level end up on medium everywhere, including the chat routes that should be on low.

The fix for both is the same: set thinking_level explicitly on every request, per route, in config, not code. Defaults are Google’s to change; your cost profile shouldn’t move when they do.

Why minimal is gone and how to fix the error

minimal worked on Gemini 3.7 Flash. On 3.8 Flash it isn’t in the supported set, and the model page lists thinking as low, medium, and high only. Send it over REST and the request is rejected before the model runs with a 400 INVALID_ARGUMENT with the message “Thinking level MINIMAL is not supported for this model. Please retry with other thinking level.” (verified with a live call on September 3, 2026). SDKs wrap that in their own exception class, so match on the 400 status or the INVALID_ARGUMENT code, not the message string.

Before:

{
  "model": "gemini-3.8-flash",
  "input": "Classify this ticket as billing, bug, or feature.",
  "generation_config": { "thinking_level": "minimal" }
}

After:

{
  "model": "gemini-3.8-flash",
  "input": "Classify this ticket as billing, bug, or feature.",
  "generation_config": { "thinking_level": "low" }
}

Google’s migration guidance is a straight mapping: minimal becomes low. Two temptations to avoid while you’re in that config. Don’t reach for thinking_budget to get a smaller floor; it’s unsupported on Gemini 3 models. And don’t lower temperature to “calm the model down”; Google says to leave it at the default 1.0 on all Gemini 3 models because lowering it may cause looping or degraded output. The full checklist, including thought signatures and the call_id requirement on function responses, is in the 3.7 to 3.8 Flash migration guide.

Because the error fires at validation time, a scheduled test request at each level catches a config regressing to minimal for free.

What each level costs per task

Per-token pricing doesn’t change with the level. Google’s pricing page lists every 3.8 Flash call at $0.75 input and $3.75 output per million tokens at the intro rate, doubling to $1.50 and $7.50 on 2027-01-01. The spread between levels is purely token count, which is what Artificial Analysis measured.

Source: Artificial Analysis, Intelligence Index runs at intro pricing. Three ratios fall out of the table.

low runs at about 41% of high’s cost and about a third of its wall-clock time. That’s the biggest single lever you have on this model.

medium on 3.8 Flash costs about what high cost on 3.7 Flash ($0.41 vs $0.40). If you were happy with 3.7 Flash at high, 3.8 Flash at medium is the like-for-like budget line.

high on 3.8 Flash costs 45% more per task than high on 3.7 Flash, on identical per-token prices, because the model emits about 30% more output tokens (48k on average per index task). That’s the “works harder” design showing up on the invoice. Whether the extra tokens pay for themselves depends on the workload; the 3.8 Flash vs 3.7 Flash comparison walks through where the quality gains landed.

One caution on quality: AA’s Intelligence Index score of 59 for 3.8 Flash is a high run. They didn’t publish index scores at medium or low in text, so don’t assume the quality curve is linear with cost. Test your own evals at each level before you move a route down. For the worked example of 1,000 tasks a day at each level and the December 31 price cliff, see Gemini 3.8 Flash pricing.

Setting thinking_level in the Interactions API

The Interactions API is Google’s primary surface for Gemini 3.x. The level sits in generation_config as a snake_case string:

curl -X POST "https://generativelanguage.googleapis.com/v1beta/interactions" \
  -H "x-goog-api-key: $GEMINI_API_KEY" -H 'Content-Type: application/json' \
  -d '{"model":"gemini-3.8-flash","input":"Explain HTTP caching in 3 sentences.","generation_config":{"thinking_level":"low"}}'

In Python:

interaction = client.interactions.create(
    model="gemini-3.8-flash",
    input="Explain HTTP caching in 3 sentences.",
    generation_config={"thinking_level": "low"},
)
print(interaction.output_text)

It’s a request-level field, so set it on every call, including follow-up turns that pass previous_interaction_id. The response comes back as a list of execution steps (thoughts, tool calls) ending in model_output, and the SDK exposes the final text as output_text. For the full first-call walkthrough, including multi-turn state and streaming, see how to use the Gemini 3.8 Flash API.

Setting it in legacy generateContent

Most existing Gemini code still calls generateContent. Google calls it legacy but says it remains fully supported with no sunset date, so there’s no rush. The field is nested one level deeper and camelCased:

curl "https://generativelanguage.googleapis.com/v1beta/models/gemini-3.8-flash:generateContent" \
  -H "x-goog-api-key: $GEMINI_API_KEY" -H 'Content-Type: application/json' -X POST \
  -d '{"contents":[{"parts":[{"text":"Explain HTTP caching in 3 sentences."}]}],
       "generationConfig":{"thinkingConfig":{"thinkingLevel":"low","includeThoughts":true}}}'

In Python:

from google.genai import types

response = client.models.generate_content(
    model="gemini-3.8-flash",
    contents="Explain HTTP caching in 3 sentences.",
    config=types.GenerateContentConfig(
        thinking_config=types.ThinkingConfig(thinking_level="low")
    ),
)
print(response.usage_metadata.thoughts_token_count)

includeThoughts: true adds thought summaries to the response as parts flagged thought: true: useful while calibrating a level, noise once you’re done. The number you care about is usageMetadata.thoughtsTokenCount, the exact count billed as output and the field your tests should watch.

A per-route strategy

Treat the level as a routing decision, not a global setting. A workable split:

• Chat, autocomplete, and anything a person is waiting on: low. It’s where first-token latency lives.
• Classification, extraction, and transcript search: low, with your own eval run once to confirm accuracy holds. Google’s own video example puts transcript search at low.
• Coding agents and tool loops: medium, the default. Escalate a single planning step to high if its output gates every later step, then drop back. On 3.8 Flash, tool loops already run more turns by design, so high across a whole loop compounds fast.
• Document-heavy, long-horizon workflows: high, and put them through the Batch API at 50% off when they aren’t interactive.
• Video: Google’s docs give three examples. high for dense visual QA or videos over 60 minutes, medium for general video Q&A, low for searching a transcript.

If low on 3.8 Flash is still more model than a route needs, the Flash-Lite line exists for that job; our earlier Gemini 3.1 Flash-Lite guide covers the tradeoff, and Gemini 3.5 Flash-Lite is the current entry at $0.30 input and $2.50 output.

Keep the level in per-route config and keep gemini-3.7-flash behind a flag. If a route’s token count spikes after the upgrade, you can drop the level or the model without a deploy.

Test all three levels side by side in Apidog

Reading AA’s table tells you the ratios. Only your prompts tell you the numbers. Here’s a test scenario in Apidog that sends one golden prompt at every level and asserts on what came back. It works against either API shape; the legacy endpoint is shown because usageMetadata is a top-level field there.

1. Store the key as an environment variable. Create GEMINI_API_KEY in an Apidog environment and reference it as {{GEMINI_API_KEY}} in the x-goog-api-key header. Add a second variable, THINKING_LEVEL, so one saved request serves all three steps.
2. Save one request. POST to /v1beta/models/gemini-3.8-flash:generateContent with your golden prompt and "thinkingConfig": {"thinkingLevel": "{{THINKING_LEVEL}}"}.
3. Build a three-step test scenario. Import the same request three times and override THINKING_LEVEL to low, medium, and high in each step.
4. Assert on the fields that move. On every step: status is 200 and usageMetadata.thoughtsTokenCount exists. On the low step, assert thoughtsTokenCount and response time stay under the ceiling that route can tolerate (set the baseline after your first run). A post-processor script can stash each step’s count in a variable so the high step can assert it reasoned at least as much as low did. If that ordering ever flips, the model or the default changed under you.
5. Add a guard step. Send thinkingLevel: "minimal" and assert the response is not a 200. When you later swap model IDs, this step tells you whether the new model still rejects it.
6. Schedule it. Run the scenario daily so a config regression or a silent behavior change shows up as a red run, not a surprise invoice. The mechanics are in how to schedule API tests in Apidog.

For streamed responses, the same scenario applies with SSE rendering; how to test LLM APIs that stream over SSE covers the setup. Download Apidog to follow along; the free plan covers this whole scenario.

FAQ

Does the thinking level change the price per token?

No. Input is $0.75 and output is $3.75 per million tokens on 3.8 Flash at the intro rate regardless of level. The level changes how many output tokens the model generates as thinking, and those are billed at the output price. The pricing breakdown covers caching, batch, and the January 1 increase.

Can I set an exact thinking token budget instead?

Not on Gemini 3 models. thinking_budget was replaced by the thinking_level enum, and 3.8 Flash accepts only low, medium, and high. If you need a ceiling, enforce it in tests and alerting instead of in the request.

Which level does the Artificial Analysis score of 59 use?

high. AA ran the Intelligence Index at high for the headline score and published cost and time at low and medium as well, but not index scores at those levels. Treat lower levels as untested on that benchmark until you run your own evals.

Should I lower temperature to reduce thinking?

No. Google’s guidance for all Gemini 3 models is to keep temperature at its default of 1.0. Lowering it can cause looping or degraded output. Use thinking_level to control reasoning depth.

What if even low is too slow or too expensive?

Stay on Gemini 3.7 Flash, which Google says remains fully supported with no deprecation date, or move the route to a Flash-Lite model. The 3.8 vs 3.7 Flash comparison shows where the extra tokens buy measurable quality and where they don’t.

Pick the level per route, then measure it

Three levels, one enum, and a model that reasons more than its predecessor by default. Set thinking_level explicitly on every route, map any leftover minimal to low, and watch usageMetadata.thoughtsTokenCount where each level lands. AA’s per-task figures ($0.24, $0.41, $0.58) give you the shape of the curve; a three-step scenario in Apidog gives you your own numbers before the December 31 price change makes them twice as important.