Reasoning effort, fast mode and ultracode: when to use each

What is effort, and how does it set how much the model thinks?

Effort is the setting where you choose how much work the model puts into an answer; OpenAI calls it reasoning effort, Google calls it thinking level. In the SWE-bench post we showed the same model getting a different score when only effort changed, and in the subagents post how subagents inherit effort. This post puts effort next to two settings it is often mixed up with:

All three providers now have you set thinking with a named level rather than a token count. Anthropic’s documentation says plainly what the level is: effort is not a budget but guidance given to the model (“a behavioral signal, not a strict token budget”). It affects not only thinking but also the text and the tool calls; as effort goes down, the model makes fewer and shorter tool calls.

Source: the three providers’ API docs, 20 October 2026. GPT-6.1 Sol does not support the none and minimal levels. At Google, the minimal level does not guarantee that thinking is off, even on the models that support it.

In all three, the hard limit is the output token limit: max_tokens at Anthropic, max_output_tokens at OpenAI and Google. Anthropic puts it briefly: effort is soft guidance, max_tokens is a strict limit. If the model hits that limit while it is thinking, the answer is cut off or comes back empty; OpenAI and Google say plainly that the thinking spent is billed anyway.

Two things changed this year. First, the old token budget is on its way out: at Anthropic, budget_tokens is deprecated on the 4.6 models and rejected by 4.7 and later; at Google, thinking_budget is deprecated for Gemini 4 Argon. On Opus 5.5 and Gemini 4 Argon you cannot even turn thinking off; the level is the only knob you have. Second, the defaults came down. Opus 5.5, Haiku 5.5, GPT-6.1 Sol and Gemini 4 Argon start at medium, so Opus 5.5 starts one level below Opus 5. Sonnet 5.5’s default depends on where it runs: high on the Claude API, medium in Claude Code.

Don’t compare level names across models. Claude Code’s documentation says the scale is calibrated for each model separately, so the same name does not mean the same amount of thinking on different models; Sonnet 5.5’s levels were recalibrated against Sonnet 5. Codex’s documentation also says the levels do not map exactly between model generations.

Changing effort in the middle of a conversation has a price. At Anthropic, changing effort at the request level invalidates the prompt cache; per-message effort (beta) changes the level while keeping the cache, and works on Opus 5.5, Sonnet 5.5 and Haiku 5.5. At OpenAI, configuration_update has done the same job since 3 September. Why the cache breaks is in the prompt caching post.

How do you set effort in the five tools?

All five tools let you pick the level with a command or a setting. Where they differ is the default, and whether there is a higher mode that splits the work across subagents. We read the table from each tool’s own documentation and release notes on 20 October 2026:

Source: each tool’s documentation and release notes, 20 October 2026. “Not in the docs”: we found no sentence saying so on the pages we read that day. --effort came to Copilot CLI with version 1.0.10 (20 March), and max for Anthropic models with 1.0.60 (5 June). /effort came to Antigravity CLI with version 1.1.5 (21 July), and /boost to the Antigravity app with 2.12.0 (2 September). HydraFusion Max was announced on 14 October.

In Claude Code, /effort opens a slider; you can also type the level directly, as in /effort high. effortLevel in the settings file takes values from low to xhigh; max is not accepted there and can only be chosen for a session. You can also write effort into skill and subagent definitions; while that skill or subagent runs, it takes the place of the session’s level.

In Codex, the level is set by model_reasoning_effort in ~/.codex/config.toml; which levels you can pick depends on the model and the client. You can give Plan mode a value of its own; if you leave it empty, Plan mode uses its own default. An example:

model_reasoning_effort = "high"
plan_mode_reasoning_effort = "xhigh"

Codex’s models page tells the two top levels apart: Max gives a single task more time to think, while Ultra spreads the separate parts of a complex job across parallel subagents. The same page says most tasks need neither.

In Copilot CLI, --effort (long name --reasoning-effort) takes five levels from low to max; max exists only on Anthropic models. Since version 1.0.88, the reasoningEffort in a custom agent’s definition applies when that agent is selected; a level you pass explicitly on the command line still wins. In VS Code, you pick the level from the “Thinking Effort” submenu, which opens when you click the arrow next to the model’s name in the model picker, and it is remembered per session. GitHub’s documentation also names the price: a higher level spends more tokens, and so more AI credits; start at the regular level and raise it only for hard tasks.

In Cursor, the Plus plan runs Cursor’s own models at fixed settings: effort medium, Fast off. Choosing an effort level and Fast takes Premium or higher. Max Mode on the old request-based plans is not an effort level; it is a separate option that widens the model’s context window.

In Antigravity CLI, /effort picks the level and saves it for later sessions; --effort applies only to that run. Most models offer low, medium and high; xhigh and max exist only on some. If you still use Gemini CLI: its command list has no command for effort, and the thinking setting lives only in the model definitions in the configuration. Google replaced Gemini CLI with Antigravity CLI for free-tier and Google One users on 18 June 2026; with paid API keys, Gemini CLI can still be used.

