Reasoning Effort Settings (Low, Medium, High)

TL;DR: Reasoning effort is not a universal low/medium/high scale. OpenAI's reasoning_effort runs seven levels (none to max, default medium); Anthropic's output_config.effort runs five (low to max, default high); Google's thinkingLevel or thinking_level runs four (minimal to high), with which four actually supported varying by model. Higher effort means more billed tokens and more latency on all three, not just better answers.

Everything below was checked against each vendor's own documentation on September 3, 2026. Reasoning-effort surfaces are new enough, and have already changed enough, that the exact values matter more than the general concept.

What is the reasoning effort parameter?

A reasoning model decides how much internal reasoning to generate before it produces a visible answer, and the effort parameter is how you steer that decision without setting a raw token count. It's a behavioral dial, not a budget: you tell the model to spend less effort or more, and the model decides how many actual tokens that translates to for the specific request in front of it.

That's a meaningfully different control from a fixed token budget, which some of these same vendors also expose separately (Anthropic's older budget_tokens, Google's thinkingBudget). An effort level is a target behavior; a budget is a hard number. The two aren't interchangeable, and mixing them up is the single most common source of confusion in this area.

What values does OpenAI's reasoning_effort accept?

Seven, and the field name itself depends which API you're calling. On Chat Completions it's a flat reasoning_effort field on the request. On the Responses API it's nested, reasoning.effort. Both reference the same underlying enum, described in OpenAI's own schema: "Constrains effort on reasoning for reasoning models. Currently supported values are none, minimal, low, medium, high, xhigh, and max. Reducing reasoning effort can result in faster responses and fewer tokens used on reasoning in a response." The default is medium.

OpenAI's reasoning guide frames the parameter the same way: "The reasoning.effort parameter guides the model on how much to think when performing a task." It also adds a caveat worth taking literally rather than assuming away: "Not all reasoning models support every value. See the reasoning guide for model-specific support." Check the specific model before you rely on a level existing.

One more wrinkle inside OpenAI's own product line: the Realtime API does not use the same value set. Its RealtimeReasoningEffort schema description reads: "Constrains effort on reasoning for reasoning-capable Realtime models such as gpt-realtime-2." It accepts only minimal, low, medium, high and xhigh, defaulting to low. No none, no max, and a different default than the seven-level version. One vendor, one parameter concept, two different value sets depending on which of its own APIs you're calling.

Effort and reasoning mode are also separate axes on the Responses API, worth not conflating: "Reasoning mode and reasoning effort are independent. Mode selects standard or pro execution, while reasoning.effort controls how much reasoning the model applies within that mode."

What values does Anthropic's effort accept?

Five: low, medium, high, xhigh and max, set at output_config.effort rather than inside Anthropic's thinking configuration. The default is high, and Anthropic states the equivalence directly: setting effort to "high" produces exactly the same behavior as omitting the effort parameter entirely.

Effort here reaches further than just the thinking phase. Anthropic's documentation is explicit that the parameter affects every output token in the response, tool calls and function arguments included, not only the reasoning text, so a lower effort level also means fewer and terser tool calls, not just less visible thinking.

Availability is per-model, the same caveat as OpenAI's: "Not every model that supports max supports xhigh." Anthropic's own migration guidance for its newest model is a useful, concrete framing of the trade-off: run a fresh evaluation sweep rather than reuse an old setting, because low and medium effort are worth testing as cost and latency controls, and max effort is worth testing specifically where maximum capability matters more than token spend.

What does Google call its reasoning effort setting?

Two names, on two APIs, with different casing and a different level count on each.

generateContent (the established API). thinkingConfig.thinkingLevel, an enum with values MINIMAL, LOW, MEDIUM and HIGH, uppercase, plus a THINKING_LEVEL_UNSPECIFIED default state. Google's reference describes the field precisely: "Controls the maximum depth of the model's internal reasoning process before it produces a response. The default value is model-dependent. Refer to the Thinking levels guide for more details. Recommended for Gemini 3 or later models. Use with earlier models results in an error." A separate sibling field, thinkingConfig.thinkingBudget, sets a raw token count instead of a named level, for whichever models still support it.

