The Thinking Dial

On Artificial Analysis's measurements, Claude Opus 5.5 at max effort took a median of more than nine minutes before its first visible word. At low it took five seconds. Same model, same weights, same price per token, one setting apart.

That setting is the thinking dial: effort in Claude Code, reasoning effort in Codex, a thinking switch on many local models. Turning it up can make an agent more capable, more expensive, slower, or worse at the task. The useful question is whether the extra computation buys a better finished result. This is the guide I wanted when I set mine.

What reasoning actually is

Reasoning is not a second brain. It is the same model writing more before it answers.

The idea started as a prompt. In 2022 Wei et al. showed that a chain of thought, "a series of intermediate reasoning steps", made large models better at multi-step problems. Kojima et al. showed that models are "decent zero-shot reasoners by simply adding "Let's think step by step" before each answer". On one model that took MultiArith "from 17.7% to 78.7%".

Reasoning models train the habit in. OpenAI's o1 post in September 2024: "Our large-scale reinforcement learning algorithm teaches the model how to think productively using its chain of thought in a highly data-efficient training process." DeepSeek-R1 showed the recipe in the open: reinforcement learning with rule-based rewards (is the answer right, is the format right, do the tests pass) applied to a base model. People call it reinforcement learning with verifiable rewards. A passing test is a checkable signal. It does not certify that every sentence of the reasoning is right.

In the peer-reviewed Nature version, R1-Zero's AIME 2024 pass@1 rose "from an initial value of 15.6% to 77.9%", and the model "exhibits a steady increase in thinking time throughout training". It even learned to stop and write "wait", the paper's "aha moment".

That story needs restraint. DeepSeek's January 2026 revision says it raised the generation cap from 32,768 to 65,536 tokens at step 8,200, and that as a result both performance and response length jumped there. Liu et al. found that "DeepSeek-V3-Base already exhibit ''Aha moment''". And Yue et al. found that "the current training setup does not elicit fundamentally new reasoning patterns": RL-trained models win at small k, but "the base models achieve a higher pass@k score when k is large".

What the model writes, Anthropic's thinking docs describe plainly: it "restates what is being asked, tries approaches, checks intermediate results, and abandons paths that do not hold up."

Why does writing help? A transformer runs a fixed number of layers per token. Writing tokens and reading them back chains many such passes. Li et al. (ICLR 2024) put it formally: chain of thought "empowers the model with the ability to perform inherently serial computation, which is otherwise lacking in transformers, especially when depth is low." That is an expressivity result. It doesn't prove a deployed model spends its tokens well. But it is the core of it: thinking buys serial steps. Same weights, more steps.

Those steps are real output. Both vendors bill reasoning tokens as output tokens, they count against your output cap, and in agent loops they take up context.

The curve has a log axis

OpenAI's o1 post is where the industry got its favorite chart: "the performance of o1 consistently improves with more reinforcement learning (train-time compute) and with more time spent thinking (test-time compute)." Look at the x-axis. It is compute on a log scale, and the post gives no absolute values.

Anthropic said the same thing in words about Claude 3.7 Sonnet in February 2025: its accuracy on math questions "improves logarithmically with the number of “thinking tokens” that it’s allowed to sample." Read literally, for that model on those questions, each doubling of thinking bought about the same gain as the one before: equal steps in accuracy took multiplying amounts of thinking. Today's numbers are less kind. On the Artificial Analysis index below, Opus 5.5 wrote 20, 38, 53, 100 and 260 million output tokens from low to max, and each doubling bought fewer points than the one before.

There are four ways to spend more compute on one problem:

Snell et al. found that spending test-time compute well can beat raw size: in a FLOPs-matched test, on problems a smaller model can sometimes solve, "test-time compute can be used to outperform a 14x larger model." Brown et al. showed why selection matters: getting a correct answer somewhere in a pile of samples is not the same as reliably picking it.

Product labels blur these. OpenAI described GPT-5 pro as using "scaled but efficient parallel test-time compute", and its 2026 API keeps reasoning.mode: "pro" separate from effort: "Pro mode performs more model work than standard mode, increasing token usage and cost." Codex's Ultra adds delegation. Parallel compute pays most where answers can be checked automatically, and coding agents have tests. That is part of why running a task twice and keeping the version that passes is a strategy, not a superstition.

