Gemini Thinking Levels vs Claude Effort: How Reasoning Controls Differ

Short version: Gemini's thinking_level and Claude's effort look like the same dial, but they turn different things. Gemini's thinking_level sets how deeply the model reasons before it answers, with up to four values (minimal, low, medium, high) depending on the model. Claude's effort sets how much work the model puts into the whole response, thinking, text and tool calls included, with up to five values (low, medium, high, xhigh, max). One is a reasoning-depth setting. The other is a spending-behaviour setting that happens to steer reasoning.

Everything below comes from Google's Gemini API thinking docs and Anthropic's effort documentation, plus each vendor's pricing page, all checked on 22 October 2026. We haven't run latency or quality benchmarks on these settings, so there are no "we tested" numbers here: where a behaviour is described, it's described per the vendor's own docs. If you want the background on Google's flagship first, our Gemini 4 Argon explainer covers its specs and thinking levels in depth.

The Short Answer: Two Dials Built on Different Ideas

Both vendors moved away from asking you for an exact number of thinking tokens. Gemini 2.5 used a numeric thinkingBudget; Claude 4.5 and earlier used budget_tokens. Today both lead with named levels instead. But the design philosophy behind the names is different, and that difference explains almost every quirk you'll hit.

Gemini's thinking_level is about reasoning. Google describes it as the setting that "decides how deeply the model reasons before it answers." It lives in the generation config next to temperature and output limits, and it governs the model's raw thoughts. Claude's effort is about token spend across everything. Anthropic says it "affects all tokens in the response," including text, tool calls and function arguments, and thinking when thinking is active. It lives in output_config, and a separate thinking parameter decides whether Claude thinks in dedicated blocks at all.

So when you set Gemini to low, you're asking for shallower reasoning. When you set Claude to low, you're asking for a cheaper, terser response overall: fewer tool calls, less preamble, and less thinking. Same word, different contract.

Side-by-Side: thinking_level vs effort

Here's the full comparison on the current flagship lines, Gemini 4 Argon and the Gemini 3.x family on one side, the Claude 5.x family on the other. For how the two flagships compare on benchmarks and price, see our Gemini 4 Argon vs Claude Opus 5.5 comparison.

How Gemini thinking_level Works

Google's docs say Gemini models "engage in dynamic thinking by default, automatically adjusting the amount of reasoning effort based on the complexity of the request." thinking_level lets you move that baseline. The generateContent guide calls the parameter "required for Gemini 4 and recommended for Gemini 3 models."

The four values

• minimal: matches the "no thinking" setting for most queries. Google is explicit that it "does not guarantee that thinking is off"; the model may still reason a little on complex tasks.
• low: "Minimizes latency and cost."
• medium: "Balanced thinking for most tasks," and the default on Gemini 4 Argon, Gemini 3.8 Flash and Gemini 3.6 Flash.
• high: "Maximizes reasoning depth." Google warns the model "may take significantly longer to reach a first (non thinking) output token." Every model marks high as dynamic.

Which Gemini models support which levels

Support is uneven, and sending an unsupported value is an error rather than a silent fallback. The main rows from Google's model table:

Two traps stand out. minimal returns an error on Gemini 4 Argon and Gemini 3.8 Flash, so code written for Flash-Lite won't port up unchanged. And defaults differ by generation: older Gemini 3 previews default to high, while 3.6, 3.8 and Argon default to medium. Moving a workload from gemini-3-flash-preview to gemini-3.8-flash (see what's new in Gemini 3.8 Flash) without setting a level quietly lowers its reasoning depth.

Pro tip: If you omit thinking_level, Gemini uses the model default. Set it explicitly in production so a model swap never changes your reasoning depth behind your back.

How Claude effort Works

Anthropic frames effort as the trade-off "between response thoroughness and token efficiency." It's generally available on the Claude API, Claude Platform on AWS, Amazon Bedrock, Google Cloud and Microsoft Foundry, with no beta header needed for the top-level parameter. Our Claude Opus 5.5 overview covers the model that changed the default.

The five values

• low: most efficient, "significant token savings with some capability reduction." At this level Claude "can skip thinking entirely for simpler problems."
• medium: moderate savings; the default on Claude Opus 5.5 and Claude Haiku 5.5.
• high: "spends as many tokens as the task needs for excellent results"; the default on every other model that supports effort.
• xhigh: extended capability for long-horizon work; Anthropic's typical use case is agentic and coding tasks running over 30 minutes.
• max: "absolute maximum capability with no constraints on token spending."

