Reasoning effort: what the dial actually controls, and what it costs

A claim in a Reddit thread goes like this: GPT-6 Astra at xhigh effort burns less of your allowance than at medium, because medium keeps reprocessing a long history while xhigh gets there sooner. Leonardo Gonzalez of Trilogy AI tested it and published the result on 11 September 2026: 24 runs through Codex on a ChatGPT Pro subscription, two internal tasks, three attempts at each of low, medium, high and xhigh. On both tasks xhigh used more tokens than medium, not fewer: 1.76 times as many on one and 2.52 times on the other. The test is small, unscored for correctness and counted in subscription allowance rather than API dollars, so it settles nothing alone. But the claim names a real cost in agent work, re-reading the context on every turn, and the useful question is whether higher effort ever shrinks that cost enough to pay for itself.

Effort is guidance, and among request parameters only the output cap is a hard limit on tokens. Raising effort makes each turn more expensive, so it can lower the cost of finishing a task only if it cuts turns or retries, or keeps the context smaller each turn, by more than a margin you can compute. The published measurements so far mostly show turns and input rising with effort instead. Below: levels and defaults, one illustrative cost example carried to break-even, the measurements, and a test for your own workload. We ran no model; the arithmetic is ours.

What the effort setting is: an instruction, not a token allowance

On the Anthropic, OpenAI and Google Gemini APIs, the reasoning effort setting tells the model how much work to put into a request, and as of 27 September 2026 no vendor documents a token count for any level of its own native effort parameter. Think of the brief you give a contractor, "have a quick look" against "be thorough", rather than a meter set to a number of hours. Unlike a contractor's brief, the setting applies to each request in an agent loop separately: on Claude, Anthropic says, the model "decides per request whether to think", so low does not stop it thinking on a hard step.

Anthropic is the most explicit. Its effort documentation says: "Effort is a behavioral signal, not a strict token budget. At lower effort levels, Claude still thinks on sufficiently difficult problems, but thinks less than it would at higher effort levels for the same problem." Its page on steering thinking and cost calls effort "soft guidance", says requests that only process tool results can skip thinking even at xhigh and max, and adds: "No level guarantees a thinking block on every request."

OpenAI says less. Its reasoning guide says reasoning.effort "guides the model on how much to think", that supported values "are model-dependent", and that "the models also reason adaptively across reasoning efforts, using fewer tokens for simpler tasks and thinking harder for complex tasks." OpenAI's documentation does not call effort soft or say levels are not budgets.

Google's current pages describe Gemini's thinking_level in similar terms. The thinking guide (updated 25 September 2026) says Gemini models "engage in dynamic thinking by default". The generateContent reference says thinkingLevel "Controls the maximum depth of the model's internal reasoning process", and the Gemini 3.5 guide warns that "minimal does not guarantee that thinking is off". The plainest sentence is on the Gemini 3 guide, a page Google marks as deprecated: "Gemini 3 treats these levels as relative allowances for thinking rather than strict token guarantees."

How the setting reaches the model is documented in two details. Anthropic says "The resolved effort value is rendered into the prompt." OpenAI's prompt-caching guide says reasoning.effort "Can change model-side reasoning instructions", and that changing it "can rewrite instructions in the hidden system instructions". We found nothing further documented.

What changes when you raise or lower effort

Raising the effort level changes more than how long a model reasons: Anthropic documents that it also changes how many tool calls Claude makes and how much it explains, and Google says higher Gemini thinking levels encourage more tool use. Anthropic's effort page says the parameter "affects all tokens in the response", including tool calls and their arguments: "Lower effort also means fewer and terser tool calls." Higher effort makes more calls, explains its plan, writes detailed summaries and adds more code comments.

Anthropic's guide to optimising for cost and intelligence draws the consequence: effort "governs how much thinking, tool calling, and self-verification the model does... Cost scales with all that activity; accuracy scales only with the part your task needs." Its Sonnet 5 prompting guide says high and xhigh "show substantially more tool usage" on that model, and Google's Gemini 3.5 guide says higher levels "encourage the model to use more tools".

OpenAI documents only the reasoning side: the Responses API reference says lower effort "can result in faster responses and fewer tokens used on reasoning". Visible length has its own control, text.verbosity.

Models differ: on Claude Opus 5, Anthropic says, "changing effort does not reliably shorten responses, so prompt for length instead", an exception it states for Opus 5 only.

