Gemini 3 Thinking Levels: Settings and Trade-offs

Gemini's thinking setting controls a reasoning allowance. It does not promise a fixed number of reasoning steps, an exact response time, or a correct answer. Choose it alongside the exact model version, the task, and a way to verify the result.

This guide covers Gemini 3 models. It is not a guide to whichever Gemini model is newest. Model support changes, and a setting exposed by Google's API may not be available in a third-party chat interface.

Check the exact model before choosing a level

Google's thinking documentation distinguishes the older Gemini 3 Pro preview from Gemini 3.1 Pro preview. In the documentation reviewed on September 18, 2026, the former lists low and high, while the latter also supports medium. Gemini 3 Flash preview lists minimal, low, medium, and high. These models default to high; medium is not a universal default.

Treat this as a version-specific reference. Before changing an integration, check the current documentation for the model identifier your request actually uses. A friendly label such as “Pro” is insufficient for reproducing a test. Record the identifier, API family, SDK version, and request date with the result.

Choose a candidate, then test the trade-off

Low is a candidate for bounded extraction or classification. Give the model an explicit input and a small output contract: for example, classify a support ticket using only the categories you supply. Check whether it follows exclusions, handles missing information, and refuses to invent a category. Do not assume low means reasoning is completely disabled.

Medium, where supported, is another candidate for tasks with several interacting constraints. Consider summarizing a document into a fixed set of fields while preserving dates and exceptions. Compare it with the model's default using the same source text. A shorter answer is not necessarily cheaper or better, and a confident answer is not evidence of accurate extraction.

High is worth testing when the task needs several checks, such as inspecting a patch against requirements or comparing inconsistent source passages. It may involve more waiting and reasoning tokens. The practical question is whether it reduces failures enough to justify the total cost, including your review time. High cannot repair a missing source or an ambiguous requirement.

Try Gemini 3 on MidassAI Chat

Keep API families and parameter names separate

Use the example for your chosen API and SDK in the official documentation. Interactions and generateContent represent conversation state differently. A field copied from one interface is not automatically a valid request to the other, and SDK field names can differ from their REST equivalents.

The following is a planning record, not a runnable API request:

{
  "task_id": "ticket-classification-01",
  "model_id": "record-the-exact-available-model",
  "api_family": "record-your-api-family",
  "candidate_level": "low",
  "success_rule": "allowed category plus evidence from the ticket"
}

Do not invent a /v1/models/gemini-3:generate endpoint or send this planning record as an API payload. Start from the current official request example, substitute your input, and verify that the server accepts the setting. Keep credentials in the local environment, outside saved prompts and test reports.

Avoid changing several controls at once

Google's Gemini 3 developer guide recommends retaining temperature 1.0 for these models and warns that lowering it can cause undesirable behavior. Consequently, “high reasoning plus temperature 0.2” is not a general recipe for reliable Gemini 3 output.

Start with documented defaults, vary the thinking level alone, and keep the prompt, tools, source text, and output limit unchanged. Do not combine thinking_level with thinking_budget in the same request. If your existing client adds a thinking budget automatically, inspect its configuration before introducing the new field.

Build a small evaluation set

Select ordinary tasks and difficult cases from the workflow you actually care about. For an extraction application, include a clear value, an absent value, conflicting values, and a document that contains instructions unrelated to the task. Write the expected result before comparing model outputs.

Run each candidate against the same cases. Repeat cases when the decision depends on consistency rather than one successful answer. A useful log includes task identifier, configuration, completion status, first-response time, total completion time, token usage when available, and the time a reviewer spends correcting the result.

Score correctness before style. If an answer produces valid JSON with the wrong customer identifier, it fails. If it includes the right value but silently changes the requested unit, it also fails. Record these separately from formatting problems so that a prompt improvement is not mistaken for a reasoning improvement.

Interpret latency and cost carefully

Measure the full path your users experience. Network delay, tool execution, retries, output length, and service load can affect elapsed time. A result from one chat session cannot establish a universal latency advantage for a thinking level.

For API tests, use the usage fields returned by the API and the applicable pricing documentation. For a third-party service, use that service's actual accounting. Do not infer an exact bill from the level's name. A slower response that needs no repair may finish the task sooner than a fast response requiring several corrections.

Handle timeouts as failures with a recorded reason. Avoid unlimited retries, especially when the workflow includes actions with side effects. Retrying a text-generation request and repeating an external operation require different controls.

Apply the result in a chat workflow

If a chat interface exposes a documented reasoning control, record its label and compare the same prompt across available settings. If it does not, you can still evaluate prompt quality, but you cannot claim to have tested an API thinking level. Do not assume MidassAI provides a Deep Think toggle, token meter, or batch scheduler.

Keep the least demanding configuration that meets your acceptance criteria, retain a fallback for known failure cases, and rerun the evaluation when the model or integration changes. The resulting decision is specific to your workload, which makes it more useful than a universal recommendation to select low, medium, or high for everything.