“Gemini thinking model” does not identify one specific model in Google’s documentation. It describes a capability in supported Gemini models: a model may use internal thinking before responding. Google says this can help with complex, multi-step planning, math, and code generation, but thinking is not guaranteed on every request—even when enabled or configured. Google Cloud documentation
For API users, the main configuration distinction is by model generation: Gemini 3 and later use thinking_level; Gemini 2.5 and earlier use thinking_budget. Choose a setting based on the task and your latency or token-use priorities, then test it with representative inputs. The level descriptions are qualitative guidance, not measured guarantees of speed, quality, or cost.
Choose a thinking level for the task
Google describes the levels this way:
- MINIMAL: Uses the fewest possible thinking tokens; intended for straightforward tasks. Support varies by model, and the cited documentation says MINIMAL is not supported on Gemini 4 models.
- LOW: Uses fewer thinking tokens and is positioned for faster responses and high-throughput, low-complexity work.
- MEDIUM: Balances reasoning quality and latency for moderately complex work.
- HIGH: Uses maximum thinking capacity; intended for complex prompts, multi-step problem solving, formal code verification, or multi-turn tool execution.
A practical starting point is MINIMAL or LOW for routine requests when lower token use or faster responses matter, MEDIUM for work of moderate complexity, and HIGH for difficult multi-step tasks. These are starting hypotheses, not universal “best” settings: compare answer quality, latency, and usage on representative inputs before choosing a production default.
The supported levels and defaults are model-specific. For example, the cited documentation lists Gemini 3.5 Flash with MINIMAL, LOW, MEDIUM, and HIGH, and MEDIUM as its default. It lists Gemini 3.1 Pro preview with LOW, MEDIUM, and HIGH, and HIGH as its default. Those are documentation entries, not a guarantee of availability in every project or endpoint; check the current model-specific documentation before relying on a model ID, level, or default.
Configure thinking with Google Cloud’s Gemini Enterprise Agent Platform
The examples below target the Google Cloud Gemini Enterprise Agent Platform API using Google’s Gen AI SDK. They are not examples for the Gemini Developer API. The Cloud documentation’s Python setup uses GOOGLE_GENAI_USE_ENTERPRISE=True; its Node.js examples configure the client for Vertex AI. For the Developer API, use its separate Gemini API thinking guide, and verify that the model and configuration you choose are supported there.
Gemini 3 and later: set thinking_level in Python
The Cloud documentation shows the Python SDK with gemini-3.5-flash and a model-supported thinking level. Its model table lists MEDIUM for that model. Set up the client for the Cloud surface as shown here; substitute your project and location values.
export GOOGLE_CLOUD_PROJECT=YOUR_PROJECT_ID
export GOOGLE_CLOUD_LOCATION=global
export GOOGLE_GENAI_USE_ENTERPRISE=True
from google import genai
from google.genai import types
client = genai.Client()
response = client.models.generate_content(
model="gemini-3.5-flash",
contents="Review this function for edge cases and explain any bug you find.",
config=types.GenerateContentConfig(
thinking_config=types.ThinkingConfig(
thinking_level=types.ThinkingLevel.MEDIUM
)
),
)
print(response.text)
Use a level supported by the selected model. Confirm the model is available for your Cloud project and target location before deployment. This request configuration does not guarantee readable thought-summary parts in the response.
Gemini 2.5 and earlier: set thinking_budget in Node.js
The Cloud documentation shows gemini-2.5-flash with a 1,024-token thinking budget in its Node.js Vertex AI example. This CommonJS example keeps the request inside an async function and invokes it with an error handler:
const { GoogleGenAI } = require('@google/genai');
const GOOGLE_CLOUD_PROJECT = process.env.GOOGLE_CLOUD_PROJECT;
const GOOGLE_CLOUD_LOCATION = process.env.GOOGLE_CLOUD_LOCATION || 'global';
async function generateWithThinking(
projectId = GOOGLE_CLOUD_PROJECT,
location = GOOGLE_CLOUD_LOCATION
) {
const client = new GoogleGenAI({
vertexai: true,
project: projectId,
location: location,
});
const response = await client.models.generateContent({
model: 'gemini-2.5-flash',
contents: 'Solve x^2 + 4x + 4 = 0 and give the result.',
config: {
thinkingConfig: { thinkingBudget: 1024 },
},
});
console.log(response.text);
}
generateWithThinking().catch((error) => {
console.error('Gemini request failed:', error);
process.exitCode = 1;
});
Google describes thinking_budget as a soft limit, not a promise that the model will use exactly that number of tokens. The documentation says an unspecified budget is set dynamically up to 8,192 tokens, and -1 explicitly enables dynamic budgeting. Setting the budget to 0 turns thinking off for Gemini 2.5 Flash and Gemini 2.5 Flash-Lite; Google says it cannot be turned off for Gemini 2.5 Pro. Even when thinking content is not returned, the generated answer may still use reasoning-style language. See the Cloud configuration and budget details.
Make production response handling tolerant
Do not assume every response contains thought parts. Google says model behavior is nondeterministic: a request may return no thought parts even when thinking is enabled, a level or budget is set, or thought summaries are requested. Applications should handle missing candidates, content, parts, or summary text instead of treating them as required output.
Thought summaries and thought signatures are different. A summary is readable text that may accompany a response; a signature is an encrypted representation used to preserve reasoning state across turns. Google says to pass returned signatures into subsequent requests in multi-turn interactions. Its official Gen AI SDKs manage signatures automatically in standard chat sessions or when complete response objects are appended to message history. Preserve signatures when present, even if there is no readable thought summary. The documentation also warns that MINIMAL requires thought signatures in applicable multi-turn conversations; omitting them can cause a 400 INVALID_ARGUMENT error.
If you request summaries for application use, treat them as optional response material—not as a complete or verbatim record of the model’s internal computation. Build the user experience around the final answer and your own validation, not on the assumption that a summary will always be available.
Latency and billing: what the documentation supports
Google’s level descriptions associate lower settings with fewer thinking tokens or faster responses, and HIGH with maximum thinking capacity for complex work. They do not provide a numeric latency or quality comparison for a particular workload. The documentation says tokens generated during thinking are billed; for models where thinking is enabled by default, it says those tokens are included in billable usage. It does not provide exact rates on the cited page, so this guide does not estimate a per-request price. Check the applicable current pricing for your model and API before budgeting.
Finally, don’t treat every product name containing “thinking” as interchangeable with the API settings above. Google’s announcement describes Gemini 3.8 Live Extended Thinking specifically as a live-dialogue model for complex tasks; that voice-model description does not establish how it relates to the general thinking_level and thinking_budget controls. Google’s Live model announcement
Bottom line: identify the exact model and API surface first, choose the generation-appropriate control, and validate the tradeoff on your workload. In production, expect thought parts to be absent sometimes and preserve signatures across multi-turn requests when required.
Sources
Thinking | Gemini Enterprise Agent Platform | Google Cloud Documentation
Gemini thinking - generateContent API | Google AI for Developers