Latency follows the extra work. Anthropic reports that Claude Fable 5 took 4.5 minutes per problem on DeepWideSearch at low against 7.9 minutes at its default (vendor-reported, runs on 2 August 2026). In Trilogy's test, moving GPT-6 Astra from medium to xhigh took runtime from 14 to 25 minutes on one task and from 14 to 38 minutes on the other.

Where per-level token counts come from, and what actually caps spend

Tables that assign each Claude effort level a fixed number of thinking tokens, such as one in a July 2026 MindStudio post, contradict Anthropic's documentation, which says effort is not a token budget. The MindStudio post, edited by Luis Chavez-Mattos and dated 3 July 2026, gives a "Thinking Budget" per level: None "0 tokens", Low "~1,000–2,000 tokens", Medium "~4,000–8,000 tokens", High "~16,000–32,000 tokens" and Max "~32,000+ tokens". It cites no sources. Against Anthropic's documentation it is wrong on four counts: effort is not a budget; Claude's effort has no none value; thinking cannot be turned off on Fable 5; and Fable 5 supports xhigh, which the table omits.

Such numbers probably descend, in our reading, from controls that really did take token counts:

• Anthropic's legacy budget_tokens. The older extended thinking budget had a 1,024-token minimum, with "16,000 tokens or more" suggested for complex tasks. It is deprecated on the 4.6 models and rejected with an HTTP 400 on 4.7 and later; why new model APIs reject old parameters such as budget_tokens covers that migration. Even this budget was, in Anthropic's words, "a target rather than a strict cap".
• Gemini's legacy thinking_budget. The API reference describes it as "The number of thoughts tokens that the model should generate". It is "no longer recommended" for Gemini 3.x, and sending it with thinking_level returns a 400 error.
• Google's compatibility layer. The OpenAI-compatibility page (updated 2 September 2026) maps reasoning_effort to thinking_level on the Gemini 3 models it lists, but on Gemini 2.5 to a thinking_budget: 1,024 tokens for minimal and low, 8,192 for medium and 24,576 for high. That is Google's own translation on its compatibility endpoint for an older model family, not how the native thinking_level works on newer ones.
• Gateway translation layers. OpenRouter's reasoning tokens guide turns its unified effort parameter into budget_tokens for budget-based Anthropic models as a share of max_tokens, from 0.1 at minimal to 0.95 at max and xhigh. The same page also documents passing Claude's native effort through unchanged, without saying which applies to adaptive-only Claude models. The ratios are a gateway's translation, not a vendor's definition.

Among request parameters, the only hard limit on tokens is the output cap, and on every platform it caps one request, not a task. Anthropic says max_tokens "is a hard cap on total output for the request", but "In a tool-use loop, each request in the turn has its own max_tokens, so it doesn't bound the whole turn's spend." On OpenAI, max_output_tokens includes reasoning tokens, a response that hits it comes back incomplete and "could incur costs for input and reasoning tokens without receiving a visible response", and the guide suggests reserving at least 25,000. On Gemini, max_output_tokens "acts as a hard cutoff enforced by the infrastructure", and thinking tokens already generated are still billed. On OpenAI, Azure, Bedrock and Databricks the cap also counts against your rate limit before the model writes anything, while Anthropic's API ignores it; our guide to max_tokens and rate limits compares the rules.

Lowering the cap does not save money. In Anthropic's measurements, "max_tokens is a safety cap: lowering it cut cost per attempt without lowering cost per solved task."

For an allowance across a whole agent loop, Anthropic has a separate beta, task budgets, which it too calls "a soft hint, not a hard cap". On Claude Managed Agents, Anthropic's cost guide says, "a session budget is the hard dollar stop": a session budget (beta) caps one session's spend at list rates and is "enforced between model requests, not mid-request", so the request that crosses it still finishes. A monthly workspace spend limit is "the final backstop". OpenAI and Google document monthly spend limits for a project or account; we found no per-task cap on either.

Effort levels by vendor and model, as of 27 September 2026

Effort level names are not a shared scale, across vendors or even within one: no vendor documents a calibration against another's levels, and Anthropic's Opus 5.5 prompting guide says: "Effort level names don't correspond to the same amount of thinking across models: in Anthropic's testing, Claude Opus 5.5 at medium matches or exceeds Claude Opus 5 at high". The Sonnet 5 guide advises: "When benchmarking, match by observed thinking length rather than effort name."

