Effort Is the New Dial: Routing Skills and Subagents from low to max

On Claude Fable 5, the token budget you used to hand extended thinking is gone. You can't set budget_tokens anymore — the request 400s. In its place is a single, cleaner control: effort. Five levels — low, medium, high, xhigh, max — that trade capability for cost and latency. Setting it well is one of the highest-leverage decisions you make when you build on Fable 5, and it's an architecture decision, not a tuning afterthought.

The reason effort matters so much is a line from Anthropic's own guidance: "lower effort on Fable 5 still performs well and often exceeds prior models' xhigh." Read that carefully. medium on Fable 5 isn't a compromise — it can beat the best setting of the model you're migrating from. Which means the default instinct to crank everything to max is not just wasteful; it's usually unnecessary. As of July 2026, the builders getting the most out of Fable 5 are the ones treating effort as a routing table across their skills and subagents.

Key Takeaways

• Effort replaces the token budget. Five levels in output_config: low, medium, high (default), xhigh, max. The old budget_tokens returns a 400.
• Start at high. Route routine tasks and subagents down to low/medium; reserve xhigh/max for capability-sensitive, long-horizon work (runs over ~30 minutes).
• Lower effort still beats prior models' best. medium on Fable 5 often exceeds prior models' xhigh — don't over-spend.
• ultracode isn't a new API level. In Claude Code it's roughly xhigh plus standing multi-agent permission — not a sixth effort setting.
• Route to save money and latency. At $10/$50 per million tokens and minutes-long turns, effort is your main lever on both.

Where effort lives, and what the old knob became

Effort is set inside output_config — not at the top level of the request, which is a common first-migration mistake. Because thinking on Fable 5 is always on and adaptive, you no longer tell it how many tokens to think; you tell it how hard to try, and the model allocates thinking adaptively within that band.

response = client.messages.create(
    model="claude-fable-5",
    max_tokens=16000,
    output_config={"effort": "medium"},   # low | medium | high | xhigh | max
    messages=[{"role": "user", "content": task_prompt}],
)

Two things to internalize. First, high is the default — if you set nothing, that's where you are. Second, there is no budget_tokens fallback; if you're porting code that set one, delete it or you'll get a 400.

The five levels, and what each is for

Anthropic's guidance maps cleanly onto how you'd actually deploy them:

• low — cheapest, fastest. Well-bounded, mechanical work where correctness is easy to verify: classification, extraction, formatting, simple lookups. Great for high-frequency subagents.
• medium — the workhorse for routine tasks that still need judgment. Remember it often exceeds prior models' top setting, so a lot of work you'd have run at high elsewhere belongs here.
• high — the default. Reach for it when you're unsure, or for standard skill execution that isn't trivially mechanical but isn't frontier-hard either.
• xhigh — capability-sensitive and long-horizon work: runs expected to exceed ~30 minutes, hard reasoning, complex multi-file changes, anything where a wrong answer is expensive.
• max — the ceiling, for the genuinely hardest problems where you want every bit of capability and cost/latency is secondary.

A routing table you can copy

Map effort to the role a call plays in your system, not to how important the overall product is. The same agent will legitimately use several levels across a single run.

The orchestrator-and-subagents shape falls out of this naturally. A high or xhigh orchestrator plans the work and fans it out to a swarm of low/medium subagents that do the mechanical parts cheaply and in parallel. You spend capability where the reasoning is hard and save it everywhere else. If you're wiring that up, the subagent side connects directly to how you build agents and workflows.

What "ultracode" actually is

If you use Claude Code, you've seen "ultracode" and probably wondered whether it's a secret sixth effort level. It isn't. Ultracode is roughly xhigh effort plus a standing multi-agent permission — it lets Claude Code operate at high effort while keeping a persistent grant to dispatch and coordinate subagents autonomously. There's no "ultracode" value you pass to the API's effort field.

That distinction matters when you're reasoning about cost and capability. Reaching for ultracode is reaching for xhigh-class thinking and an autonomous multi-agent posture at once. It's the right move for a genuinely hard, long-horizon coding task; it's overkill for a quick formatting fix, where low or medium would be faster and cheaper.

The cost and latency math

Effort isn't free to over-set, on two axes.

Cost. Fable 5 is $10 per million input tokens and $50 per million output tokens — roughly 2x Opus 4.8. Higher effort means more thinking, which means more tokens billed. Running a high-frequency subagent at max when low would do can multiply your bill for zero quality gain — precisely because lower effort here already clears prior models' best.

Latency. Fable 5 takes minutes-long turns at higher effort by default, and autonomous runs can extend for hours. Effort is a direct lever on how long a call takes. A user-facing skill that needs to feel responsive should lean toward low/medium; a background job that can run async can afford xhigh. (When you do run long, adjust client timeouts and use streaming or progress UIs — a topic in its own right across the series.)

The practical rule: default down, escalate on evidence. Start a new skill at medium or high, measure quality on real inputs, and only climb to xhigh/max if the outputs actually need it. Escalating a specific skill is cheap; paying max on every call across your whole system is not.

A worked example: one run, three effort levels

Picture an agent that migrates a mid-size service to a new API. A naive build runs the whole thing at max and pays for frontier thinking on every trivial step. A routed build looks different.

The orchestrator runs at xhigh: it reads the codebase, plans the migration, and decides what to change and in what order — genuinely hard, long-horizon reasoning where a bad plan is expensive. It then fans work out to subagents at low: "find every call site of this deprecated method," "rewrite this file's imports," "extract the changed function signatures." Those are mechanical and easy to verify, so they run cheap and in parallel. When the plan hits a genuinely tricky module — a tangled bit of business logic that resists a mechanical rewrite — the orchestrator escalates that one subagent to xhigh and leaves the rest at low.

The result is that you pay frontier prices only for the two or three calls that actually need frontier capability, and commodity prices for the dozens that don't. This is the shape behind Anthropic's reported proof point of a codebase-wide migration on a roughly 50-million-line Ruby codebase in about a day — routing effort by role is what makes that economical rather than ruinous. Build your own agents and loops the same way: a smart, expensive planner over a swarm of cheap, fast executors.

A quick routing checklist

1. Delete any budget_tokens from ported code — it 400s now.
2. Set effort in output_config, not at the top level.
3. Classify each call by role — mechanical, routine, default, hard, or frontier — and map it to the table above.
4. Start subagents at low/medium, orchestrators at high/xhigh.
5. Reserve xhigh/max for runs over ~30 minutes or where a wrong answer is expensive.
6. Measure, then escalate — don't default to max; climb only when outputs need it.
7. Match effort to the surface — responsive UI calls low, async background jobs can go high.

Where this goes next

Effort is the dial that ties the rest of Fable 5 together. It's how a leaner, less-prescriptive prompt gets the right amount of thinking — pair the prescriptive-skills refactor with a deliberate effort level and you get both room to plan and the compute to plan well. And because higher effort means longer turns, your effort routing decides how much async and fallback plumbing you need downstream — see the fallback-aware agents guide for the reliability half.

Treat effort as a first-class part of your agent architecture and Fable 5 becomes both cheaper and better than a one-setting deployment. Start by tagging every model call in one agent with an effort level from the table, then measure. The full run is at the Claude Fable 5 series hub, and you can find subagent patterns and automation loops to route across /agents and /loops.