Which Claude models support which levels

Effort works on Claude Fable 5.1 and 5, Mythos 5.1, 5 and Preview, Opus 5.5, 5, 4.8, 4.7, 4.6 and 4.5, Sonnet 5.5, 5 and 4.6, and Haiku 5.5. The top two levels are narrower:

• max is available on every model in that list except Opus 4.5.
• xhigh is available on Fable 5.1, Mythos 5.1, Fable 5, Mythos 5, Opus 5.5, Opus 5, Opus 4.8, Opus 4.7, Sonnet 5.5, Sonnet 5 and Haiku 5.5. Anthropic notes that "not every model that supports max supports xhigh": Opus 4.6, Sonnet 4.6 and Mythos Preview have max but not xhigh.

The most important sentence on Anthropic's page: "Effort is a behavioral signal, not a strict token budget." At lower levels Claude still thinks on hard problems, just less than it would at higher levels. Levels are also calibrated per model: Anthropic says Sonnet 5.5's levels are "recalibrated," so high on Sonnet 5.5 doesn't produce the same amount of thinking as high on Sonnet 5.

The Parameter in Each API

The syntax is where people trip, because the two parameters sit in different objects. Here is each one, adapted from the vendors' own examples.

Gemini: Interactions API (Python)

from google import genai

client = genai.Client()

interaction = client.interactions.create(
    model="gemini-4-argon",
    input="Find the bug in this retry loop and explain it.",
    generation_config={
        "thinking_level": "high",        # low | medium | high on Argon
        "thinking_summaries": "auto"     # optional: return thought summaries
    }
)
print(interaction.output_text)
print("Thought tokens:", interaction.usage.total_thought_tokens)

Gemini: generateContent (Python and REST)

from google import genai
from google.genai import types

client = genai.Client()

response = client.models.generate_content(
    model="gemini-3.8-flash",
    contents="Classify this support ticket.",
    config=types.GenerateContentConfig(
        thinking_config=types.ThinkingConfig(thinking_level="low")
    ),
)
print(response.text)

# REST body fragment
{
  "contents": [{"parts": [{"text": "Classify this support ticket."}]}],
  "generationConfig": {"thinkingConfig": {"thinkingLevel": "low"}}
}

Claude: Messages API (cURL and Python)

curl https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{
    "model": "claude-opus-5-5",
    "max_tokens": 64000,
    "output_config": {"effort": "high"},
    "thinking": {"type": "adaptive", "display": "summarized"},
    "messages": [{"role": "user", "content": "Find the bug in this retry loop."}]
  }'

# Python
response = client.messages.create(
    model="claude-sonnet-5-5",
    max_tokens=16000,
    output_config={"effort": "low"},
    messages=[{"role": "user", "content": "Classify this support ticket."}],
)

Notice the extra field on the Claude side. effort and thinking are separate objects, and Anthropic warns you not to pass adaptive as an effort value: "adaptive is a thinking mode, not an effort level." On Gemini, there's no second object: the level is the reasoning control.

Gemini through the OpenAI-compatible endpoint

If you call Gemini through Google's OpenAI compatibility layer, you send OpenAI's reasoning_effort and Google maps it. Per Google's table, minimal maps to low on Gemini 4 Argon (and to minimal on 3.1 Flash-Lite and 3 Flash); low, medium and high map one to one; and on 2.5 models they become budgets of 1,024, 1,024, 8,192 and 24,576 tokens. Google also says reasoning "cannot be turned off for Gemini 2.5 Pro or 3 models" through this route.

Thinking Budgets and the Off Switch

Both vendors still ship the older numeric budgets, and both are steering you away from them.

On Gemini, thinkingBudget belongs to the 2.5 series. Google's generateContent guide says "Gemini 2.5 series models don't support thinkingLevel; use thinkingBudget instead." Ranges run from 128 to 32,768 tokens on 2.5 Pro (which can't disable thinking) and 0 to 24,576 on 2.5 Flash, where 0 turns thinking off and -1 turns on dynamic thinking. On Gemini 4 Argon the budget is deprecated: sent alone, it "maps to the nearest thinkingLevel and returns a warning," and sending both together returns a 400 error. Vertex AI's docs say the same: both parameters in one request is an error. (One caveat worth flagging: the Interactions API's model table lists low/medium/high for 2.5 models too, so check which API surface you're on.)