Some levels exist on one model and not the next. GPT-6 Astra has no none (OpenAI says sending it returns HTTP 400), and no OpenAI page we found states Astra's default. "Not every model that supports max supports xhigh", Anthropic notes. minimal exists on some Gemini models and on no GPT-6 model page; OpenAI's latest-model guide says "If your existing request uses minimal, start with low". Claude Opus 5.5 always thinks, and thinking: disabled returns a 400.

Defaults move between versions. Anthropic says "Most Claude models default to high effort... Claude Opus 5.5 defaults to medium." Google's Gemini 3.5 guide says the default moved from high to medium. On Claude, setting the default explicitly "produces exactly the same behavior as omitting the effort parameter entirely", so pinning the level in code changes nothing today and protects you when a default changes.

	Anthropic	OpenAI	Google Gemini
Parameter	output_config.effort	reasoning.effort (Responses); reasoning_effort (Chat Completions)	thinking_level; thinkingLevel in generateContent
Values	low, medium, high, xhigh, max, per model	none to max, per model	minimal to high, per model
Vendor's words	"not a strict token budget"	"guides the model on how much to think"	"Controls the maximum depth"; "relative allowances" (deprecated page)
Also changes	text, tool calls, arguments	reasoning tokens and speed only documented	more tool use at higher levels
Hard cap	max_tokens, per request	max_output_tokens, includes reasoning	max_output_tokens
Other budget controls	task budgets (beta, advisory); Managed Agents session budgets (beta, hard, in dollars); legacy budget_tokens	none per task found	legacy thinking_budget
Reasoning-token field (in usage)	output_tokens_details.thinking_tokens	output_tokens_details.reasoning_tokens; completion_tokens_details.reasoning_tokens (Chat)	thoughtsTokenCount; total_thought_tokens (Interactions)
Billing	as output; billed tokens differ from the visible summary	as output	full thought tokens, though only a summary is returned
Changing effort mid-session	breaks the cache; per-message beta avoids it	cache miss reasoning_effort_changed; configuration_update avoids it	not documented

How each API implements effort, as of 27 September 2026. On Anthropic, output_tokens is authoritative for billing; the thinking count sits inside it.

Model	Levels	Default
Claude Opus 5.5	all five	medium
Claude Fable 5.1	all five	high
Claude Mythos 5.1	all five	high
Claude Sonnet 5	all five	high
Claude Opus 4.6	all but xhigh	high
Claude Sonnet 4.6	all but xhigh	high
GPT-6 Astra	low to max	not documented
GPT-6 Sol	none, low to max	medium
GPT-6 Luna	none, low to max	medium
gemini-3.8-flash	low, medium, high	medium
gemini-3.7-flash	low, medium, high	medium
gemini-3.6-flash	minimal to high	medium
gemini-3.5-flash	minimal to high	medium
gemini-3.5-flash-lite	minimal to high	minimal
gemini-3.1-pro-preview	low, medium, high	high
gemini-3-pro-preview	low, high	high

Levels and defaults for selected models, as of 27 September 2026; the vendor pages list more, so check them before relying on a row. For Claude, "all five" means low, medium, high, xhigh and max; OpenAI's "low to max" covers the same five names. Sources: Anthropic's effort page, OpenAI's model pages for GPT-6 Astra, Sol and Luna, and Google's thinking guide.

Where the money goes in an agent loop

In a multi-turn agent task the largest cost is usually not the reasoning tokens but re-sending the growing context on every turn, so caching, and anything that changes the number of turns or the size of the context, moves the bill more than effort's extra output does. Anthropic's cost guide puts it plainly: "A 40-turn task sends its first turn 40 times, so task cost grows with roughly the square of turn count." It reports that agent loops "read a median 84% of their input from the cache", and the top 10% of harnesses 94% or more (vendor-reported, 14 days of first-party API traffic to 23 August 2026, scored per organisation-day).

One example carries the rest of this piece. It is illustrative arithmetic, not a measurement, and these assumptions hold wherever it appears:

• Model and prices, documented. Claude Opus 5.5 at Anthropic's list prices as of 27 September 2026, per million tokens: $4 input, $5 for a five-minute cache write, $0.20 for a cache read and $20 output.
• Task, invented. 30 turns per attempt at every level. A short context that starts at 10,000 tokens and grows by 1,500 tokens of tool results a turn; a long one that starts at 80,000 and grows by 6,000.
• Output, invented. 800 tokens per turn at low, 2,400 at high and 4,800 at xhigh, all of it fed back into the next turn's context. The high to low ratio sits near Artificial Analysis's measurement for Opus 5.5, whose high variant produced 2.68 times the output tokens of its low variant.
• Caching, idealised. Every prefix hits, so about 94% of input is read from cache, close to Anthropic's figure for the top tenth of harnesses. A median harness pays more.

Start with the long context and no caching. One attempt at low costs $21.91, of which output is $0.48. At high it costs $25.66, with $1.44 of output. Tripling the output raised the price of the attempt by about 17% (a ratio of 1.171), because almost all the money goes on input: 5.36 million input tokens at low and 6.05 million at high, the rise coming from extra output re-entering the context.

Now cache it. The same attempts cost $2.88 and $4.20. Caching cut the low attempt by about eight times, but output is billed at full price either way, so the ratio between the levels rises to 1.459. The short context shows the same pattern more strongly: 1.659 uncached and 2.193 cached, with caching cutting the low attempt by about five times. The cheaper your input, the larger effort's extra output looms in the bill; how prompt caching prices repeated context explains why cache reads are so cheap.

Scenario	low per attempt (output)	high per attempt (output)	high ÷ low
Short, uncached	$5.68 ($0.48)	$9.43 ($1.44)	1.659
Short, cached	$1.11 ($0.48)	$2.43 ($1.44)	2.193
Long, uncached	$21.91 ($0.48)	$25.66 ($1.44)	1.171
Long, cached	$2.88 ($0.48)	$4.20 ($1.44)	1.459

One attempt, Claude Opus 5.5, illustrative task, list prices as of 27 September 2026.

When higher effort can cost less: the break-even condition

A higher effort level is cheaper per solved task only if its cost per attempt divided by its success rate falls below the lower level's. More output per turn raises cost per attempt when all else is equal, so higher effort can win only by finishing in fewer turns, by adding less to the context each turn, or by raising the success rate by more than it raises cost. A failed attempt is paid for and then run again, so cost per solved task is the number that matters.

In symbols (notation, not code), with failures detected and retried at the same level:

A = cost of one attempt     p = chance an attempt succeeds
cost per solved task = A / p

higher level H beats lower level L  if  A_H / p_H  <  A_L / p_L
equivalently                        if  A_H / A_L  <  p_H / p_L

For T turns, starting context C0, tool results r per turn,
output o per turn, and a share v of output re-entering context:
  d = r + v*o
  uncached:  A = price_in * (T*C0 + d*T*(T-1)/2) + price_out * T*o
  cached:    A = price_write * (C0 + (T-1)*d)
               + price_read * ((T-1)*C0 + d*(T-1)*(T-2)/2)
               + price_out * T*o

For success rates we borrow 0.874 at low, 0.953 at high and 0.967 at xhigh from Anthropic's vendor-reported Opus 5.5 SWE-bench Pro sweep (below). They make the arithmetic concrete; they are not a claim about the example task.

Consider the retries route first. The success ratio of high over low is 1.09, while the cost-per-attempt ratios above run from 1.171 to 2.193, so in no scenario can success alone pay for high. Even in the long uncached case it would need a success rate per attempt of 102.3%, which is impossible.

Next, the turns route, holding each turn's tool results fixed: how many of the 30 turns must the higher level save to match low per solved task?

Scenario	low	high	xhigh	high must cut	xhigh must cut
Short, uncached	$6.50	$9.89	$15.56	6.5 turns (22%)	12.0 (40%)
Short, cached	$1.27	$2.55	$4.56	14.2 turns (47%)	20.9 (70%)
Long, uncached	$25.07	$26.92	$32.34	1.3 turns (4%)	4.4 (15%)
Long, cached	$3.30	$4.41	$6.40	7.2 turns (24%)	14.1 (47%)

Cost per solved task at 30 turns, and turns out of 30 each higher level must avoid to match low. Illustrative task, Claude Opus 5.5 list prices as of 27 September 2026.

Illustrative task shape. Claude Opus 5.5 list prices as of 27 September 2026; success rates borrowed from Anthropic's vendor-reported SWE-bench Pro chart. Calculated, not measured.