From budgets to a dial

In 2025 you gave Claude a thinking budget in tokens (budget_tokens). In 2026 that mode is "deprecated on the Claude 4.6 models", and "Claude 4.7 and later models do not support it and reject requests that use it, returning a 400 error." Thinking is now adaptive: "the model evaluates each request and determines whether to think and how much." You steer it with effort. On Opus 5.5 you can't switch thinking off at all: thinking: {"type": "disabled"} returns a 400 error.

OpenAI went the same way. Its reasoning.effort scale runs none, minimal, low, medium, high, xhigh and max, model by model, and "the models also reason adaptively across reasoning efforts, using fewer tokens for simpler tasks and thinking harder for complex tasks." Local models are converging too: Qwen3.8 added a reasoning_effort field (xhigh by default, medium, low), and llama.cpp's server documents --reasoning-effort and a real --reasoning-budget N.

The defaults differ by surface, and that alone explains many complaints that a model got dumber:

Anthropic says the Sonnet split out loud in its launch post: "In Claude Code and our apps, the default effort is set to Medium, while the Claude Platform defaults to High."

Four more details catch people.

ultrathink doesn't change the effort level. In current Claude Code it "adds an in-context instruction. The effort level sent to the API is unchanged." Phrases like "think hard" are plain text.

MAX_THINKING_TOKENS is not a modern dial. On adaptive-reasoning models Claude Code ignores a positive budget; use effort instead.

Ultracode and Ultra are orchestration, not just thinking. Claude Code's ultracode is "a Claude Code setting rather than a model effort level": it plans dynamic workflows at whatever effort the session runs at, and since version 2.1.284 it stays on at any level. Codex's Ultra "uses subagents to handle separate parts of a complex task in parallel." Both can raise usage through the extra orchestration and delegation.

One key doesn't set every path. In Codex, plan mode and spawned agents have their own effort keys, and an explicit spawn effort wins. In Claude Code, a skill's or subagent's effort frontmatter overrides the session level, but not the environment variable.

What the dial changes

People talk about the dial as a measure of how long the model thinks. The docs describe something broader. Anthropic's effort docs: "Effort is a behavioral signal, not a strict token budget." It "affects all tokens in the response", meaning text, tool calls and thinking. Here is everything I found that it moves.

1. How readily it thinks. Anthropic's steering docs: "At every level, Claude determines per request whether to think." At max it "thinks the most readily and at the greatest depth"; at low it "minimizes thinking". No level guarantees a thinking block on every request, and follow-up requests that only process tool results can skip thinking even at max.

2. How much it does. "Lower effort also means fewer and terser tool calls." Higher effort may "Make more tool calls", "Explain the plan before taking action", "Provide detailed summaries of changes" and "Include more comprehensive code comments". Anthropic's Claude Code effort guide says effort "controls how much work Claude does on your request overall including the number of files read, tools used, and how many steps it takes before it checks back in with you." Artificial Analysis measured it in its Coding Agent Index: Claude Code with Sonnet 5.5 averaged 18.6 turns per task at low and 265.9 at max. Codex with GPT-6.1 Sol barely moved, from 35.7 to 40.5 turns, while its output tokens grew about fourfold. Those rows change model and client together, so they don't isolate the cause. They do show that the same dial can show up very differently in different agents.

3. How much judgment it uses. From the Claude Code docs: "In tests on Opus 5.5 and Fable 5.1, Claude at a higher level tested more edge cases and verified more of its work before answering. It also made more choices on its own." At lower effort, Anthropic's guide says, Claude "would rather ask you for more context than spend tokens figuring something out on its own." OpenAI says the same about GPT-5: lower effort "reduces exploration depth"; higher effort increases "tool-calling persistence".

4. How much it writes. Effort touches visible text too, but not reliably. Anthropic notes that on Opus 5, "changing effort does not reliably shorten responses". OpenAI gives answer length its own knob, text.verbosity, which influences "the length of the model’s final answer, as opposed to the length of its thinking." If you want a short answer, ask for one.