On Claude, manual extended thinking (thinking: {"type": "enabled", "budget_tokens": N}) is deprecated on the 4.6 models and rejected with a 400 error on Claude 4.7 and later. Opus 4.5 is the odd one out: it's the only extended-thinking-only model that supports effort, and Anthropic says to set both there, effort for the overall response and budget_tokens for thinking depth.

Turning thinking off

This is the sharpest practical difference. Google says plainly: "You cannot disable thinking for Gemini 4 Argon," and Gemini 3 Flash and Flash-Lite "do not support full thinking-off." The lowest you can go is low on Argon or minimal where it exists, and minimal still isn't a guarantee.

Claude's answer is model by model, and it interacts with effort:

• Opus 5.5, Fable 5.1, Fable 5, Mythos 5.1, Mythos 5 and Mythos Preview: thinking can't be turned off; "disabled" returns a 400 error.
• Opus 5 and Haiku 5.5: "disabled" works at high effort or below and returns a 400 at xhigh or max.
• Sonnet 5.5: rejects "disabled"; send thinking: {"type": "between_tools"} to turn off up-front thinking, accepted at high or below.
• Sonnet 5, Opus 4.8, 4.7, 4.6 and Sonnet 4.6: "disabled" turns thinking off. On the 4.x models, thinking is off by default until you set "adaptive".

What Effort Controls That thinking_level Doesn't

Because effort covers every output token, it reaches parts of the response that Gemini's level doesn't claim to touch. Anthropic's docs list what lower effort tends to do in tool use: combine operations into fewer tool calls, make fewer calls overall, skip the preamble and use terse confirmations. Higher effort tends to explain the plan first, make more tool calls, write detailed summaries and add more code comments.

That's a big deal for agents. On Claude, turning effort down changes how the agent behaves, not only how long it thinks, which makes it as much a context engineering decision as a cost one. Anthropic's Haiku 5.5 guidance spells out the downside: in long agent prompts at low, the model "is more likely to skip a search, stop early, or skip a check." On Gemini, Google describes thinking_level purely as reasoning depth, and says thinking models "work with all of Gemini's tools and capabilities" without describing a level-driven change in tool-call volume.

There's one limit the other way. Anthropic notes that on Opus 5, "effort controls thinking volume, not visible response length," so changing effort "does not reliably shorten responses": prompt for length instead. Gemini's best-practice section gives similar advice from the other side: if you want a long output, prompt the model to think less so more of the token allowance goes to the answer.

Can You See the Thinking? Summaries, Signatures and Display

Neither vendor shows you the raw chain of thought. Both return summaries if you ask, and both attach an encrypted signature you must send back.

Gemini returns only the final output by default. On the Interactions API you opt in with thinking_summaries: "auto"; on generateContent you set includeThoughts: true and read the parts flagged thought. Google adds that "thinking levels and budgets apply to the model's raw thoughts and not to thought summaries," so a higher level means more hidden reasoning, not a longer summary. A thought step may carry only a signature and no summary on simple requests.

Claude uses a display field on the thinking config. "omitted" is the default on Opus 5.5, Sonnet 5.5, Haiku 5.5, the Fable and Mythos models, Opus 5, Sonnet 5, Opus 4.8 and Opus 4.7: you get thinking blocks with an empty text field and a signature. "summarized" returns readable summaries (the default on Opus 4.6, Sonnet 4.6 and earlier). Anthropic says summaries are written by a different model, and "no display setting returns the raw chain of thought."

Pro tip: Anthropic says display: "omitted" gives a faster time-to-first-text-token when streaming, because the server skips streaming thinking tokens. It reduces latency, not cost: you're still charged for the full thinking.

Billing and Latency: What More Thinking Costs

Here the two vendors agree almost word for word. Google: "response pricing is the sum of output tokens and thinking tokens," and pricing "is based on the full thought tokens the model needs to generate," even though only a summary comes back. Anthropic: thinking tokens "are billed as output tokens, even when the thinking text isn't returned to you." Turning either dial up therefore raises your output bill, and output is the expensive side of every price sheet.

Prices are standard paid-tier rates from Google's and Anthropic's pricing pages on 22 October 2026. For the Claude side of the bill in agent workloads, our Claude Code API pricing guide breaks down rate limits and usage costs.