The spread is the point. With a long, uncached context, high pays for itself if it saves just over one turn in 30. With a short, well-cached one it has to save nearly half of them. Caching discounts exactly what fewer turns would save, the re-read context, so good caching makes a saving from higher effort harder.

There is an honest counterexample. If little output re-enters the context (v = 0), then with the long uncached context high is already cheaper per solved task at equal turns, $22.54 against $23.48, because input dominates and the better success rate outweighs the small rise in cost per attempt. Cached, the same case still needs high to cut 5.7 turns.

The third route is a context that grows more slowly. If higher effort made fewer failed tool calls or read narrower slices of files, less tool output would enter the context each turn; the turns table above holds that at 1,500 or 6,000 tokens for both levels. Holding turns at 30, high matches low on the long context if its tool results add 4,987 tokens a turn instead of 6,000 uncached (17% less), or 1,308 cached (78% less). On the short context no cut is enough: even with no tool results at all, high would cost $7.15 per solved task uncached against low's $6.50, and $2.19 cached against $1.27.

The simplification has limits. The task shape is invented, the success rates come from a different task, and retries are assumed independent, while Anthropic's own escalation data (below) implies failed tasks are harder and costlier than average. The model does not predict your costs; it tells you what to measure (turns, and context size per request) and how large a change would matter.

What published measurements show

Published measurements of effort levels, from Anthropic and from independent testers, mostly show turns, tool calls and input tokens rising with effort rather than falling, and accuracy gains that range from none to large, usually shrinking and costing more per point at each step up. Vendor and independent results use different models, tasks and harnesses, so they are kept apart.

Anthropic's own sweeps (vendor-reported)

Anthropic calls the results on its cost and intelligence page "Anthropic-internal... and directional, not guarantees". The largest is Claude Opus 5.5 on a 478-problem SWE-bench Pro subset, run on 19 and 20 September 2026: two runs averaged at low, medium and high and one at xhigh, a 16,384-token output cap per turn, and metered pricing with a five-minute cache. Anthropic says the scores are not comparable to the public leaderboard. We label numbers like these "measured, by the vendor", for the reasons in our note on grading AI claims. Our analysis of coding benchmarks that leak their answers explains why a SWE-bench Pro score is hard to compare unless its setup says how Git history and the network were handled.

Level	Solved	Cost per task	Cost per solved	Cost per extra point
low	87.4%	$0.11	$0.126	n/a
medium	92.8%	$0.21	$0.226	$0.019
high	95.3%	$0.29	$0.304	$0.032
xhigh	96.7%	$0.74	$0.765	$0.321

Solved and cost per task are Anthropic's figures (vendor-reported). Cost per solved, and cost of each extra percentage point when stepping up one level, are our arithmetic on those rounded figures; Anthropic's text gives $0.12 and $0.22 per solved task at low and medium.

Each step bought fewer points than the last, the high to xhigh step cost about 17 times as much per point as low to medium, and cost per solved task rose at every level.

The other sweeps are flatter. On Claude Fable 5, across WideSearch, DeepWideSearch, BrowseComp and GDPval (runs from 26 July to 3 August 2026), Anthropic reports that low gave up 1 to 3 points for a third to a half off the cost, and medium matched the default at 70% to 87% of the cost. On DeepResearch Bench II (three runs, 26 and 27 August 2026), Anthropic says Claude Fable 5.1 "scored nearly the same at low, medium, and high while the cost per task rose from $4.66 to $7.12".

Independent measurements

The strongest independent evidence on effort and cost per solved task is a preprint by Weinberger and Hozez of PointFive, a company: arXiv 2608.01347, v6, 10 September 2026, not peer reviewed. Its Appendix N ran Claude Code 2.1.220 at low, high and xhigh on a frozen slice of 25 hard SWE-bench Verified tasks, scored by the official evaluator, with a preregistered gate requiring low to succeed on 30% to 80% of tasks for at least one model. The authors report: "xhigh versus low added 12-16k thinking tokens and 23-30 turns and increased billed cost by 2.4-4.5×." Turns went up, not down.

• Claude Opus 5: 17, 18 and 16 of 25 resolved at low, high and xhigh, at $0.75, $1.89 and $3.62 per resolved task.
• Claude Sonnet 5: 12, 19 and 17 of 25, at $1.76, $2.32 and $3.00. The high against low comparison had seven rescues and no regressions (p = 0.016).

