Effort Ladders for Every AI CLI and API: The Reference Table

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.

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.

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.

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.

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.

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.

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:

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.

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.

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.

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.

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.

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.