Interactions API (the newer one). A plain thinking_level field, lowercase, inside generation_config. There are four documented values total, minimal, low, medium and high, but which of those four a given model actually accepts varies: Google's own Gemini 3 documentation states plainly that Gemini 3.1 Pro does not support minimal at all, while Gemini 3.1 Flash-Lite and Gemini 3 Flash both do. Check the specific model's supported-levels list rather than assuming all four apply everywhere.

The default isn't fixed across the family either. Google's guidance is direct: "If thinking_level is not specified, Gemini 3 will default to high." That's the default for Gemini 3.1 Pro and Gemini 3 Flash. Gemini 3.1 Flash-Lite is the exception, defaulting to minimal instead, and Google adds a caveat worth taking literally rather than treating minimal as an off switch: "minimal does not guarantee that thinking is off." Google frames the whole scale the same non-strict way Anthropic frames effort: "Gemini 3 treats these levels as relative allowances for thinking rather than strict token guarantees."

Every provider's reasoning effort field, side by side

Five rows, four vendors' worth of naming, no two value sets identical. Even within OpenAI, the Realtime variant quietly drops two of the seven values everywhere else uses.

Does reasoning effort change what you're billed for?

Yes, on every vendor here, and the shape of the answer is consistent even though the field names aren't: reasoning tokens are generated, billed as output, and never fully separable from the response you asked for.

OpenAI. The output cap on both its APIs is described the same way: "An upper bound for the number of tokens that can be generated for a response, including visible output tokens and reasoning tokens." Push effort high enough on a hard task and you can exhaust that cap before the model writes anything visible, which is a real failure mode, not a hypothetical: a response can come back with nothing in it but a truncation status. Elsewhere in OpenAI's schema, describing a related token category, the same principle is stated again: "like reasoning tokens, these tokens are still counted in the total completion tokens for purposes of billing, output, and context window limits."

Anthropic. There's no separate thinking budget to set; Anthropic frames cost control as two independent levers instead: "You don't set a thinking token budget. Two controls bound cost:" a hard max_tokens cap on the whole request, and effort as soft guidance over how much of that cap gets spent on thinking rather than the visible answer. What you're billed doesn't match what you see, either: "You are billed for the full thinking process, not the thinking content visible in the response." The exact split is readable in the response's usage.output_tokens_details.thinking_tokens field.

Google. Usage metadata tracks thinking separately from ordinary output: thoughtsTokenCount is documented as "Output only. Number of tokens of thoughts for thinking models." Google's thinking guide states the pricing consequence directly: "Pricing is based on the full thought tokens the model needs to generate, despite only the summary being output from the API." One thing Google's reference does not state either way: whether maxOutputTokens can be exhausted by thinking before any visible text is produced, the way OpenAI's cap explicitly can be. That's a real gap in the documentation, not a settled "no" — don't assume Google's behavior here matches or differs from OpenAI's until Google says so.

Does a higher reasoning effort mean a slower response?

In general, yes: more reasoning tokens take real wall-clock time to generate before the visible answer starts, on every vendor here, and two of the three say so in their own words rather than leaving it implied.

OpenAI's guidance for its top level is blunt about the trade-off: only reach for xhigh "when your evals show a clear benefit that justifies the extra latency and cost." Its lowest level exists for the opposite case: latency-critical work that doesn't benefit from extended reasoning at all.

Anthropic documents the same trade-off level by level. Its lowest setting: "Claude minimizes thinking. Skips thinking for simple tasks where speed matters most." Its default, one level up from the bottom of the five: "Claude almost always thinks. Provides deep reasoning on complex tasks." Anthropic even ships a ready-made system-prompt snippet for developers who want to push the model toward less thinking: "Extended thinking adds latency and should only be used when it will meaningfully improve answer quality, typically for problems that require multistep reasoning." And because thinking tokens are billed inside the same cap as the answer, Anthropic's own guidance is direct about the mechanical reason: "Thinking tokens count toward the max_tokens limit for the turn, so the budget must leave room for the final response."

