Seventeen of the eighteen surfaces in this table name their reasoning-effort rungs. The eighteenth, DeepSeek’s native API, ships a boolean thinking switch and no named rung at all. The named ladders rarely line up: across these rows, vendors differ on the names, the count, the default or the position of high
, though Z.ai’s GLM-5.3, Moonshot’s Kimi K3 API and the stealth/ox-alpha
listing all land on the same three rung names, the same default and the same position for high
. This page is the table: for 18 numbered surfaces, the rung names, each read from a vendor page, from the installed binary’s own output, from a dated live check in this kit’s CLI notes, or, for the one stealth listing, from OpenRouter’s models-API record; the rung count; the default; and whether reasoning can be disabled at all. Data as of August 22, 2026.
The same word does different work on different rows. high
is the third of five rungs on Anthropic’s current ladder and the third of four on its previous one, the fifth of seven values Codex’s backend enumerates, the ceiling on Gemini 3.7 Flash, and the middle of three on GLM-5.3 and Kimi K3. Three vendors ship no medium
rung. One ships no effort rung at all. Eight table lines document reasoning as something you cannot switch off. None of that is visible from any single vendor’s page, which is the reason to keep one dated table.
This is a control-surface reference, not a performance study. It records what the parameter accepts and what it defaults to, and deliberately records nothing about what each rung costs or scores. The narrative companion is our cross-vendor field guide to reasoning effort ladders; the cost and quality side is in our effort-versus-quality benchmark read. This page contrasts with both rather than repeating them, and it corrects one claim we have published ourselves.
- 0118 numbered rows, 19 table lines, CLI and API kept apart.Row 18 is split into the stealth/ox-alpha listing record (18a) and OpenRouter’s generic reasoning parameter (18b). CLI and API surfaces sit on separate rows because they differ: Kimi’s OpenPlatform API defaults to max while the Kimi Code CLI defaults to high.
- 02Codex’s backend enumerates seven values; high is fifth of seven.A live probe of Codex CLI 0.149.0 with an invalid model_reasoning_effort returned the backend’s own list: none, minimal, low, medium, high, xhigh, max. The CLI also accepts ultra, which that list does not carry. The older six-rung, high-is-fourth framing, including our own, is retired.
- 03Three vendors ship no medium rung.GLM-5.3 (low, high, max), Kimi K3 (low, high, max) and the stealth/ox-alpha record (max, high, low) all skip medium. One of the two sourced readings for Qwen3.8-max-preview skips it too; the other skips high instead, and the table records both.
- 04Eight lines document reasoning as always-on; one surface has no rungs at all.Grok 4.6 (API and CLI), GLM-5.3 (API and via Claude Code), Kimi K3 (API and CLI), Qwen3.8-max-preview and Ox Alpha all document that reasoning cannot be disabled. Gemini 3.7 Flash and agy document no off state. DeepSeek V4’s native API exposes a boolean only, zero named rungs.
- 05Three cells stay open, on purpose.Qwen’s rung names differ between QwenCloud’s docs and our own live CLI check, and both readings are printed. Muse Code’s default differs between a live --help and our published guide; the live value is used and the discrepancy is stated. Codex’s ultra is the third kind of open cell: not a conflict between sources but an absence, since nothing fetched documents its wire-level treatment.
01 — ScopeWhat a rung is, and why CLI and API get separate rows. #
A rung, for this table, is one named value a vendor accepts on its reasoning-effort control: reasoning.effort
on the OpenAI Responses API, output_config.effort
on the Anthropic Messages API, thinking_level
on the Gemini API, reasoning_effort
at xAI, Z.ai, Moonshot and QwenCloud, and whatever flag the CLI in front of each of those models exposes. Integer token budgets (Gemini’s older thinking_budget
, Anthropic’s budget_tokens
, OpenRouter’s reasoning.max_tokens
) are recorded where they interact with the named rungs but are not counted as rungs.
CLI and API surfaces sit on separate rows wherever the kit drives both, because the cells differ in ways a merged row would hide. Kimi Code’s managed CLI defaults to high
while Moonshot’s OpenPlatform API defaults to max
. Codex CLI accepts a value the backend’s own enumeration does not list. The Antigravity CLI encodes effort as a model-id suffix as well as a flag. Where a CLI simply passes a flag through (GLM-5.3 via Claude Code), the row says so and records the operational default separately from the vendor default.
Two things are recorded per row that most vendor pages leave implicit: the ordinal position of the word high
, counted from the lowest rung upward regardless of the order the vendor prints the list, and whether a disabled state exists at all. The first matters because a routing rule written as “use high” means five different things across this table. The second matters because a migration that relied on turning thinking off now fails outright on at least one vendor.
Rung names, verbatim and in order
The exact spelling and order the vendor lists, including values a CLI accepts that the backend does not enumerate, and values a vendor lists that its own CLI does not support in practice. Each such note is attributed in its own cell to the source it rests on, including where that source is a post of ours. Nothing is normalised across rows.
Default, high position, off state, flag
The vendor default (and, where the kit overrides it, the operational default labelled as a choice), the ordinal of the word high counted from the bottom, whether reasoning can be disabled, and the parameter or flag name.
Cost, scores, consumer toggles, legacy models
No benchmark or price figures tied to rungs, no ChatGPT or Claude.ai UI dials, no OpenAI o-series, and deprecated variants only where they explain a generational change such as Grok 4.5 to 4.6 adding xhigh.
02 — MethodologyA method a stranger could redo, stating what was read and what was not. #
Four kinds of evidence feed the table, and each row says which one it rests on. The highest-confidence source is the installed binary’s own output: a deliberately invalid value sent to Codex CLI to force the backend’s validation error, and Muse Code’s own help text. Next are this kit’s dated CLI reference notes, each built from a live check against the installed tool on the date shown. Then the vendors’ current documentation pages. Last, for the single stealth listing, is the stealth/ox-alpha
record from OpenRouter’s models API, taken from this batch’s verified anchors rather than re-pulled for this table. Nothing in the rung-name column is reconstructed from memory or pattern-matched from a sibling model.
What was collected. For every coding-agent CLI and model API this kit actively drives, plus the two vendors this batch’s verified anchors flagged (the stealth/ox-alpha
listing and GLM-5.3) and OpenRouter’s own generic reasoning parameter, the reasoning-effort control surface: parameter or flag name, the full ordered list of accepted values verbatim, the default, whether reasoning can be disabled, and the ordinal position of the word high
counted from the lowest rung. Data as of August 22, 2026. 18 numbered rows; row 18 is split into 18a and 18b, giving 19 table lines.
Sources, in order of preference. (1) Read from the binary: Codex CLI 0.149.0, probed with an invalid model_reasoning_effort
so the backend returned its own enumeration, then none
, max
and ultra
tested as live values against gpt-5.6-sol
; Muse Code 0.2.1, whose --help
prints the value list and default inline. (2) Read from this kit’s dated CLI notes, each a live check against the installed tool: Grok CLI and Antigravity agy
(2026-08-17), GLM via Z.ai (2026-08-17), DeepSeek V4 (2026-08-17), Kimi Code v0.29.1 (2026-07-26), Qwen Code v0.21.0 (2026-07-26). (3) Read from current vendor documentation: the Anthropic effort and Claude Code model-config pages, the OpenAI reasoning guide, the Gemini thinking guide, the xAI reasoning page, the GLM-5.3 launch post (dated 2026-08-14), the Kimi K3 quickstart, the QwenCloud thinking guide, and the OpenRouter reasoning-tokens guide. (4) The stealth/ox-alpha
record from OpenRouter’s models API, taken from this batch’s verified anchors rather than re-pulled for this table: pulled there 2026-08-22 and confirmed the same day by two separate pulls.
Read versus inferred. Every rung name is read. Two cells carry a conflict between two sourced readings: Qwen3.8’s rung names, tagged unresolved and printed both ways, and Muse Code’s default, where the live binary is used and the disagreeing source is named in the cell. A third is marked undocumented rather than conflicted (Codex ultra
on the wire). DeepSeek V4’s row is a checked absence: the native API documentation was searched for an effort enum and none was found. Our previously published cross-vendor guide was read for cross-checking rather than used as a primary source, with one stated exception: row 17’s note that Muse Code’s none
value is listed but unsupported in practice rests on that guide’s footnote, which itself attributes the point to Muse Code’s own documentation as checked on 2026-08-14. That vendor page was not re-fetched for this table, and the cell says so.
Excluded, and why. Consumer UI dials (covered in our consumer effort-dials explainer); cost or score figures tied to rungs; OpenAI’s o-series; and deprecated variants except where they explain a generational change.
Known limitations. (a) The exact backend treatment of Codex’s ultra
is not documented anywhere fetched: the CLI accepts it and the request completes, but the value sent on the wire is unconfirmed. (b) Qwen3.8-max-preview’s three rung names could not be reconciled between QwenCloud’s documentation and this kit’s own live check; both are recorded. (c) Muse Code’s default differs between the live binary and our own guide, published on August 15 and checked by its authors on August 14, eight days before this dataset’s as-of date; the live value is used here and the discrepancy is stated. (d) Vendor pages carry no per-page revision dates; they are cited as current documentation, and the as-of date is the dataset’s, not a guarantee that each page was unchanged on that day.
03 — The DatasetThe complete table: 18 rows, 19 lines, nine columns. #
The table is the asset; no row is summarised away. Rung names are printed in the order the vendor lists them, so OpenRouter’s two lines read top-down where Anthropic’s read bottom-up; the high position column always counts from the lowest rung. Each surface cell carries its primary source and the date that source itself states, or “current documentation” where the page shows none. Cells marked unresolved show both sourced readings. Data as of August 22, 2026.
| # | Surface (vendor) · primary source | Model(s) | Rung names, verbatim, vendor order | Rungs | Default | High position | Reasoning off? | Flag / parameter |
|---|---|---|---|---|---|---|---|---|
| Rows 1–4 · Anthropic | ||||||||
| 1 | Claude Code CLI (Anthropic) | |||||||
low, medium, high, xhigh, max
. The ultracode
meta-mode sends xhigh
plus workflow orchestration and is not itself a rung.high
(Opus 4.7 alone defaults to xhigh
)xhigh
or max
.--effort <level>
/ /effort
code.claude.com/docs/en/model-configcurrent documentation
low, medium, high, max
(no xhigh
)high
`--effort <level>`
[platform.claude.com/docs/en/build-with-claude/effort](https://platform.claude.com/docs/en/build-with-claude/effort)current documentation
low, medium, high, xhigh, max
high
; the docs state that setting high
behaves exactly as omitting the parameterthinking: {type: disabled}
returns a 400 at xhigh
or max
, so it cannot be fully disabled at those two levelsoutput_config.effort
platform.claude.com/docs/en/build-with-claude/effortcurrent documentation
low, medium, high, max
(no xhigh
)high
effort
; it works alongside budget_tokens
output_config.effort
codex exec -c model_reasoning_effort="bogus"
[github.com/openai/codex · rust-v0.149.0 (2026-08-20)](https://github.com/openai/codex/releases/tag/rust-v0.149.0)Corrected row
`gpt-5.6-sol`
(and other configured models)none, minimal, low, medium, high, xhigh, max
. The CLI additionally accepts ultra
(banner prints reasoning effort: ultra
, request succeeds), which the backend list does not carry; its wire-level treatment is undocumented.high
in this kit’s ~/.codex/config.toml
; OpenAI states no CLI-level default beyond the API’s ownnone
is backend-accepted and completed as a live value; disable semantics follow the API’s model-dependent rule (row 6)model_reasoning_effort
in ~/.codex/config.toml
, or -c model_reasoning_effort="…"
developers.openai.com/api/docs/guides/reasoningcurrent documentation
none, minimal, low, medium, high, xhigh, max
; the docs state support is model-dependent and to check the relevant model page before choosing a settingmedium
for GPT-5.5 and GPT-5.6 per the docs, subject to the same model-dependent caveatnone
where the model supports itreasoning.effort
ai.google.dev/gemini-api/docs/thinkingcurrent documentation
low, medium, high
medium
(the model “starts at medium”; described as dynamic)thinking_level
(replaces the older thinking_budget
integer)agy
(Google)this kit’s antigravity-cli notes · verified live 2026-08-17 against agy 1.1.x`claude-sonnet-4-6`
, `claude-opus-4-6-thinking`
, `gpt-oss-120b-medium`
)low, medium, high
; also encoded in the model id via a suffix, e.g. gemini-3.7-flash-high
high
via the -high
model-id suffix: an operator choice, not a vendor defaulthigh
is the top of Flash’s dial, not a mid-tier--effort low|medium|high
or the -high
/ -low
model-id suffix (the two overlap; pick one)docs.x.ai/developers/model-capabilities/text/reasoningcurrent documentation
low, medium, high, xhigh
high
reasoning_effort
grok
(xAI)this kit’s grok-cli notes · verified live 2026-08-17low, medium, high, xhigh
high
; xhigh
is the ceiling, not the default`--reasoning-effort`
(alias `--effort`
); persisted as `[models] default_reasoning_effort`
in config.toml
z.ai/blog/glm-5.3launch post · 2026-08-14
low, high, max
(no medium
)max
thinking.type
accepts only enabled
; disabled
“is no longer supported” and a request still sending it failsreasoning_effort
thinking.type
low, high, max
on Z.ai’s side; Claude Code’s --effort
is passed throughmax
; this kit’s operational default is high
, a deliberate choice rather than a vendor default--effort
, proxied to Z.ai’s reasoning_effort
platform.kimi.ai/docs/guide/kimi-k3-quickstartcurrent documentation
low, high, max
(no medium
)max
reasoning_effort
budgets depth without turning it offreasoning_effort
(top-level request field)`kimi`
, managed service (Moonshot AI)this kit’s kimi-code notes · live v0.29.1 · 2026-07-26`kimi-code/k3`
low, high, max
; the same three names as the OpenPlatform APIhigh
: the managed CLI service’s own default, differing from the OpenPlatform API’s max
; not a fleet-imposed choicealways_thinking
flag is set on all four Kimi-served models in this kitdefault_effort
in ~/.kimi-code/config.toml
; the TUI status bar shows e.g. K3 thinking: high
docs.qwencloud.com/developer-guides/text-generation/thinkingcurrent documentation · vs this kit’s qwen-code notes, live v0.21.0, 2026-07-26Unresolved · both readings shown
low, medium, xhigh
(no high
). This kit’s live CLI check: low, high, xhigh
(no medium
). The two sourced readings conflict; neither is preferred here.xhigh
(both sources agree)high
. Kit reading: 2nd of 3.temperature
also floors at 0.6 on this model.reasoning_effort
(errors if sent together with thinking_budget
)[api-docs.deepseek.com · reasoning-model guidance](https://api-docs.deepseek.com/)checked absence · plus this kit’s deepseek-v4 notes, verified live 2026-08-17
`deepseek-v4-flash`
, `deepseek-v4-pro`
effort
or reasoning_effort
field was found in the native reasoning-model guidance; the native control is a boolean thinking on/off./anthropic
), Claude Code’s output_config.effort
on the five-rung scale of row 3 is honored end-to-end.output_config.effort
when accessed via /anthropic
muse
(Meta)live probe of the installed binary: `muse --help`
/ `muse exec --help`
· Muse Code 0.2.1 (0.2.1-R1215.1)Default differs from our guidenone, minimal, low, medium, high, xhigh, ultra
, the widest CLI ladder in this tablehigh
: both help screens print (default: high)
. Our own cross-vendor guide, checked 2026-08-14, states xhigh
; the live value is used here and the guide is flagged for correction.none
is listed in the value set but not supported in practice. That note rests on a footnote in our own cross-vendor guide, which attributes it to Muse Code’s documentation as checked 2026-08-14; the vendor page was not re-fetched for this table. ultra
is client-side multi-agent delegation clamped to xhigh
at the model call--reasoning-effort <EFFORT>
openrouter.ai/api/v1/models · stealth/ox-alpha recordvia this batch’s verified anchors · pulled 2026-08-22 · confirmed twice that day
stealth/ox-alpha
max, high, low
as listed in reasoning.supported_efforts
(no medium
)max
(reasoning.default_effort
)reasoning.mandatory: true
reasoning
/ reasoning_effort
(OpenRouter’s generic params, restricted to these three values)openrouter.ai/docs/guides/best-practices/reasoning-tokenscurrent documentation
max, xhigh, high, medium, low, minimal, none
as listed"enabled": true
maps to medium
.none
is in the enum but only takes effect where the underlying model supports a full disable. On ~latest
slugs, unsupported values are silently remapped.reasoning.effort
(or reasoning.max_tokens
as a token-budget alternative; reasoning.exclude
hides reasoning tokens)Two conventions to read the table by. First, the rung column prints each list in the vendor’s own order: Anthropic and OpenAI print bottom-up, OpenRouter prints top-down, and the stealth/ox-alpha
record lists max, high, low
. The high-position column normalises that by always counting from the lowest rung, which is why 18b reads “5th of 7” even though high
is the third item printed. Second, where a default is an operator’s choice rather than a vendor’s (rows 5, 8, 10 and 12), the cell says so; those cells are about this kit’s configuration, and a different installation may differ.
04 — Rung CountsWho has the widest dial, from the Rungs column. #
Rung count is the one column that compares as a magnitude across rows, so it is the one column charted. Four lines reach seven values: the Codex backend enumeration, the OpenAI Responses API superset, Muse Code, and OpenRouter’s generic parameter. Eight lines stop at three. One line, DeepSeek V4’s native API, has no named rung at all. The high-position column is deliberately not charted: a “3rd of 4” bar beside a “5th of 7” bar would imply a comparison that is not real.
The shape is two clusters with a gap. Seven-value ladders belong to OpenAI’s surfaces, Meta’s CLI and the aggregator; three-value ladders belong to Google and every Chinese lab in the table. The four-rung group in between is xAI plus Anthropic’s previous generation. One pattern the chart cannot show is that the three-rung ladders are not the same three rungs: Google’s is low, medium, high
, while Z.ai, Moonshot and the stealth listing are low, high, max
, which is why a request carrying medium
ports cleanly to one group and not the other.
05 — CorrectionCodex: seven backend values, and one the backend does not list. #
Row 5 is a correction, and the correction is a finding. Our own routing notes describe Codex’s effort ladder as six rungs with high
in fourth place, against a printed list of low, medium, high, xhigh, max, ultra
. That list puts high
third, not fourth; the arithmetic only works if minimal
is counted as the first rung and ultra
is dropped. Separately, the cross-vendor guide we published on August 15 describes the GPT-5.6 family as documenting a six-value set with no minimal
rung, on which high
is also fourth. Rather than pick a reading, the installed binary was asked directly.
Sending Codex CLI 0.149.0 a deliberately invalid model_reasoning_effort
against gpt-5.6-sol
made the backend return its own validation error, which enumerates the accepted set. It is seven values, it starts at none
, and it ends at max
:
"Supported values are: 'none', 'minimal', 'low', 'medium', 'high', 'xhigh', and 'max'."— Codex CLI 0.149.0, backend validation error returned to a live probe with an invalid model_reasoning_effort
Counted from none
, high
is the fifth of seven, and the enumeration returned for gpt-5.6-sol
does include minimal
. ultra
is not in that list, yet the CLI accepts it: the session banner prints reasoning effort: ultra
and the request completes. The 0.149.0 release notes, linked in row 5, say the SDK now selects max
or ultra
without describing the internals, and a pre-0.149.0 issue in the Codex repository’s tracker (#30585) describes a bug in which ultra
was rejected server-side after being translated to max
. That issue is carried from this kit’s own research notes rather than re-fetched for this table, and it is not one of the twelve sources linked in the rows above. Nothing fetched for this table confirms what value reaches the API today, so the row records ultra
as CLI-observed behaviour with an undocumented wire treatment, not as a documented contract.
The practical consequence for anyone who wrote a routing rule around “Codex high is the fourth of six” is that the rule was reasoning about the wrong ladder. On the backend’s own enumeration high
sits fifth of seven: four values below it rather than the three that framing implies, with the same two, xhigh
and max
, above it. Our GPT-5.2 to 5.5 migration playbook covers how the API-side defaults moved across generations; this row is about what the CLI in front of the API will accept today.
none through max
The accepted set as enumerated by the backend’s own validation error for gpt-5.6-sol. This is the list the high-position column counts against: high is fifth.
counting ultra
The CLI accepts ultra, prints it in the session banner and completes the request, but the backend’s enumeration does not list it. What is sent on the wire is undocumented in anything fetched.
the list that did not add up
Six rungs with high fourth only works by counting minimal as rung one and dropping ultra. Our own routing notes carried it, and our August 15 guide lists a six-value GPT-5.6 set without minimal; the live enumeration for gpt-5.6-sol includes minimal. This table retires the six-rung framing.
06 — Disable ColumnWhere thinking cannot be turned off. #
Eight of the nineteen lines document reasoning as something the caller cannot disable: the xAI API and Grok CLI on Grok 4.6, the Z.ai API and the GLM-via-Claude-Code route on GLM-5.3, the Kimi K3 API and Kimi Code CLI, Qwen3.8-max-preview on both sourced readings, and the stealth/ox-alpha
record with reasoning.mandatory: true
. Two more, Gemini 3.7 Flash and the Antigravity CLI, document no disabled state at all, which is recorded as an absence rather than a prohibition. Anthropic’s Opus 5 sits between: thinking can be disabled, except at xhigh
and max
, where the request returns a 400.
GLM-5.3 is the row where this changed within the month, and the vendor’s own launch post states both halves in one breath. The migration consequence is concrete: an application that sends thinking.type: "disabled"
to GLM-5.3 fails outright, and the documented floor is thinking.type: "enabled"
with reasoning_effort: "low"
. The launch itself is covered in our GLM-5.3 API post; the table only records the control surface.
low
, high
, and max
. Disabling thinking is no longer supported by GLM-5.3.”Published 2026-08-14. The same page’s parameter table lists reasoning_effort
values low, high, max
with default max
, and records thinking.type
as accepting only enabled
.xAI’s page is equally short: its reasoning documentation states “Reasoning cannot be disabled.” for both Grok 4.5 and 4.6, and the Grok CLI inherits that. Moonshot’s K3 quickstart describes thinking as always enabled, with reasoning_effort
budgeting depth rather than switching it off; the Kimi Code CLI carries an always_thinking
flag on every Kimi-served model in this kit. The under-used consequences of that always-on design are in our Kimi K3 capabilities read.
effort: none
, enabled: false
, max_tokens: 0
) being silently remappedto the nearest supported level on
~latest
model slugs, where a concrete pinned slug returns a strict 400 for the same input. A caller who explicitly disabled reasoning on a ~latest
slug can keep receiving 200-status responses with reasoning silently re-enabled after the upstream model is repointed. Row 18b records the enum; this is the behaviour around it.## 07 — Open CellsThree cells left open: two source conflicts and one gap.
A reference table that resolves every conflict silently is less useful than one that shows its conflicts, because the conflicts are where a reader’s own check is most likely to land. Three cells could not be closed from the sources available, and they are not the same kind of open. Two are conflicts between two sourced readings: Qwen’s rung names, printed with both readings and no pick, and Muse Code’s default, where the live binary is used and the disagreeing source is named. The third is an absence rather than a disagreement: nothing fetched documents what Codex sends on the wire for ultra
. One of the three is a discrepancy with a post we published ourselves.
Two sourced readings of the same three rungs
QwenCloud’s thinking guide lists low, medium, xhigh with no high rung. This kit’s own live check of Qwen Code v0.21.0 on 2026-07-26 recorded low, high, xhigh with no medium. Both sources agree the default is xhigh and that thinking is always on. The names are not reconciled; a fresh CLI check is the way to close it.
Live binary says high; our guide says xhigh
Both muse --help and muse exec --help on Muse Code 0.2.1 print the default inline as high. Our cross-vendor guide, checked 2026-08-14, states xhigh. Either Meta changed the default between the two checks or one check was wrong; the table uses the live value and the guide is flagged for a correction pass rather than edited silently.
Accepted by the CLI, absent from the backend list
The CLI accepts ultra and the request completes, but the backend’s own enumeration stops at max and nothing fetched documents what value is transmitted. The 0.149.0 release notes mention SDK selection of max or ultra without internals; an earlier issue in the Codex tracker (#30585) describes ultra being translated to max and then rejected. This cell is open for lack of documentation, not because two sources disagree. Recorded as observed behaviour, not a contract.
08 — Reading The TableThe word high is five different positions. #
The most portable-looking value in the table is the least portable. Across the nineteen lines, high
is the third of five on Anthropic’s current ladder and the third of four on the previous one; the fifth of seven on the Codex backend list, the OpenAI Responses superset, Muse Code and OpenRouter’s generic parameter; the ceiling on Gemini 3.7 Flash and the Antigravity CLI; and the middle rung of three on GLM-5.3, Kimi K3 and the stealth listing. On one reading of Qwen3.8-max-preview there is no rung named high
at all.
Two rungs above, two below
Claude Code and the Messages API on the 5-series. Anthropic’s docs state that setting high behaves exactly as omitting the parameter, so high is also the unstated default.
One rung above, two below
Claude Code and the Messages API on Opus 4.6 and Sonnet 4.6, and the xAI Grok API and Grok CLI on Grok 4.6. Both ladders carry exactly one rung above high, but not the same one: max on Anthropic’s 4.x line, xhigh on xAI’s. A rule that reaches for “one above high” has to know which.
Two rungs above, four below
The Codex backend enumeration, the OpenAI Responses superset, Muse Code and OpenRouter’s generic enum all place high fifth when counted from the bottom. On the OpenAI API the count drops where a model exposes fewer values.
The ceiling, not a mid-tier
Gemini 3.7 Flash and agy stop at high. A routing rule that treats high as a moderate setting sends Flash its maximum intensity; there is no max or xhigh above it on this surface.
The middle, with max above it
GLM-5.3, Kimi K3 and stealth/ox-alpha all skip medium, so high is the middle rung and max the top. Three of these lines default to max (the Z.ai API, the Kimi K3 OpenPlatform API and Ox Alpha); the Kimi Code CLI defaults to high while its own API defaults to max, and this kit runs the GLM-via-Claude-Code route at high by choice rather than at Z.ai’s max.
The table is meant to be used, not read. Two ways it earns its place in a routing configuration: as the lookup that turns a portable intent such as “one rung below the ceiling” into the right literal per surface, and as the diff to re-run when a vendor ships a generation change, since rows 1 and 2 show Anthropic adding xhigh
between generations and rows 9 and 10 inherit xAI’s addition of xhigh
from Grok 4.5 to 4.6. Our four-model effort-tier comparison works through one such mapping across Grok 4.6, GPT-5.6 Sol, Opus 5 and Fable 5. Teams standardising reasoning configuration across several vendors can also draw on our AI transformation work, which is where this table started. This dataset is maintained in place on a stable URL. When a cell changes on re-check, the as-of date moves with it and the change is recorded rather than overwritten; the three open cells above are the first candidates for the next refresh.
09 — ConclusionOne dated table beats nineteen vendor pages. #
Effort ladders share a vocabulary and almost nothing else.
Nineteen lines, eighteen numbered rows, and the same handful of words reused with different meanings. high
is a third, a fifth, a second or a ceiling depending on the row. medium
exists on some three-rung ladders and not on others. none
appears on four lists: backend-accepted and live-tested on Codex, honoured model-dependently on the OpenAI Responses API and on OpenRouter’s generic parameter, and listed but unsupported in practice on Muse Code. The only safe way to carry an effort setting between vendors is to look it up, which is what this table is for.
The two findings that did not exist before the table was built are both corrections. Codex’s backend enumerates seven values with high
fifth, and accepts an eighth the enumeration does not list; the six-rung framing in our own routing notes is retired here, and our published guide’s GPT-5.6 list without minimal
is contradicted by the live enumeration. Muse Code’s installed binary reports a default of high
where our guide said xhigh
. Both are stated, neither is hidden, and the guide will be corrected rather than quietly overwritten.
The direction of travel is visible in the disable column. Within the month, one vendor removed the off switch entirely, and eight of nineteen lines now document reasoning as mandatory. If that continues, the next refresh of this table will record fewer none
rungs and more mandatory flags, and a migration that relied on turning thinking off will need the lowest rung instead. The as-of date is there so that reading can be checked.