5. Tokens and money. Thinking is billed as output, and output costs five times input on Opus 5.5 ($4 in, $20 out per million tokens), GPT-6 Astra ($10 and $50) and GPT-6.1 Sol ($2 and $10). Artificial Analysis needed 20 million output tokens to run its index on Opus 5.5 at low and 260 million at max. Both APIs report the hidden share: usage.output_tokens_details.thinking_tokens on Claude, usage.output_tokens_details.reasoning_tokens on OpenAI.

6. Time. On Artificial Analysis, Opus 5.5's median wait before the first word went from 5 seconds at low to 23 at medium, 34 at high, 111 at xhigh and 573 at max. That is not the time to fix your repository; it is how much computation can precede a short answer. Simon Willison ran Opus 5.5 at max on a simple drawing prompt twice; it hit the 128,000-token output limit while still reasoning, and "Those two failures each cost me $2.56 and took nearly 20 minutes."

7. Your usage window. Anthropic's Help Center: "Higher effort means more thorough responses, but they take longer and use more tokens, so you'll reach your usage limits faster." Codex once shipped the warning in its own interface: "⚠ High reasoning effort can quickly consume Plus plan rate limits." OpenAI's help center adds that higher effort "does not always produce a better result." Neither vendor publishes a multiplier for how much faster a level drains a plan, and API prices can't tell you how many subscription tasks you have left. Speed tiers are a separate dial again: Claude Code's fast mode bills usage credits, and Codex's Fast mode draws included limits at 2.5 times the standard rate.

8. Context and cache. Current Claude models keep earlier turns' thinking in context, where it is "billed as input tokens like the rest of the conversation history", and OpenAI's GPT-5.6 family renders earlier reasoning by default. More thinking per turn means a fuller window later. Changing the level can also cost you the prompt cache: on the Claude API, a top-level effort change "starts a new cache prefix", while a per-message effort change (in beta on current models) keeps it. Claude Code avoids the miss on Opus 5.5, Sonnet 5.5, Haiku 5.5 and Fable 5.1 with an API key or a Claude subscription ("changing effort keeps the cache"), and OpenAI's configuration_update changes effort mid-conversation "while preserving the cached prompt prefix", on GPT-6 models in standard single-agent runs.

9. Truncation. Thinking counts toward the output cap. OpenAI warns a capped response can end "before any visible output tokens are produced, meaning you could incur costs for input and reasoning tokens without receiving a visible response", and suggests reserving "at least 25,000 tokens". In Anthropic's own runs, Opus 5.5 with a 16,384-token cap per turn had 25% of attempts cut off; at 64,000, none were. And in a tool loop each request has its own cap, "so it doesn't bound the whole turn's spend."

10. How monitorable it is. A December 2025 study found that "for a model at a low reasoning effort, we could instead deploy a smaller model at a higher reasoning effort (thereby matching capabilities) and obtain a higher monitorability, albeit at a higher overall inference compute cost." In that study, effort changed monitorability as well as cost.

What each step buys

Independent numbers first. Artificial Analysis runs every effort level as its own entry. Opus 5.5 on its Intelligence Index, October 2026 (Artificial Analysis ran all five levels with Anthropic's default fallback enabled):

Max ranks first overall on that index, and it charges for it: from low to max, about 15 points for about 11 times the cost per task, 13 times the output tokens and about 50 times the median end-to-end response time. GPT-6 Astra goes from 45.8 to 52.7 for about four times the cost. For the top models the last step, xhigh to max, adds 1.6 points (Opus 5.5), 0.8 (GPT-6.1 Sol), 0.3 (GPT-6 Astra) and 0.2 (Fable 5.1). Smaller models gain more there: Sonnet 5.5 adds 4.1 and GPT-6 Luna 3.6. Calling max useless would misread this. Calling it the obvious default would ignore the price.

Sometimes max scores lower, though several of these gaps sit inside the noise:

• ARC-AGI-2, ARC Prize: Opus 5.5 scored 93.3% at high for $0.41 a task, 92.5% at xhigh and 91.7% at max for $1.85 on the Semi-Private set that ranks the leaderboard. That gap is 1.6 points on a 120-task set, about two tasks, and on ARC's public evaluation set the order reverses: 97.9% at max against 93.5% at high.
• AA Coding Agent Index: Haiku 5.5 in Claude Code scored 41.4 at xhigh and 36.5 at max. GPT-6.1 Sol in Codex scored 62.9 at xhigh and 60.1 at max. Sonnet 5.5 went the other way, 62.9 to 68.4, at more than four times the cost.
• Terminal-Bench 4.0, public leaderboard (its rows name the harness owner, not who ran them): Opus 5 in Claude Code scored 53.94 at xhigh and 51.82 at max, and GPT-6 Astra scored 57.88 at high, 57.88 at xhigh and 58.18 at max. The 95% half-widths run from about ±2.7 to ±3.4 points, so these figures alone don't establish a reliable difference at either last step.
• Vendor charts: in Anthropic's own Opus 5.5 launch, xhigh beats max on Terminal-Bench 4.0 (66.4% against 64.8%, inside Anthropic's stated ±2.6-point standard error), and medium edges out max on FrontierCode (54.6% against 54.4%) at about an eighth of the cost. In OpenAI's GPT-6.1 Sol launch charts, by my count, max was the single best setting in 9 of the 18 GPT-model curves (three models, six charts); GPT-6.1 Sol scored 75.2% on DeepSWE at high and 71.9% at max.