What is ultracode, and how is it different from effort?

Ultracode is, in the words of Claude Code’s documentation, “a Claude Code setting rather than a model effort level”. With it on, Claude plans a dynamic workflow for every substantive task: it writes a JavaScript script that splits the work into parts and manages many subagents, and runs the script in the background. According to the workflows documentation, a single request can turn into several workflows in a row: one to understand the code, one to make the change, one to verify it.

Effort, on the other hand, sets how much a single agent thinks. The two are independent: ultracode runs at whatever level the session is at. This split is new. When ultracode was announced with dynamic workflows on 28 May, it raised effort to xhigh. Since version 2.1.284 (28 September), it is a separate toggle inside /effort and leaves the level alone. Write-ups from before that date describe the old behaviour. One exception remains: if you start the session with claude --effort ultracode, the level becomes xhigh too. The four ways to turn ultracode on are in the subagents post.

There is no multiplier for the cost. Anthropic does not publish how many times more tokens ultracode uses; the documentation says each request will use more tokens and take longer, and that on a subscription you will reach a session or weekly limit sooner. With ultracode on, two brakes come off: the “Large workflow” warning for workflows that expect more than 25 agents or 1.5 million tokens is not shown, and the session’s concurrent subagent limit does not apply to subagents started with the Agent tool. The workflow’s own limits stay in place: by default 16 at a time, and at most 1,000 agents in a run. Ultracode does not turn on if workflows are off or the model does not support xhigh.

The other tools have their own versions of the same idea. None of them is the same thing as effort:

Source: the Claude Code, Codex, HydraFusion and Antigravity documentation, 20 October 2026. In Codex, Ultra sits as a level on the effort slider (from Light to Ultra); it is not among the reasoning.effort values of the OpenAI API.

Ultrathink, with its similar name, is something else. When you type ultrathink into a prompt, Claude Code adds an instruction asking for deeper thinking on that turn, but the effort level sent to the API does not change. So ultrathink is a one-message request, effort is the session’s setting, and ultracode is how many agents do the work.

The sources we read contain no measurement that compares ultracode on and off, and none for the similar modes either. So try ultracode on a large job that can be split, and on a small slice of it first. The workflows documentation also suggests running it in a single folder first, to see the spend before you start a large job.

What does fast mode speed up, and what does it cost?

Effort changes how much the same model thinks; fast mode changes how fast the same model writes its answer. Providers sell the same model at several speeds: cheaper for whoever can wait, more expensive for whoever is in a hurry. We read the table from the providers’ pricing and tier documentation on 20 October 2026:

Source: the providers’ pricing and tier documentation, 20 October 2026. Prices are input / output per MTok. At OpenAI, Priority was renamed Fast mode on 30 July. Google’s Flex is in preview. At Anthropic, fast mode cannot be used together with the Batch API.

Anthropic’s documentation is precise about what fast mode speeds up: it raises the output tokens per second, not the time until the first token arrives. The model and its intelligence stay the same. The difference shows in a long answer or a long diff; on short questions you will barely notice it. There is one more cost: requests at different speeds do not share the cache. Claude Code’s documentation spells out what follows: the first time you turn fast mode on in a conversation, you pay the uncached fast mode price for the entire context so far. So the cheapest moment to turn it on is at the start of the session.

Here is where the five tools stand:

• Claude Code: /fast turns it on and off. On Opus 5.5 output speed goes up by as much as 2.5×, at $8 / $40 per MTok. On subscription plans it is paid from usage credits, not from your plan limit. On the API, fast mode for Opus 5.5 left research preview on 15 October; Claude Code’s fast mode page still said “research preview” on 20 October 2026.
• Codex: /fast in the CLI; to keep it on, service_tier = "fast", which goes out in the request as priority. According to the documentation, fast mode draws on your subscription limit at 2.5× the standard rate, and on purchased credits at 2×. Since 8 October, GPT-6.1 Sol also has Ultrafast: 8× from the limit, 6× from credits; only on Pro $500 and eligible Enterprise and Edu plans.
• GitHub Copilot: there is no tool-wide speed switch; the fast version sits in the model picker as a separate model. “Claude Opus 4.8 (fast mode)” has been in preview since 29 June 2026 and costs more than standard Opus 4.8; on Business and Enterprise an administrator has to turn it on.
• Cursor: Fast is a separate option in the model table; on models such as Grok 4.7 you can pick it at twice the price. It is off on the Plus plan.
• Antigravity: the docs say nothing about a paid speed tier.

The price of the cheap tiers is waiting, or being turned away. OpenAI’s flex tier can return 429 under load; these requests are not charged. Google’s Flex does not move a request up to the standard tier on its own when capacity is full; it leaves the retry to you. For work a person is sitting and waiting for, that means a surprise; for a batch job that runs overnight, it means half price.

