Claude Fable 5.2 Effort Levels, Explained

Claude Fable 5.2 effort levels are the single biggest lever on what a run costs and how good the answer is, and the control is one subscribers can actually change on what a run costs and how good the answer is: the Claude apps expose a thinking/effort control, and the API has five levels (low, medium, high, xhigh, max) with high as the default. The community shorthand "don't run Fable on max" is mostly right, and the reason is arithmetic.

Anthropic's effort documentation defines the mechanism plainly: each step up lets the model spend more tokens for deeper, more thorough work (the effort docs). On Fable 5.2 all five levels are available, adaptive thinking is always on, and thinking tokens bill at the output rate, so effort is a cost dial before it is a quality dial.

Key Takeaways:

• Five levels exist: low, medium, high (Fable's default), xhigh, max
• Higher effort means more thinking tokens, more tool calls, more cost, all billed as output
• One public test spread a single prompt from $24 to $642 purely by raising the setting
• Max is for correctness-critical work; most tasks belong at high or below
• Prompt lines like "just answer directly" do not suppress thinking at medium and above

Where subscribers can actually change effort

The gate question for this article was whether effort is an API-only concern, and it is not: Anthropic's help center documents a consumer-facing control in "Change the model, effort, and thinking settings" (support article). On the Claude apps, the effort/thinking selector sits alongside the model picker where the product exposes it; on the API, output_config.effort sets it per request. On Zentor, you never set it at all: Auto weighs depth against cost per turn, which is what most people hand-tuning effort are approximating anyway (the integration page).

What each of the Fable 5.2 effort levels buys

Effort applies to everything the model emits: the answer, the thinking behind it, and every tool call in between.

• low: minimal thinking, terse answers, cheapest. For extraction, classification, simple Q&A.
• medium: a real reasoning pass without going deep. Opus 5.5's default lives here.
• high: the Fable 5.2 default. Spends what the task needs for a strong result; right for most serious work.
• xhigh: long-horizon runs, pitched at agentic tasks running 30+ minutes.
• max: uncapped. The model spends what it judges necessary, including spawning subagents to review its own work, a behavior Anthropic documented at xhigh and max that earlier models did not show.

The cost curve, measured publicly

The best public measurement is @0xRhinoX's sweep of a single iceberg render prompt, using his own labels for each step up: $24.31 and 1h 05m at High, $43.79 at the next step, $87.99 at Max, and $642.42 over 10h 21m at his top setting (post). Same model, same prompt, a 26x spread on price and 10x on the clock. The quality gain was real, the top run added an aurora the High run missed, but the poster's own "is it 26x better" is the question every buyer should ask.

Where each level belongs

• Everyday questions, summaries, lookups: low or medium. Paying high-effort prices for a definition is waste.
• Serious work, drafting, analysis, normal coding: high, the default, and mostly you do not touch it.
• Long agentic runs that justify hours of compute: xhigh.
• Genuinely hard, correctness-critical problems where a wrong answer costs more than the run: max, deliberately, not as a habit.

The trap is treating max as "the good one." It is not a quality tier so much as a blank check, and the iceberg test is what a blank check looks like.

Effort vs thinking: the mental model

Adaptive thinking is the engine (always on); effort is the throttle. You cannot turn thinking off on Fable 5.2, asking for thinking: disabled returns a 400 on the API, so effort is the only legitimate way to quiet it. And per Anthropic's migration notes, prompt lines like "answer without deliberating" fail to stop thinking at medium and above, so do not rely on wording to control spend.

Effort and your allowance

Higher effort burns the same allowances faster: more thinking tokens, longer runs, more draw on the five-hour and weekly windows and on the separate Fable limit. That is the mechanical reason Pro users hit "usage limit reached" quickly at launch, as the usage-limit mechanics elsewhere in this cluster walk through.

A decision rule that survives the bill

Start everything at the default. Drop a level for shallow, high-volume work where the spend is visible. Raise one notch when output actually misses, not as a pre-emptive habit. Check the usage draw after the first runs: the gap between levels shows up on the meter before it shows up in quality.

Effort is calibrated per model

The docs are explicit that effort is calibrated per model, which makes cross-model comparisons slippery. High on Fable 5.2 is not high on Opus 5.5, and neither equals Sonnet 5.5's default high. The practical reading of Anthropic's table: Opus 5.5 and Haiku 5.5 default to medium, everything else defaults to high, and max is available nearly everywhere but only justified at the top of the stack. A benchmark quoted at xhigh for Fable, like the 49.1% FrontierCode figure, tells you nothing about what xhigh costs on another model.

How effort interacts with caching and batch pricing

Effort does not change the price per token; it changes the number of tokens. That distinction matters because the levers stack: a medium-effort run with a warm prompt cache and a batch discount can cost a tenth of a max-effort interactive run, and all three compose. Teams that only tune the effort dial and ignore cache stability leave the easy half of the savings on the table.

There is also a latency corollary nobody prices in. High and xhigh runs wall-clock for tens of minutes; on interactive work the user pays for that wait twice, once in tokens and once in attention. Fast mode exists precisely for that case at double the token price, and on interactive workloads it can be cheaper in practice than watching a high-effort run crawl.

The "don't use max" claim, tested against the posts

The viral version of the advice says never touch max. The posts themselves say something narrower: never touch max on a prompt you have not priced. The top run of the iceberg sweep produced the best image of the set; the objection was the $642 invoice, not the output. And a separate max-effort run that burned $5.13 on planning and wrote no code was a planning-loop failure, not a capability failure.

The calibrated rule: max when the task's failure costs more than the run's ceiling. Everything else, high is already the ceiling you are paying for by default.

Effort for agents, not just chats

Everything above reads naturally as a chat setting, but the stakes multiply in agent work because effort also scales tool calls. A max-effort agent run does not just think longer; it issues more tool calls, delegates more, and at xhigh and max on Fable 5.2 will spawn subagents to review its own output, each billed at output rates. Anthropic's migration notes flag this self-review behavior as new to 5.2, and it is the mechanism behind the largest launch-week invoices. For API builders the cheapest architecture is a router that starts each task at the default and escalates only specific turns, which is the same thing Zentor's Auto does per turn without the plumbing.

Fable 5.2 effort levels across the product surfaces

The same five levels surface differently depending on where you work. In the API, output_config.effort is set per request and per-message effort is in beta. In the consumer apps, Anthropic documents the control in the thinking-settings help article. On Zentor there is no dial at all because Auto weighs depth against cost per turn, which is the behavior most people hand-tuning effort are approximating anyway.

Where effort shows up in real failures

The launch-week failure stories map onto effort choices more than onto the model. A Pro user who ran one prompt at default high and watched a chunk of the weekly allowance vanish was paying for thinking depth on a task that may not have needed it; an agent run that hit hours of wall-clock at xhigh was a deliberate blank check. The posts that got the model right are the ones matching effort to consequence: high for the tasks that matter, medium for everything else, and the top settings only when a wrong answer costs more than the compute.

Calibrating effort across a real week

A week of disciplined effort use looks boring: defaults on for anything that matters, medium for bulk runs where the spend is visible, and max reserved for the two or three prompts a week where correctness is worth a blank check. The community posts that got this right are not the ones with the prettiest output; they are the ones that matched effort to consequence and wrote down the bill.

Effort in the subscription math

For plan-level readers, effort translates directly into the meters covered in the usage-limit guide: higher effort burns the five-hour and weekly windows faster and empties the separate Fable limit on Max and Ultra plans sooner. The same task at medium instead of high can mean finishing the week instead of hitting the cap on Thursday.

The one-line version

If this article had to shrink to a sentence: effort is the bill, not the model, so match it to the task's consequence, keep max for the few prompts that earn it, and let routing handle the rest.

Why the apps and the API disagree on what "effort" looks like

The product layer hides the dial differently per surface, which confuses people comparing notes. The API exposes the raw five-level parameter; the consumer apps fold it into a thinking selector where the product exposes one; Claude Code maps it onto its own reasoning controls; and Zentor removes the choice entirely because Auto weighs depth against cost per turn. When a post says "I ran it at max," the first question is which surface's max, because they are calibrated per model and surfaced differently per product.

What effort looks like on a normal bill

The subscription reader's version of the iceberg sweep is simpler: one heavy run at high effort on a Pro credit meter reads as a percentage of the month's spend cap, while the same run at max reads as a bad week. The five-hour and weekly windows magnify the difference because thinking time, not just token price, is what a long run consumes. A task that would crawl for 10 hours at the top setting is also occupying the session for those ten hours, so the real cost is tokens plus your own attention.

FAQ

What are Claude Fable 5.2's effort levels?

Five: low, medium, high, xhigh, max. High is the default.

Can I change effort in the Claude apps?

Yes, where the product exposes the thinking/effort control; Anthropic documents it in the model and thinking settings help article. On Zentor, Auto manages it per turn.

Is max effort worth it?

Rarely as a default. One public test paid 26x more for a modest quality gain. Use it when correctness outweighs cost.

Can I turn off thinking on Fable 5.2?

No. Adaptive thinking is always on; effort controls how much it spends.

Does higher effort always mean better answers?

Up to a point. Depth helps on hard tasks; on well-specified prompts the extra spend buys little.