On Sonnet 5, then, effort bought real accuracy and still raised the cost of each resolved task. The public repository the paper cites was not listed on GitHub on 28 September 2026, so we could not confirm the effort data is public.

Trilogy's test from the opening, with harness-reported tokens and no quality scoring, adds three details. Tool operations rose with effort, xhigh making 1.14 and 1.89 times as many as medium on the two tasks. Fewer failed tool calls, the mechanism the third route needs, did appear: on the staff-table task xhigh averaged "fewer than five tool errors per run, compared with ten at medium", yet used 1.76 times the tokens. And output was only about 0.5% of total tokens: "Most of that volume is accumulated input, including cached context". The author concludes it "gives us no basis for choosing xhigh to save tokens... leaves the quality tradeoff open."

Artificial Analysis gives the broadest view. Its Intelligence Index v4.3.2 combines ten evaluations, with agentic tasks run in its published Stirrup harness, and its comparison pages (accessed 27 September 2026) report scores, token counts and cost to run the index for each effort variant. Dollar figures apply a typical cache-hit rate for each model to measured token counts, so token counts are the sturdier comparison; the aggregate says nothing about any one workload. Levels are not comparable across models, so each gets its own table.

Opus 5.5 level	Index	Run cost	Input tokens	Cost per extra point
low	42.3	$860	0.66B	n/a
medium	51.2	$1,627	1.80B	$86
high	53.6	$2,172	2.62B	$233
xhigh	56.0	$4,057	5.96B	$782
max	57.6	$8,708	10.98B	$2,854

GPT-6 Sol level	Index	Run cost	Input tokens	Cost per extra point
no reasoning	28.1	$448	1.10B	n/a
low	33.9	$268	0.34B	n/a
medium	39.8	$417	0.60B	$25
high	42.8	$610	0.94B	$63
xhigh	44.1	$865	1.31B	$200
max	47.5	$1,550	2.55B	$200

Artificial Analysis data (independent). Cost per extra point is our arithmetic: run cost per index point, stepping up one reasoning level.

From low to max, Opus 5.5 went from 42.3 to 57.6 for 10.1 times the run cost, and Sol from 33.9 to 47.5 for 5.8 times. On both, input tokens rose at every step between reasoning levels: more effort meant more context read, the opposite of the saving mechanism. Gemini 3.8 Flash has priced data for only two levels; from medium to high it gained 1.16 points for 1.48 times the cost.

The one independent case of more reasoning costing less is in the Sol table. Sol at low cost 0.60 times as much to run the index as Sol with reasoning off ($268 against $448), read 0.31 times the input tokens and scored 5.8 points higher. Artificial Analysis gives no cause. Fewer turns or shorter trajectories is our inference; if right, it is the saving mechanism from the break-even section, seen once, at the step from no reasoning to some.

synthorai, a commercial publisher, ran GPT-6 Astra (posted 7 September 2026) on 11 tasks with known answers, three runs each, through a Chat Completions-compatible endpoint not stated to be OpenAI's own, and it reports that endpoint accepting none on Astra, which OpenAI documents as returning HTTP 400. Every level from low up scored 33 of 33, and on the five hardest tasks max cost 2.29 times as much per call as low.

No source we found shows higher effort cutting turns past the break-even on a long-context agent workload, and none reports context size per request by level, so none isolates the slower-growth route. None is a large, quality-scored sweep on OpenAI's or Google's API with published raw data.

Running low first and re-running failures at higher effort

In Anthropic's own test on Claude Opus 5.5, running every task at low and re-running only the failures at high solved about 97% of tasks for about $0.17 each, against 95.3% for $0.29 with every task at high. It used the same SWE-bench Pro subset as the sweep above, with results computed task by task, counting the failed first attempt, and ranging from 96.4% to 97.5% across run pairings. By our arithmetic on these vendor-reported figures, that is $0.175 per solved task against $0.304 for all-high.

It works because the cheap first pass handles the 87% of tasks that pass at low, and the expensive level is paid only on the rest. Anthropic warns against crediting the higher level with the gain: "Most of the small lift is the second attempt (re-running the failures of one high run at high scores about the same, for more money), so use this policy for the saving, not the lift". And "every first-pass failure takes two runs' worth of wall-clock time".