Does more effort mean a better result?

Up to a point. We looked at three kinds of evidence: the vendor’s own measurement, an independent index and our own logs. Results the vendor reported are marked as such.

We drew the effort sweep from Anthropic’s cost documentation in the SWE-bench post: on a SWE-bench Pro subset Anthropic chose itself, Opus 5.5 solves more tasks as it goes from low to xhigh, and the cost per task multiplies. The same document has a more useful idea: instead of running everything at a high level, run at low first and repeat only the failures at high. At low, 13% of the tasks failed; with those repeated at high, about 97% of the tasks were solved, at about $0.17 per task. With everything at high, the result was 95.3% at $0.29. This is a vendor-reported result with two conditions: you need a signal that tells you a task failed (there, the benchmark’s own tests), and every task that fails on the first try waits for two runs.

On the independent side, Artificial Analysis’s Coding Agent Index measures the same model at every effort level, inside a coding tool: 303 tasks, 3 attempts per task. The results on 20 October 2026:

Source: Artificial Analysis, the live page on 20 October 2026; a single snapshot. Each cell holds the index score and the average cost per task. The page gives no confidence interval; a difference of a few points may be noise. When a model refuses for safety reasons, another model can finish the attempt, and the attempt still counts: in the Sonnet 5.5 rows, between 18 and 45 of 909 attempts went this way. Level names are calibrated for each model separately, so read the table column by column, not row by row.

The three models show three different things. Sonnet 5.5 rises at every level, but the cost per task is $0.48 at low and $14.19 at max; the average time per task also grows from about 6 minutes to 87 minutes. On Haiku 5.5, max costs 4.2 times as much as xhigh and scores lower. GPT-6.1 Sol is nearly flat across the levels: its lowest and highest scores are 5.7 points apart.

In the vendor’s own measurements, too, the returns flatten at the top levels. According to Opus 5.5’s system card (vendor-reported), the model scored 66.4% on Terminal-Bench 4.0 at xhigh and 64.8% at max; Anthropic counts the difference as within noise (standard error ±2.6 points). On the same card, Opus 5.5’s best FrontierCode score (54.6%) is at medium; above medium the score drops, and at max it largely comes back. FrontierCode penalises changes the task did not ask for; how the model strays outside the scope at high effort is in the SWE-bench post.

Our own logs showed something else. diffox is an AI code review tool; we ran the Claude model we use several times on the pull requests of a public benchmark set, changing only effort. Each run consists of the same 100 model calls. Because thinking tokens are billed inside the output tokens, we counted whether a call thought by checking whether its response had a thinking block:

At medium, none of the calls thought; the model wrote the answer directly. At high most calls thought, at xhigh all of them did, and the output and time per call grew with it. So with adaptive thinking, effort changes whether the model thinks more than how long it thinks. Anthropic’s documentation says the same: in adaptive mode, effort sets how often and how deeply the model thinks, and at lower levels it can skip thinking entirely on simple problems. A second benchmark set gave the same picture: at medium none of 200 calls thought, at high 88 of 200 did. We tried max on only two calls, and both thought: 61,470 and 83,150 tokens, 423 and 745 seconds per call.

Whether raising effort catches more bugs is something our logs do not show. To say that, you need repeated runs at every setting; we have one or two runs per setting, and the difference between them is no larger than the usual swing between two runs. Why we don’t count a single run’s outcome as a result is in the LLM-as-a-judge post.

Which setting should you pick for which job?

The sources agree on this: start with the model’s default, and raise it only by measuring on your own work. OpenAI says to treat effort as a tuning knob, not as the main way to recover quality. Google suggests trying all three levels in your own evaluation and picking the lowest one that meets your bar. A summary for common jobs:

The reasons behind the cards are in the docs. Claude Code’s documentation warns of diminishing returns and overthinking at max, and asks you to test it before you adopt it widely; Codex’s documentation also says most tasks need neither Max nor Ultra. OpenAI lists security and code review among the common uses of xhigh, but only when your own evaluation shows a clear benefit. Ultra modes help when you can split the work into meaningful parts; on a single hard problem that cannot be split, one agent thinking longer makes more sense. For pull request bots and CI jobs, pick the standard tier: flex can reject requests under load, and batch can take hours.

Three more habits help:

• Add a scope instruction. If the output will be a diff to merge, add a short sentence to the prompt telling the model to stay within the task’s scope. According to Anthropic, above high Opus 5 made more changes than the task asked for, and with this instruction the score came back on most of those tasks.
• Change effort per message. In a long session, changing the level at the request level invalidates the cache. Anthropic’s per-message effort and OpenAI’s configuration_update change the level while keeping the cache.
• Cheap level first, then the expensive one. If you can check the output with a test or a checker, running at a low level first and repeating only the failures at a high level came out cheaper in Anthropic’s measurement than running everything at high.