Reasoning Effort Ladders: A Cross-Vendor Field Guide

Reasoning effort levels are now a first-class API control at every major LLM vendor — and every vendor built a different ladder. As of mid-August 2026, the surfaces we surveyed expose anywhere from three to seven named rungs, under at least four different parameter names, with defaults that range from the middle of the ladder to its very top — and no shared standard behind any of it.

That divergence is not cosmetic. A config value that means “cheap and fast” on one API can be an invalid value on the next — GLM-5.3 rejects requests that try to disable thinking outright, while Grok silently downgrades an unsupported rung instead of erroring. Port an effort setting across a model swap without checking, and quality, latency, and cost all move at once — sometimes silently, sometimes as a hard failure.

This guide is the operational reference: the current rung set, parameter name, default, and disable behavior for OpenAI, Anthropic, Google, xAI, Z.ai, DeepSeek, Moonshot, and Meta’s Muse Code, plus the migration traps between them and the mechanics of how effort moves your bill. For the consumer-facing side — the ChatGPT effort slider and its cousins — see our explainer on consumer thinking dials; this post stays at the API and CLI layer.

The table below is the whole post in one view: every surface’s documented rung set, exact parameter name, default, and whether thinking can be turned off — taken from each vendor’s own API or product documentation, checked August 14, 2026. Everything after this section unpacks the rows that carry traps.

* Muse Code's docs list none in the flag's value set but separately state the CLI doesn’t support it. ** ultra is client-side multi-agent delegation, clamped to xhigh at the model-call level — see section 07. Source: vendor API and product documentation, checked August 14, 2026.

OpenAI’s control is reasoning.effort, and its cross-model reasoning guide lists up to seven values — none, minimal, low, medium, high, xhigh, and max — with the explicit caveat that supported values are model-dependent. That seven-value list is the guide’s superset, not any one model’s ladder.

On the current GPT-5.6 family, the ladder is narrower. All three durable tiers — Sol, Terra, and Luna — document the identical six-rung set: none, low, medium (the default), high, xhigh, and max, with no minimal rung. GPT-5.5, by contrast, defaults to medium and still lists minimal among its available values. In other words, OpenAI pruned the bottom step of the ladder in its most recent generation — a pattern we will meet again at Google.

Two operational details matter beyond the rung names. First, GPT-5.6’s reasoning tokens are billed as output tokens; they are invisible in the response but still occupy context-window space, and the exact count is reported in usage.output_tokens_details.reasoning_tokens. Second, GPT-5.6 flips a long-standing default: the family defaults to carrying reasoning from earlier turns into the next request (reasoning.context set to all_turns), where every prior generation defaulted to current_turn.

Anthropic exposes exactly five documented effort levels — low, medium, high, xhigh, and max — and the parameter is not a bare effort field: the request shape is output_config.effort, distinct from the deprecated thinking budget-tokens mechanism used on pre-4.6/4.7 models. The default is high, one rung above OpenAI’s medium — worth knowing before you compare “default vs default” across the two APIs. Claude Sonnet 5 likewise defaults to high on both the Claude API and Claude Code.

Even within Anthropic’s own line, the ladder is not uniform: the docs note that xhigh is a newer level and that some models supporting max do not support xhigh. Per the same page, xhigh is available on six models (Fable 5, Mythos 5, Opus 5, Opus 4.8, Opus 4.7, and Sonnet 5) while max spans a broader nine-model list. A config that assumes xhigh exists everywhere will not survive contact with the older members of the family.

The sharper trap is the off switch. On Claude Opus 5, thinking cannot be disabled at the xhigh or max effort levels — a request that sets thinking to disabled at those levels returns a 400 error. That is a partial, tier-gated version of the blanket no-disable rules we will see at GLM, Grok, and Kimi: the pattern of top effort tiers forcing thinking on did not start in China; it already exists at Anthropic.

One more Anthropic-documented behavior earns its own section later: effort changes tool-calling behavior, not just verbosity. Lower effort levels tend to combine operations into fewer tool calls and proceed directly to action; higher levels may make more tool calls and explain the plan before acting. That is a billing mechanism, and section 09 prices it out.

Google’s parameter is thinking_level, set inside the generation config, and it explicitly varies by model rather than following one company-wide ladder — the thinking docs list the level set per model across eleven entries. Gemini models also engage in dynamic thinking by default, automatically adjusting reasoning effort to the request’s complexity; thinking_level is the override for that dynamic behavior, and the documented “On (medium)” default describes the dynamic starting point, not a fixed per-request budget.

The row worth staring at is the newest one. Gemini 3.7 Flash’s documented level set is exactly low, medium, and high — three rungs. Gemini 3.6 Flash, its immediate predecessor, still supports four: minimal, low, medium, and high. The newest Flash pruned the minimal rung its own prior generation still has — a regression in configurability against 3.6 Flash, and the second instance of the pattern OpenAI set when GPT-5.6 dropped minimal from GPT-5.5’s ladder. Two unrelated vendors trimmed the cheap bottom rung in their most recent releases.

