Reasoning Effort Parameter Comparison: Claude vs GPT vs Gemini

The cheapest speed boost in AI development isn’t a faster model, it’s a single parameter most teams set once and never touch again. Every major provider now ships a reasoning effort control: Claude’s effort, GPT-5.6’s reasoning.effort, and Gemini’s thinking_level. They look interchangeable, and they even share the same level names (low, medium, high), which is exactly the trap. A reasoning effort misconfiguration is one of the few single-line changes that can quietly double an API bill. The same word buys you different behavior, different latency, and a different bill depending on which API you’re calling, and porting a setting from one provider to another can quietly change what your application does. This reasoning effort parameter comparison lines up the current parameter names, levels, and defaults for all three, walks through a working code example for each, and flags the migration pitfalls that only show up after something breaks.

What “Reasoning Effort” Actually Controls

All three parameters answer the same underlying question, how much internal computation the model should spend before it responds, but they answer it at very different scopes, and any serious reasoning effort discussion has to start with scope rather than level names. That’s where the trouble starts. Claude’s effort is the broadest of the three: it governs the entire response, including tool calls and explanatory text, not just the thinking. GPT-5.6’s reasoning.effort governs reasoning-token generation specifically, and it sits alongside a separate reasoning.mode switch (standard vs. pro) that controls how much overall model work goes into producing a final answer. Gemini’s thinking_level is the narrowest: it governs only the model’s internal “thinking process” step before output is produced.

So what actually changes when you port “high” from Claude to Gemini and expect the same bill? On Claude, high effort means more tokens across everything: the explanation gets longer, the tool calls get more numerous, the reasoning gets deeper. On Gemini, the same word only stretches the internal thinking step; the visible output doesn’t necessarily grow at all. Neither vendor treats these level names as a shared standard, so stop treating them like one. The catch here is that nothing in the naming warns you: “medium” feels like “medium,” and developers keep learning the hard way that it isn’t.

The Reasoning Effort Parameter Comparison, Side by Side

Use this table as a translation reference for effort settings across providers, since the level names overlap without meaning the same thing.

* Level availability varies by specific Gemini 3.x model; check the model page before assuming a level is supported.

Claude’s Effort: The Widest Dial of the Three

Claude’s effort parameter is set through output_config.effort in a Messages API request, and it’s available on supported Claude models with no beta header required, but check the supported-models list in the docs, since it doesn’t cover every model. By default Claude uses high effort. Setting effort to “high” produces exactly the same behavior as omitting the parameter entirely. The five levels run from max, with no constraints on token spending, down through xhigh for extended long-horizon capability, high as the default, medium as a balanced middle ground, and low as the most efficient setting with some capability reduction. Low is the natural choice for simple tasks like subagent calls where speed and cost matter more than depth.

The recommended defaults shift per model generation, and the lineup moves fast, Opus 5.5 and Sonnet 5.5 are the current generation, with Opus 5.5 defaulting to medium rather than high. Don’t trust a remembered list: Opus 4.7 and 4.8 documentation suggests starting at xhigh for coding and agentic work, while Sonnet-class guidance suggests staying at the default for most tasks and reserving xhigh for the hardest coding problems. Then there’s the caching wrinkle, which is pure mechanism. Effort shapes how the prompt itself is rendered, so changing effort mid-conversation invalidates cached prompt prefixes. If a long session leans on prompt caching, pick one effort level at the start and hold it constant rather than adjusting turn by turn.

import anthropic

client = anthropic.Anthropic()
response = client.messages.create(
    model="claude-opus-5-5",
    max_tokens=4096,
    messages=[
        {"role": "user", "content": "Summarize the trade-offs between microservices and monoliths."}
    ],
    output_config={"effort": "medium"},
)

for block in response.content:
    if block.type == "text":
        print(block.text)

GPT-5.6’s Reasoning.effort: Depth, Plus a Separate Mode

GPT-5.6 exposes reasoning depth through reasoning.effort in the Responses API, with six named levels, none, low, medium, high, xhigh, and max. Omit the parameter and you get medium in both standard and pro reasoning modes. The none setting is the interesting one: unlike every other provider’s lowest tier, it doesn’t mean “light reasoning”; it behaves like a non-reasoning model outright, which makes it the closest thing to a true “reasoning off” switch among the three. One scope note for newer models: the none-as-off-switch framing above describes GPT-5.6. On the GPT-6 family the level range runs low through max with medium as the default, so none isn’t in the picture, recheck the level list in OpenAI’s current guide if you’re building on GPT-6.1 Sol or later rather than assuming the 5.6 mapping.

