Fable 5 Effort Levels vs Switching Models: When to Dial and When to Change

Last updated: July 29, 2026

Two dials on Fable 5 both trade cost for capability, and it is easy to reach for the wrong one. The effort parameter (low through xhigh) changes how much a given model thinks and how many tool calls it makes. Switching models - Haiku to Sonnet to Opus 4.8 to Fable 5 - changes which model is doing the thinking at all. They solve different problems, and using one to fix the other either wastes budget or leaves quality on the table.

Short Answer#

Why These Are Different Levers#

Per Anthropic's effort documentation, effort does not change which model answers - it changes how much of that model's own capability gets spent on a given response: more or fewer tool calls, more or less thinking, more or less explanation. It is documented as "a behavioral signal, not a strict token budget," and critically, it does not change the per-token price. Fable 5 bills $10 per million input tokens and $50 per million output tokens at every effort level from low to max - the full breakdown is in Fable 5 effort levels explained.

Model choice is a different axis entirely. Fable 5 costs exactly double Opus 4.8 ($10/$50 vs $5/$25) and roughly ten times Haiku 4.5, per the pricing math worked through in the Fable 5 vs Opus 4.8 decision guide. That guide's headline number - 80.3% on SWE-Bench Pro for Fable 5 versus 69.4% for Opus 4.8 - is a capability gap that no amount of effort-dial tuning on Opus 4.8 will close, because effort only reallocates a model's existing ceiling, it does not raise it.

Put plainly: effort spends more of what a model already has. Switching models buys a different ceiling. If a task is failing because the model's plan is shallow at every effort level you have tried, that is a model problem. If a task succeeds at high but wastes tokens doing it, that is an effort problem.

When to Move the Effort Dial#

Anthropic's own guidance, summarized in the effort-levels breakdown, is to start Fable 5 at high (its default) for most work and reserve xhigh only for the most capability-sensitive workloads - the docs note that Fable 5's lower effort settings "often exceed xhigh performance on prior models." That is a specific claim worth taking seriously before assuming a task needs the dial maxed. If you only need xhigh for one hard turn, Claude Code 2.1.311 lets ultrathink raise a single turn to xhigh without changing your saved level.

The clearest low-effort use case is anything high-volume and low-stakes: subagents, classification, quick lookups. The Fable 5 orchestrator playbook makes the same point from the model-routing side - pay the frontier rate where errors compound (the orchestrator) and the commodity rate where they do not (workers). Running workers at low effort while the orchestrator sits at high or xhigh is, per that guide, "the cleanest cost win available" precisely because it is a same-model, different-dial decision, not a model swap.

The math behind why this matters: a worked example in the effort-levels post shows roughly a 7x cost spread per turn between low and xhigh on the same model, purely from output token volume - thinking tokens bill as output even when hidden from view. That spread compounds fast across a long agent run, which is why effort deserves its own line item in a cost-per-task analysis rather than being lumped in with model choice.

When to Switch Models Instead#

Effort has a ceiling: it reallocates a model's existing capability, it does not add new capability. Once you are running the strongest model you have access to at xhigh and the output is still shallow or wrong, there is nowhere further to turn the dial - the next lever is a stronger model. That is the situation the Fable 5 vs Opus 4.8 guide is built to resolve: it scores task profiles against the benchmark gap so the model-swap decision is not instinct.

The inverse also holds. If a task profile is simple enough that a cheaper model handles it reliably, running Fable 5 at low effort still bills Fable 5's per-token rate - you get the token-volume savings of low effort, but not the price-per-token savings of a smaller model. Those two savings stack independently: cheap model plus low effort beats either one alone for genuinely low-stakes, high-volume work.

Fable 5 with its 1M token context window is a related but separate axis again - see Fable 5 with 1M context in practice for when window size, not effort or model tier, is the actual constraint.

Reading Your Usage Window Before You Decide#

Both levers draw against the same 5-hour rolling usage window Claude Code enforces. If you are watching that window burn down fast, effort and model choice are the two places to look, in order: first check whether tasks are running at higher effort than they need (the free lever, since it costs nothing to try medium before xhigh), then check whether tasks that do not need a frontier model are routed to one anyway. The Claude Code usage limits playbook covers the operational side of that - routing, guardrails, and workload shaping - in more depth than the pricing math alone.

FAQ#

Does raising effort ever substitute for switching to a stronger model?#

Sometimes, up to a point. Raising effort from high to xhigh on the same model gives it more room to think and more tool calls before answering, which recovers some quality on marginal cases. But it cannot exceed that model's ceiling - Opus 4.8 at xhigh still does not reach Fable 5's benchmark scores, because effort reallocates existing capability rather than adding new capability.

Does lowering effort ever substitute for switching to a cheaper model?#

No, not on price-per-token. Effort changes token volume, not the rate. A frontier model at low effort still bills the frontier per-token price; it just generates fewer of those tokens. If the actual goal is a cheaper per-token rate, that requires a model swap, not an effort change.

Should the orchestrator and workers in a multi-agent fleet use the same effort level?#

Usually not. The common pattern from the orchestrator playbook is a frontier model at high or xhigh for the orchestrator, paired with cheaper models at low effort for workers - two independent dials (model tier and effort) both turned down for the low-stakes seats.

Continue Reading#

• Fable 5 Effort Levels Explained - the full breakdown of what each level changes and costs
• Fable 5 vs Opus 4.8: When to Use Which - the benchmark and cost data behind the model-swap decision
• How to Model Fable 5 Costs Before They Blow Up Your Budget - building a real cost model across both levers
• Claude Code Usage Limits Playbook - the operational side of routing and the 5-hour window
• The Fable 5 Orchestrator Playbook - one frontier model managing cheap workers, the model-tier version of this same tradeoff
• Claude Fable 5 - pricing, limits, and alternatives on one page
• Claude - the full model family you would switch between

Sources#

• Effort parameter - Anthropic docs - effort levels, availability, defaults, tool-use behavior
• Pricing - Anthropic docs - per-model token rates and cost optimization guidance
• Fable 5 prompting guide - Anthropic docs - delegation and orchestration behavior
• Claude Fable 5 and Claude Mythos 5 - Anthropic announcement - launch benchmarks and pricing confirmation