Two more billing details are easy to miss. First, the hard ceilings include thinking on both sides. Gemini's max_output_tokens counts thought tokens, and if the model hits it mid-reasoning you get a truncated or empty answer "while still billing for any thinking tokens generated." Claude's max_tokens works the same way, which is why Anthropic recommends starting around 64k at xhigh or max on Opus 4.7 and 4.8. Google's advice: lower thinking_level instead of setting a small output cap. Second, Gemini's thought signatures "will increase the input tokens you are charged when sent back."

On latency, neither vendor publishes per-level timing. The documented direction is clear, though: Google says high may take "significantly longer" to the first non-thinking token, and Anthropic says low effort "can significantly reduce response times and costs."

Tools, Multi-Turn Conversations and Caching

Reasoning controls don't live in isolation once you run an agent loop, and this is where the two designs diverge again.

Signatures in tool loops. Both vendors require you to return the encrypted reasoning state. Gemini's Interactions API handles it for you in stateful mode (store: true plus previous_interaction_id); in stateless mode you must resend every thought block unchanged. On generateContent, Gemini 3 and 4 may put signatures on any part, and they're required for function calling. Claude requires you to pass thinking blocks back "complete and unmodified" within a tool-use turn, and manual extended thinking only supports tool_choice of auto or none. If you're comparing the two coding agents built on these models, see our Claude Code vs Google Antigravity breakdown.

Changing the dial mid-conversation. On Gemini, the level is part of each request's config. On Claude, Anthropic warns that changing top-level effort between requests "doesn't preserve cached prefixes from earlier turns." Newer models (Fable 5.1, Mythos 5.1, Opus 5.5, Opus 5, Sonnet 5.5 and Haiku 5.5) support a per-message effort change in beta, sent as an empty system message carrying output_config with the header mid-conversation-output-config-2026-07-01, which keeps the cache intact. Toggling thinking modes also invalidates Claude's prompt cache. Our Claude prompt caching guide explains why prefix changes break cache hits.

"messages": [
  {"role": "user", "content": "Plan the migration in three steps."},
  {"role": "assistant", "content": "1. Export... 2. Create schema... 3. Import..."},
  {"role": "system", "content": [], "output_config": {"effort": "low"}},
  {"role": "user", "content": "Summarize the plan in one sentence."}
]

If you run the same agent on both providers, the caching side matters as much as the reasoning side: Gemini 4 Argon supports implicit caching only, while Claude uses explicit cache breakpoints. Our Gemini vs Claude prompt caching comparison covers that split.

Common Mistakes When Switching Between the Two

• Treating low as the same setting on both. Gemini low trims reasoning depth. Claude low trims the whole response, including tool calls and checks.
• Sending minimal to Gemini 4 Argon or 3.8 Flash. Both return an error. minimal exists only on some models.
• Passing adaptive as an effort value. It's a thinking type on Claude, not an effort level.
• Sending thinkingBudget and thinkingLevel together. That's a 400 on Gemini 4 Argon and an error on Vertex AI.
• Using budget_tokens on Claude 4.7 or later. Manual extended thinking is rejected there; use adaptive thinking with effort.
• Setting thinking: disabled with xhigh or max. Opus 5 and Haiku 5.5 return a 400 at those levels, and Opus 5.5 never accepts disabled.
• A tight output cap to "save money." On both platforms the cap includes thinking, so you can pay for reasoning and get an empty answer.
• Relying on defaults across model upgrades. Opus 5.5 defaults to medium where Opus 5 defaulted to high; Gemini 3 previews default to high where 3.8 Flash defaults to medium.

The Verdict

Gemini's thinking_level is the simpler dial: one setting, up to four values, aimed squarely at how deeply the model reasons, with no true off switch on the flagship. Claude's effort is the broader one: up to five values that scale the whole response, sitting next to a separate thinking parameter whose rules change model by model. My take: Gemini is easier to reason about, and Claude gives you more control over agent behaviour, at the price of a compatibility matrix you have to check before every model upgrade.

Whichever you use, three rules hold on both platforms: set the level explicitly instead of trusting defaults, keep your output cap generous because it includes thinking, and remember you're billed for every hidden thinking token at output rates.

Frequently Asked Questions

Keep Reading

• 25 best Gemini 4 Argon prompts for developers
• 25 best Claude Opus 5.5 prompts for coding
• How to use Google Antigravity with Gemini 4 Argon