Where does higher effort pay? On smaller models and hard multi-step work. GPT-6 Luna went from 2.4% at low to 66.6% at max on DeepSWE in OpenAI's charts. And in one case more thinking cost less: on ARC-AGI-3 with ARC's standard harness, GPT-6 Astra scored 38.6% at medium for $48,090 in total and 62.7% at max for $26,098. ARC's explanation: "Higher reasoning levels generally cost less because Astra solves games in fewer actions, reducing the total number of model calls and tokens." Per-response savings are the wrong thing to optimize.

Anthropic's own sweep on its SWE-bench Pro subset (vendor numbers): Opus 5.5 solved 87.4% of tasks at low for $0.11 each, 92.8% at medium for $0.21, 95.3% at high for $0.29 and 96.7% at xhigh for $0.74 (a single run). Then the most useful result I found on this whole topic: "At low, 13% of tasks failed. With those re-run at high, the pass rate was slightly higher than with everything at high, for a little over half the cost." Anthropic's table puts that policy at about 97% of tasks solved for about $0.17 each, against 95.3% and $0.29 with everything at high. Two conditions come with it: you need a failure signal, here the benchmark's own tests, and "every first-pass failure takes two runs' worth of wall-clock time". Anthropic's own advice: "Use this policy for the saving, not the lift."

Practitioners land in the same place. In a 300-run test on six real merged changes, paddo.dev found: "On real work, the best Opus setting was the default, and every level above it broke more." And: "Effort changed how much each model wrote and how far it searched. It never made a model more careful." In the same test, max was Sonnet 5.5's best setting (13 clean runs of 20, against 11 at medium), and the Opus differences were one or two runs out of 20. Peter Steinberger, on Codex in December 2025: "There’s very little benefit to xhigh other than it being far slower".

One more number gets quoted out of context. Anthropic's multi-agent research post found that on BrowseComp "token usage by itself explains 80% of the variance". That is about total tokens across a multi-agent system, not about the effort setting.

When more thinking makes it worse

More thinking can hurt. The research has names for it.

Overthinking. On a trivial question, "o1-like models consumed 1,953% more tokens than conventional models to reach the same answer". Accuracy often follows an inverted U as reasoning grows: "performance initially improves but eventually decreases as the number of CoT steps increases."

Inverse scaling. Gema et al. (TMLR, 2025) built tasks where longer reasoning lowers accuracy and found five failure modes: "1) Claude models become increasingly distracted by irrelevant information; 2) OpenAI o-series models resist distractors but overfit to problem framings; 3) models shift from reasonable priors to spurious correlations; 4) all models show difficulties in maintaining focus on complex deductive tasks; and 5) extended reasoning may amplify concerning behaviors".

Underthinking. The opposite failure is real too: "o1-like LLMs frequently switch between different reasoning thoughts without sufficiently exploring promising paths to reach a correct solution". A long trace can be mostly indecision.

Analysis paralysis. In coding agents, a model can reason instead of act. Cuadron et al. studied 4,018 trajectories on SWE-bench Verified and named three patterns: "Analysis Paralysis, Rogue Actions, and Premature Disengagement". Higher overthinking scores "correlate with decreased performance". Their cost line is the whole topic in one sentence: "o1 with high reasoning effort achieves a 29.1% resolution rate at $1,400, while the low reasoning variant reaches 21.0% at $400 — a 3.5× cost difference for an 8.1 percentage point improvement in performance." And a twist: their low-effort o1 runs had higher overthinking scores than the high-effort ones. Turning the dial down is not a cure by itself.