Reasoning mode (reasoning.mode: “standard” or “pro”) is a genuinely separate axis from effort, and confusing the two is the most common GPT-side mistake. Mode selects how much overall model work goes into producing a final answer; effort controls reasoning depth within that mode. You can think of it as mode choosing the size of the workshop and effort choosing how long the tools run. And one hard constraint to know before you architect around it: the Chat Completions API and function tools can’t both be used together unless effort is set to “none”, which is an API-level restriction, not a quality trade-off you can tune around. The official workaround is to move the flow to the Responses API, where reasoning and tools work together. The only Chat Completions option is effort none, which also switches reasoning off entirely. While researching this, the loudest complaint I found was on OpenAI’s developer forum: a developer who hit this exact error the moment they moved from 5.4 to 5.6. Their take was blunt, function tools shouldn’t be blocked on Chat Completions at all, calling the restriction pointless and aggravating. That’s the sound of a migration trap springing in production, not in a changelog.

from openai import OpenAI

client = OpenAI()
response = client.responses.create(
    model="gpt-5.6",
    input="Summarize the trade-offs between microservices and monoliths.",
    reasoning={"effort": "medium"},
)

print(response.output_text)

Gemini’s Thinking_level: Thinking Only, Nothing Else

Gemini 3-series models control reasoning depth through thinking_level, which replaced the older numeric thinking_budget parameter. Gemini 3 and Gemini 3 Flash default to HIGH, giving the model more tokens for complex, multi-step reasoning; Gemini 3 Flash also introduced MINIMAL and MEDIUM levels for throughput-optimized and balanced use cases. Google’s own migration guidance for Gemini 3.5 Flash explicitly recommends replacing thinking_budget with thinking_level across all Gemini 3.x models, and the default effort on that model shifted from high to medium in the same release. Gemini 3.6 Flash is now generally available. Defaults vary by model: HIGH on Gemini 3.1 Pro (levels LOW/MEDIUM/HIGH), medium on the 3.5 and 3.6 Flash models, MINIMAL on Flash-Lite.

Buried in those migration notes is the detail that saves a wasted afternoon. You cannot use thinking_level and the legacy thinking_budget in the same request. Google’s API doesn’t silently prefer one or degrade gracefully. It returns a 400 error. Reading through a dev.to migration guide for Gemini 3.6 Flash, the detail that stuck with me: deprecated fields like temperature, top_p, and top_k are ignored today but will return HTTP 400 on future model generations, a time bomb for any adapter that “works” right now. Any code still passing thinking_budget needs to migrate before it’s combined with newer Gemini 3.x features, and this is exactly the kind of thing that only surfaces in production if you don’t read the migration guidance first.

from google import genai
from google.genai import types

client = genai.Client()
response = client.models.generate_content(
    model="gemini-3.6-flash",
    contents="Summarize the trade-offs between microservices and monoliths.",
    config=types.GenerateContentConfig(
        thinking_config=types.ThinkingConfig(thinking_level="high")
    ),
)

print(response.text)

Three Migration Traps That Break Real Integrations

The gotchas in this reasoning effort comparison are the ones most likely to wreck a working integration when a team ports a workload across providers. Used as a pre-migration checklist, they read like this:

1. Don’t trust “medium” twice.
   Verify quality and latency on your own evaluation set after any cross-provider migration instead of reusing a level name. The scopes differ, the defaults differ, the maxima differ, the name is the only thing that’s the same.
2. Check tool-calling interactions separately. Lower effort levels on Claude reduce the number of tool calls the model makes, which can quietly change agentic behavior. GPT-5.6’s tool-calling restriction at non-“none” effort is a hard API constraint with no middle ground. Test the tool path, not just the text path.
3. Re-check defaults on every model upgrade. The documentation itself tells the story here. Anthropic and Google have both changed default effort behavior within a single model family. A default that held on one version isn’t guaranteed on the next, so pin the level explicitly in code rather than relying on the omission default.

Assume every default you rely on will change.

Picking a Level for Your Actual Workload

Figuring out which effort level to pick starts with the workload, not the provider. For latency-sensitive, simple tasks (classification, short lookups, chat), start reasoning effort at the lowest or near-lowest level on any provider and raise it only if your evaluations show a real quality gap. There’s no prize for spending reasoning tokens on a task a lookup could answer. For agentic and coding workloads, start near each provider’s recommended default (Claude at high, stepping to xhigh for hard coding tasks; GPT-5.6 at medium, testing high or xhigh; Gemini at high), and step down only after measuring quality on your own tasks rather than guessing. For frontier, high-stakes work, Claude’s max and GPT-5.6’s max are built for exactly that, while Gemini’s high is currently the ceiling on most 3.x models.

There’s no single “equivalent” setting across all three APIs, and hunting for one is the mistake to avoid. The practical takeaway from this reasoning effort parameter comparison is to treat effort settings as per-provider tuning knobs, each verified against your own evaluation set, rather than a value you carry over unchanged. For more API configuration breakdowns in the same vein, see AI Discovery Wire’s AI Tutorials coverage.

FAQ