Our consistency check suggests the failures are not ordinary tasks. On Anthropic's averages, the escalation would cost about $0.15 and, if failed tasks were typical, solve 99.4%. The reported $0.17 and 97% imply, by our inference, that a failed task cost about 1.6 times an average task at high and that about three quarters of failures were rescued.

The pattern needs a reliable failure signal: tests that pass or fail, or a grader you trust. It also differs from escalating early on signs of difficulty, which PointFive simulated on its static runs and found "did not improve the observed cost-success frontier".

Switching levels inside a session has its own cost. On Claude, a top-level effort change "invalidates cache breakpoints". Anthropic measured Claude Sonnet 5 sessions that started at low, then switched to the default effort and added a tool (vendor-reported): $0.95 per session with both changes mid-session, $0.75 with both on the first request after compaction (a $0.20 difference, 95% confidence interval $0.11 to $0.29) and $0.92 on the request that triggered compaction. OpenAI logs a cache miss with the reason reasoning_effort_changed. Each offers a workaround: Anthropic's per-message effort beta (header mid-conversation-output-config-2026-07-01, on Fable 5.1, Mythos 5.1, Opus 5.5 and Opus 5) and OpenAI's configuration_update input item (GPT-6 family, standard single-agent mode, not with automatic compaction or truncation). Gemini documents neither. A re-run in a fresh session pays its own cache writes anyway.

How to test effort levels on your own workload

A useful effort sweep compares cost per solved task, not cost per token, on your own tasks, with everything except the effort level held fixed. We did not run one; this is the method the evidence suggests. Our extraction test of six cheap models later ran a small version on short documents: turning reasoning down cut cost and latency on all four models that reasoned, and accuracy held on two of them.

1. Fix everything else. A dated model snapshot, the prompt, tools, harness version, a generous output cap and the cache configuration. Give each level its own session, because changing effort breaks the cache on Anthropic and OpenAI.
2. Choose tasks the lowest level sometimes fails. PointFive gated its campaign on low succeeding 30% to 80% of the time; tasks that always pass at low measure only overhead. Include your hardest tasks, since failures cost more than average.
3. Log every request. Record each usage field (uncached input, cache reads, cache writes, output, reasoning or thinking tokens, named as in the first table), plus turns, tool calls, context size per request (the sum of its input fields), wall time and pass or fail from a fixed grader. Price each token class at its own rate.
4. Repeat. At least two or three runs per task and level. Of ten PointFive tasks solved at only one level, six were solved at both on rerun, and a single-author preprint, Moon, arXiv 2608.16956, found per-call cost on Claude Sonnet 5 at one nominal setting had a 95th percentile about six to eight times its median. That paper is not effort evidence: it compares an explicit high with the omitted default (also high on Sonnet 5), which Anthropic says behaves identically, and its author warns it "must not be read as evidence that high effort buys nothing".
5. Read it the way the break-even does. Compare cost per solved task per level, paired by task, with intervals. Check each level's turn counts and context growth per turn against the break-even for your context size and cache hit rate. Then simulate escalation from the same runs: take the low result, else the high result, and pay for both.

A rule for choosing a level

Treat an effort level as a multiplier on the price of each attempt, not as a token budget. Put the per-request hard limit where the vendors put it, on max_tokens or max_output_tokens, and set it generously. On Claude, a task budget steers a whole loop but is advisory; on Managed Agents, a session budget is the hard stop for a run, and a workspace spend limit is the backstop.

Raise the level for a class of tasks only when your own runs show cost per solved task falling: success rising by more than cost per attempt, turns falling past the break-even for your context size and cache hit rate (from about one turn in 30 to nearly half in the example above), or the context growing enough more slowly to cover the extra output. On the measurements published so far, expect turns and input to rise with effort, not fall.

If you can tell reliably when a task has failed, start at the lower level and re-run failures higher. Do not change the level inside a running session unless you use Anthropic's per-message beta or OpenAI's configuration_update; failing that, Anthropic's Sonnet 5 measurement (five or six sessions per arm) points to the first request after a compaction, not the one that triggers it.

The question that would change this advice is still open. We found no independent, quality-scored sweep on a long-context agent workload in which higher effort cuts turns or context growth. If one appears, the break-even condition says exactly how large a cut it has to show before it saves money.