Underthinking on low. Qwen's own model card warns that in multi-turn agentic tasks lower effort "can also lead to insufficient analysis, more failures, and repeated retries, which may increase total latency and token consumption." Anthropic says that in long agent prompts Haiku 5.5 at low "is more likely to skip a search, stop early, or skip a check".

The puzzle debate. Apple's "Illusion of Thinking" reported "a complete accuracy collapse beyond certain complexities". Critics argued that some instances exceeded output limits and showed that some River Crossing puzzles were unsolvable; Apple dropped Tower of Hanoi above 12 disks and River Crossing from six pairs up, kept its core claims, and an independent replication still found failures around eight disks. Reasoning isn't an illusion. It isn't unlimited either.

Thinking can't fix a missing fact. OpenAI's help center: "Increasing reasoning effort cannot supply missing information or access." Anthropic: "If you're increasing effort on a task that shouldn't need it, the fix is often upstream, in your context, your CLAUDE.md, or how the task is scoped." Anthropic's Thariq Shihipar, after reading Anthropic's internal Terminal-Bench 3.0 runs, wrote that higher effort tends to reduce failures from missed edge cases "but does not fix when the model has the wrong approach".

The thinking you see is not the thinking it did

Keep three things apart: the model's internal computation, the reasoning tokens it generates and conditions on, and the text the interface shows you.

Anthropic's docs are blunt about the third: "You don't always see this text, and what you see is never the raw chain of thought". "Summarization is processed by a different model from the one you target in your requests. The thinking model does not see the summarized output." On current models the default display is omitted: an empty thinking field. Either way, "You're charged for the full thinking tokens generated by the original request, not the summary tokens." OpenAI doesn't return raw reasoning either; you can opt in to a summary, and in stateless mode reasoning travels as encrypted content you pass back. Local runtimes can show the raw thinking text, and even that is not a complete account of the computation. And an empty thinking display doesn't mean the model didn't think.

Even the raw chain leaves things out. In Anthropic's faithfulness study, "Claude 3.7 Sonnet mentioned the hint 25% of the time, and DeepSeek R1 mentioned it 39% of the time." When a model learned a reward hack, it exploited it "on >99% of the prompts, but almost never (<2% of the time) verbalizes the reward hack in its Chain-of-Thought on more than half of our environments." Those numbers describe the models and conditions studied, not today's Opus or Astra.

None of that makes reasoning useless as evidence. In OpenAI's study of reward hacking in coding environments, a monitor that read the chain of thought caught 95% of systemic hacks; one that saw only actions caught 60%. But train against that monitor and "agents learn obfuscated reward hacking, hiding their intent within the CoT". A 41-author paper from across the labs titled it "Chain of Thought Monitorability: A New and Fragile Opportunity for AI Safety".

The practical rule: treat the thinking summary as a hint, not an audit log. Audit the diff and the tests.

The default is a product decision

The default is not a neutral starting point. It is a vendor's tradeoff between latency, cost and quality, and vendors change it.

On March 4, 2026, Claude Code lowered its default effort from high to medium for Opus 4.6 and Sonnet 4.6. Users reported worse results. Anthropic's postmortem on April 23: "On March 4, we changed Claude Code's default reasoning effort from high to medium to reduce the very long latency—enough to make the UI appear frozen—some users were seeing in high mode. This was the wrong tradeoff." The reversal rolled out in April. Two other changes fed the same wave of reports: a bug that kept clearing earlier thinking on every turn in sessions that had sat idle for over an hour, and a system-prompt change. Not every complaint was about effort. Anthropic reset subscribers' usage limits. Boris Cherny of the Claude Code team explained why a better effort picker wasn't enough: "people didn't understand to use /effort to increase intelligence, and often stuck with the default -- we should have anticipated this".

Six months later Opus 5.5 shipped at medium again, this time by design: "In Anthropic's testing, Opus 5.5 at medium matches or exceeds Opus 5 at high on coding and knowledge-work evaluations." Which leads to the rule people miss most: "The effort scale is calibrated per model, so the same level name does not represent the same underlying value across models." Medium on Opus 5.5 is not medium on Opus 5. Re-test your level on every model change.