What do the vendors leave undocumented?

Two gaps worth naming rather than guessing past.

Do stop, frequency penalty or presence penalty behave normally on a reasoning model? OpenAI's spec is explicit that stop sequences don't apply at all on two specific reasoning models: "Not supported with latest reasoning models o3 and o4-mini." Whether the penalty parameters do anything meaningful on a reasoning model in general is a separate question, and it's genuinely open: OpenAI's reasoning guide and its companion reasoning best-practices page contain zero occurrences of the word "penalty" between them. That silence isn't proof the penalties are inert on those models, only proof that OpenAI hasn't documented the interaction either way. Test before you rely on it.

Can Google's maxOutputTokens be exhausted by thinking first? Covered above, and worth repeating on its own: Google's field description for maxOutputTokens says only this: "Optional. The maximum number of tokens to include in a response candidate." No mention of reasoning tokens one way or the other. OpenAI states its equivalent cap explicitly includes reasoning tokens. Google simply doesn't say, for either reading.

When is a higher effort level actually worth it?

Not by default, according to every vendor's own guidance, not just as a cost-saving suggestion from this page.

Google's own best-practice guidance ties effort level to task type directly: "Simple tasks: Use minimal or low thinking for fact retrieval or classification", "Moderate tasks: Use default thinking for comparing concepts or creative reasoning", and "Complex tasks: Use maximum thinking for advanced coding, math, or multi-step planning".

OpenAI's per-level guidance runs the same shape: its lowest levels are recommended for latency-sensitive work like voice interfaces, fast retrieval and classification; its middle levels for agentic coding, planning and multi-step decisions; its top levels reserved for long-running research, security review and the hardest coding and debugging work, specifically flagged as only worth the added cost and latency when your own evaluation results show the difference.

Anthropic's models-specific guidance repeats the same instruction across every current model: start at the default, high, and step up or down only after your own evals show the change actually holds quality while saving cost, rather than porting a setting from an older model or defaulting to the maximum on principle. None of the three vendors that document effort recommend maxing it out as a default policy. Treat it the way you'd treat any other cost lever: set it to match the task, then verify with your own evaluation, not with a benchmark number nobody here is claiming.

Copy-paste: the same request at medium effort, three ways

# OpenAI — Chat Completions. Flat `reasoning_effort`, seven possible values.
curl https://api.openai.com/v1/chat/completions \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-5.6",
    "reasoning_effort": "medium",
    "messages": [{ "role": "user", "content": "Outline a rollback plan for a failed migration." }]
  }'

# Anthropic — Messages API. `output_config.effort`, five possible values, default high.
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",
    "max_tokens": 4096,
    "output_config": { "effort": "medium" },
    "messages": [{ "role": "user", "content": "Outline a rollback plan for a failed migration." }]
  }'

# Google — Interactions API. Lowercase `thinking_level`, nested inside generation_config.
curl "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": "Outline a rollback plan for a failed migration.",
    "generation_config": { "thinking_level": "medium" }
  }'

Same word, "medium", in all three requests. It resolves to a different position on a different scale on each vendor, which is exactly why the exact value list matters more than the label.

Sources and access dates

Every claim above traces to a primary document, checked September 3, 2026:

• OpenAI: the reasoning guide, the reasoning best-practices guide, the Responses API reference, and the published OpenAPI specification (info.version 2.3.0) for the ReasoningEffort and RealtimeReasoningEffort schemas.
• Anthropic: the effort guide, the thinking and cost control guide, the extended thinking guide, and the Claude Opus 5 migration guide.
• Google: the generateContent API reference, the Interactions API reference, the Gemini thinking guide, and the Gemini 3 developer guide for per-model thinking-level support and defaults.

Reasoning-effort surfaces are recent and actively changing on all three vendors. For the temperature-and-sampling-parameter equivalent of this task-based breakdown, post 212 covers temperature by use case; post 48 explains the classic sampling parameters that effort supplements rather than replaces; and for every other parameter across all three vendors, post 114 is the full cheat sheet.