Grok 4.6’s reasoning_effort ladder has four rungs — low, medium, high, and xhigh — defaulting to high, with no max tier documented anywhere on xAI’s reasoning page. Reasoning cannot be disabled on either Grok 4.6 or Grok 4.5. How xAI positioned that high default against rival ceilings in its launch benchmarks is a story of its own — we covered it in our read of the Grok 4.6 effort-tier comparison table — so here we stay with the operational surface.

The failure mode xAI chose for unsupported rungs is the quiet one. Grok 4.5 supports only three rungs — low, medium, and high — and per the docs, xhigh is available on grok-4.6 and later; on models that do not support it, such as grok-4.5, requests with xhigh are treated as high. No error, no warning: the request runs one rung below what you asked for. That is the opposite failure mode from GLM-5.3, which hard-fails invalid values — and the silent version is arguably more dangerous, because nothing tells you your “maximum effort” eval ran at high.

Cross-reference the vendor docs and a pattern emerges that no single vendor states: DeepSeek, Z.ai, and Moonshot — three separate Chinese frontier labs — have independently converged on an identical three-rung scheme: low, high, max, with no medium rung. Every US vendor we surveyed (OpenAI, Anthropic, Google, xAI, and Meta’s Muse Code) keeps medium as a core tier or default. If your routing layer assumes medium exists everywhere, it does not survive the Pacific crossing.

The bloc shares more than names. GLM-5.3 and Kimi K3 both default to max — the top of the ladder — where every US vendor defaults to a middle or upper-middle rung. And two of the three ship blanket no-disable rules: Kimi K3’s thinking is always on, and GLM-5.3’s own migration note is unambiguous — disabling thinking is no longer supported, and a request that sends thinking type disabled fails outright. Z.ai's prescribed migration path is to switch the value to enabled and set reasoning_effort to low before updating the model ID to glm-5.3; otherwise the request errors. We covered the model itself in our GLM-5.3 launch analysis.

One aggregator-layer caution for the DeepSeek row: listings on OpenRouter surface an “xhigh” label for these models, but that is OpenRouter’s own effort-naming layer, not a DeepSeek term — DeepSeek’s documentation describes low, high, and max only, for both V4-Pro and V4-Flash. When a middleman renames the rungs, the vendor's docs are the ladder; the aggregator's labels are a translation.

Meta’s Muse Code CLI documents the widest ladder of any surface we checked: --reasoning-effort accepts seven named values — none, minimal, low, medium, high, xhigh, and ultra — changeable mid-session, with the default at xhigh, not high. But two of those seven values do not do what the ladder metaphor implies.

The docs state it plainly: Muse Code doesn’t support none in practice, and ultra is a client-side setting. Set ultra and Muse Code clamps the actual model request to xhigh — ultra doesn’t add deeper per-call model reasoning. What it changes is how aggressively the CLI delegates to multi-agent workflows on the client, which can raise token usage. So the top rung of the widest ladder in the survey is not a reasoning depth at all; it is a parallelism dial wearing an effort costume.

That makes at least two primary-sourced cases of vendors overloading effort-adjacent naming to mean “more parallel agents” rather than “deeper single-model reasoning” — Muse Code’s ultra and the grok-4.20-multi-agent docs entry from section 05, where the same parameter name selects an agent count. The operational lesson: an effort value is not portable even within a single vendor's model line until you have read what that value does on that model.

Model migrations used to be about prompts and tool schemas. The effort layer now adds four distinct failure classes — and they fail differently, from silent quality drift to hard 4xx errors. Any team routing requests across models and effort tiers should be able to name all four.

Effort moves spend through two documented mechanisms — and knowing them matters more than any multiplier, because both scale with your workload, not with a fixed ratio.

Mechanism one: thinking tokens. On GPT-5.6, reasoning tokens are billed as output tokens — the most expensive token class — and occupy context-window space even though they are invisible in the response; the count is reported in usage.output_tokens_details.reasoning_tokens. Raise the effort rung and you raise how much of that class the model produces per request. GPT-5.6’s all_turns default compounds this: prior-turn reasoning is carried into each new request unless you opt out, so the same thinking can occupy billable context repeatedly across a conversation.

Mechanism two: tool-call turns. Anthropic documents that effort changes agent behavior, not just verbosity: lower effort levels tend to combine multiple operations into fewer tool calls and proceed directly to action, while higher levels may make more tool calls and explain the plan before acting. In an agentic loop, every additional tool call is a full extra round-trip of input and output tokens. Effort therefore multiplies with loop length — the rung you pick sets how many turns the loop runs, and each turn re-sends context.

A third, CLI-specific channel: Muse Code’s ultra can raise token usage precisely because it delegates to multi-agent workflows on the client. And on subscription surfaces, when you run can matter alongside how hard: Z.ai’s GLM Coding Plan meters usage in points and charges half the standard point cost outside peak hours, with peak defined narrowly as Monday to Friday, 14:00–18:00 UTC+8 — every other hour, weekends included, gets the off-peak rate. Time-based pricing is spreading across vendors this month; our off-peak pricing breakdown covers the schedules in detail.

What this post deliberately does not give you is a table of “low costs X% of high” figures — spend per rung depends on task shape, loop length, and context size, and any fixed multiplier would be an invention. For measured cost-versus-quality curves across effort tiers, see our reasoning-effort benchmark study — the performance-numbers companion to this reference.