Then there is precedence. In Claude Code, CLAUDE_CODE_EFFORT_LEVEL "Takes precedence over --effort, /effort, and the modelSettings and effortLevel settings." max "isn't accepted as a level in either" settings key, and "Unless you set it through the CLAUDE_CODE_EFFORT_LEVEL environment variable, Claude Code applies max to the current session only." One more: "a top-level effortLevel in your user settings file doesn't count for Opus 5.5." If that key is the only place you set effort, your Opus 5.5 sessions are quietly running at medium.

Codex has its own layers: CLI flags and --config overrides first, then project config, profile files, user config and managed defaults. A /model change applies to the session unless you save it, and a higher layer can still override what you saved.

Check what you actually run. In Claude Code: /effort status, the "with … effort" header, or effort.level in the status-line JSON. Since version 2.1.212, session transcripts also record the effort level on each assistant message.

My harness

I run three agents on one Mac: Claude Code, Codex, and OpenCode on local open-weight models. My personal defaults are deliberately aggressive: the top setting on every agent, paid for in time and in usage. That is my choice, not evidence that you should copy it.

Claude Code: Opus 5.5 at max. The level is pinned with CLAUDE_CODE_EFFORT_LEVEL=max in the env block of ~/.claude/settings.json, mirrored in my shell. There is deliberately no effortLevel key, and subagents are forced to the same model. In my own usage logs for the past week, a max-effort response averaged about 1,300 output tokens, and a little over half of that was thinking.

Codex: GPT-6 Astra at ultra, set in ~/.codex/config.toml for normal work, plan mode and subagents. My headless launches repeat the model and effort on the command line, and a consistency check fails if any of those values drift.

Local: Qwen3.8-27B with thinking on. In OpenCode each thinking-capable alias has a #max variant that sets enable_thinking: true and a #none variant that turns thinking off; the explore and title agents use #none. My #max sends no native effort level, so with Qwen3.8's template default it should mean Qwen's xhigh. That is a reading of the config, not a captured request. The launchers name the model and the variant explicitly, because a headless run that named only an agent once dropped the #max. Locally the bill is time, not money: at the roughly 16 tokens per second I measured for that model, 16,000 thinking tokens take about 17 minutes.

One exception: a work project runs Opus 5.5 at medium, to save tokens. A per-folder routing layer gives that folder its own level. Every launcher I own (the interactive shell function, the headless runner, the reviewer, the loops) adds --settings '{"env":{"CLAUDE_CODE_EFFORT_LEVEL":"medium"}}' and rewrites any --effort flag to match. When I type a level myself at an interactive launch, the routing layer pins that level instead, for that launch; Claude Code's own precedence doesn't change. It has to be a flag-level setting: the env block in my global settings would overwrite a medium value inherited from the shell, and --effort medium alone can't beat the environment pin. Medium is Opus 5.5's own default, and I still have to pin it, because my global max would win otherwise. Launches that bypass the routing, like the desktop app, stay at max. Codex and the local agent keep their settings there.

In the first hours at medium, responses averaged about 540 output tokens, with about 23% thinking:

That's different work and a short sample. It shows output size, not how much of a plan's allowance a level uses, and it says nothing about cost per finished task or about quality.

One rule for the agents. My harness policy says agents must not "lower model/effort, cap output, skip necessary review, force compaction, disable useful capabilities or start paid cache-keepalive jobs to save tokens." Explicit choices of mine take precedence. Lowering effort to save tokens is my decision, made per folder, never the agent's.

One surprise. I pinned Codex to Ultra believing it was the top of the dial. OpenAI's catalog describes Ultra as "Maximum reasoning with automatic task delegation". In the source of the Codex release I run (0.163.0), selecting Ultra resolves each request's reasoning.effort to the model's multi_agent_reasoning_effort when one is set, and my local catalog sets that to xhigh for GPT-6 Astra. Ultra also switches on proactive subagents. So, on that reading, my "maximum" Codex is xhigh per request, plus delegation. That is a reading of the source and the catalog, not a captured request. It is also not obviously worse: in OpenAI's own Astra charts, xhigh beats max on DeepSWE (74.12% against 73.01%). The label alone doesn't tell you that.

The cheaper sibling, again. My rule for the Codex seat: switch only to a model that, at its own maximum, beats Astra at Astra's maximum and costs less. GPT-6.1 Sol costs a fifth of Astra per token. At max it doesn't beat Astra at max on the outside numbers I found on October 20 (Artificial Analysis and ARC Prize ran their own tests; the Terminal-Bench rows don't say who ran them):

At its best settings Sol is close, sometimes ahead, and a rule based on the best result per dollar would give it a strong case. At max it fails mine. My rule has its own blind spot: max-effort benchmarks don't measure my actual Codex setup, which is xhigh plus delegation.

How to choose

Start from the vendors' own advice, because it is surprisingly consistent. Anthropic: "Our guidance is that for most tasks you should use the model’s default effort level." OpenAI calls medium "a well-balanced point on the pareto curve of latency, performance and cost", treats effort as "a tuning knob, not the primary way to recover quality", and says of Codex: "Most tasks do not need Max or Ultra." For Codex's current models the docs suggest the client default for GPT-6.1 Sol, Light (low) for Astra and High for Luna.

Four more starting points:

• Subagents doing search and summaries: low.
• A small, cheap model on agentic work: higher than you think.
• Work that splits into separate investigations: test delegation separately from depth.
• A local model on interactive work: compare thinking off against thinking on.

The low, medium, high and max rows follow Anthropic's own Claude Code table and the xhigh row its API docs; the subagent advice follows the API docs, which list low for "Simpler tasks that need the best speed and lowest costs, such as subagents"; the small-model advice follows the GPT-6 Luna and GPT-6 Sol curves. These are starting points, not thresholds.

Then diagnose before you turn the dial. Anthropic's rule: "If Claude has all the pertinent context, clearly tried, and still got it wrong, that's a signal to pick a more capable model. If Claude got it wrong by skipping a file, not running the tests, or bailing on a refactor partway through, pick a higher effort level." Extended to the failures I see:

• Missing context or access: supply it. More effort can't invent it.
• Skipped a file, a test or an edge case: tighten the definition of done, then try one level higher.
• Sound process, still wrong: try a stronger model or a different approach.
• Repeats the same analysis: read the trajectory and the tool feedback before raising anything.
• Ran out of output: raise the cap or lower the level.
• Delegates badly: check the task split before changing depth.
• A simple task needs high effort: check the prompt, the context and the scope before raising effort. Anthropic says the fix is often upstream.

Four habits make the dial pay:

• Escalate failures, not everything. Run at a lower level and re-run only what failed at a higher one. Anthropic measured a slightly higher pass rate than everything at high for a little over half the cost, with each failure taking two runs of wall-clock time. It only works if you can tell that something failed, which is what tests are for.
• Hold the level steady inside a session unless your model keeps the cache when you change it.
• Stop prompting for thinking. OpenAI's advice for reasoning models: prompting them to "think step by step" or "explain your reasoning" is unnecessary. Anthropic suggests removing "think carefully" instructions from chat system prompts for Opus 5.5 and says: "To get less thinking, lower the effort level first."
• Re-test on every model change. Level names are recalibrated per model.

Count the whole job when you compare: failed attempts, repairs and your own review time. A cheaper request that leaves more work unfinished is not a cheaper solution.

Brutal truths

• "Max is the smart setting." It's the expensive one, and often no better than a lower level: on ARC-AGI-2, Terminal-Bench, FrontierCode and the AA Coding Agent Index a lower level matched or beat it, sometimes clearly (Haiku 5.5 in Claude Code: 41.4 at xhigh, 36.5 at max).
• "Thinking makes the model smarter." It gives the same model more steps. On the index above, each step up the dial buys its points at a higher price than the one before.
• "I can read its reasoning." On Claude you read a summary written by a different model, on OpenAI an opt-in summary, and even raw reasoning text can leave things out.
• "More turns mean more care." In paddo.dev's 300 runs, effort "never made a model more careful."
• "Low is safe for easy agent work." Low can stop early, skip checks and cost more in retries.
• "The default is neutral." It is a vendor's tradeoff, and it moves.
• "ultrathink means max." In current Claude Code it's an in-context nudge. The API effort is unchanged.
• "Ultra means max." In the Codex 0.163.0 source, with today's model catalog, Ultra on GPT-6 Astra resolves to xhigh per request and adds subagents. That is my reading of the code, not a captured request.
• "More effort always costs more." Usually. On ARC-AGI-3 higher effort cost less, and Anthropic's low-then-high policy beat everything-at-high on both price and pass rate, where tests could catch the failures.
• "My max-everywhere setup proves max is right." It proves I prefer it. My own logs aren't a controlled test.

Start at the default, compare complete results on your own work, and keep max for the work where a wrong answer costs more than the extra thinking.

Sources

• Anthropic docs: Thinking, Effort, Steering thinking, Extended thinking (legacy), Optimizing for cost and intelligence, Prompting Claude Opus 5.5, Pricing, read 20 October 2026.
• Claude Code docs: Model configuration, Environment variables, Settings, Status line, Prompt caching, Changelog, Commands, CLI reference, Subagents, Costs, read 20 October 2026.
• Anthropic: Introducing Claude Opus 5.5, 22 September 2026; Introducing Claude Sonnet 5.5, 28 September 2026; An update on recent Claude Code quality reports, 23 April 2026; How we built our multi-agent research system, 13 June 2025; Claude's extended thinking, 24 February 2025; Reasoning models don't always say what they think, 3 April 2025.
• Claude: Choosing a Claude model and effort level in Claude Code, 7 July 2026; Thariq Shihipar, Using Claude Code: Spending your effort, 25 September 2026; Help Center, Change the model, effort, and thinking settings.
• OpenAI docs: Reasoning models, Reasoning best practices, API pricing, Codex models, Codex configuration reference, Codex pricing, Codex config basics, Codex slash commands, Codex speed, read 20 October 2026; Learning to reason with LLMs, 12 September 2024; Introducing GPT-6.1 Sol, 29 September 2026; Introducing GPT-6 Sol and Luna, 22 September 2026; openai/codex at tag rust-v0.163.0.
• OpenAI (other): Managing usage with GPT-6 Astra in Work and Codex; Introducing GPT-5, 7 August 2025; GPT-5 prompting guide; API changelog; GPT-6 Astra; openai/codex PR #5035, shipped in rust-v0.47.0.
• Independent evaluations: Artificial Analysis leaderboard and Coding Agent Index; ARC Prize leaderboard and GPT-6 Astra on ARC-AGI-3, read 20 October 2026.
• Public leaderboard: Terminal-Bench, submitter not stated, read 20 October 2026.
• Papers: Wei et al., Chain-of-Thought Prompting; Kojima et al., Large Language Models are Zero-Shot Reasoners; DeepSeek-AI, DeepSeek-R1, Nature 645 (2025), and arXiv v2, 4 January 2026; Liu et al., Understanding R1-Zero-Like Training; Yue et al., Does Reinforcement Learning Really Incentivize Reasoning Capacity; Li et al., Chain of Thought Empowers Transformers to Solve Inherently Serial Problems; Snell et al., Scaling LLM Test-Time Compute Optimally; Brown et al., Large Language Monkeys; Chen et al., Do NOT Think That Much for 2+3=?; Wang et al., Thoughts Are All Over the Place; Wu et al., When More is Less; Gema et al., Inverse Scaling in Test-Time Compute; Cuadron et al., The Danger of Overthinking; Shojaee et al., The Illusion of Thinking; Varela et al., Rethinking the Illusion of Thinking; Baker et al., Monitoring Reasoning Models for Misbehavior and the Risks of Promoting Obfuscation; Korbak et al., Chain of Thought Monitorability; Guan et al., Monitoring Monitorability.
• Local models: Qwen, Qwen3.8-27B model card; OpenAI, gpt-oss model card; llama.cpp server; my local measurements in The Third Mind.
• Practitioners: Simon Willison, Claude Opus 5.5, GPT-6 Sol, GPT-6 Luna, and a new price war, 22 September 2026; paddo.dev, The Default Was Right, 29 September 2026; Peter Steinberger, Shipping at Inference-Speed, 28 December 2025; Boris Cherny on Hacker News, 23 April 2026.
• My harness settings and usage averages come from my own configuration and usage ledger on 20 October 2026; they are not controlled evaluations.