Stop at High

In the week before this change, 97% of my harness's recorded spend ran at xhigh or max effort. Everything at high, Sonnet included, got under 3%. Fable, the model Anthropic sells for the hardest work, got nothing.

On November 9 Anthropic published Which Claude model should you build with?, Addy Osmani's guide to choosing between Haiku, Sonnet, Opus and Fable. Its effort rule reads like a comment on that number: past high, one more level "can cost as much as a bigger model." My main session runs at max by choice, for reasons I give at the end. The role table under it, one model and one effort per kind of delegated work, had no such reasons, so I tested the rule with the guide's own method.

This follows My Self-Tuning AI Harness, which described the role table, a benchmark that couldn't yet tell setups apart, and the inbox where the harness keeps its own problems. All of my numbers are API-equivalent estimates at list prices, not bills. Every vendor number is labelled as one.

What the guide actually says

The headline is blunt: "The quick answer is that you should start most work on Opus 5.5 at its default effort level, medium." Opus 5.5 costs $4 per million input tokens and $20 per million output, half of Fable 5.2's $8 and $40, and it's the default model in Claude Code.

The effort rule, in full: "Before you move models, try adjusting your effort level. It's a finer dial for both cost and capability. Past high, one more effort level can cost as much as a bigger model, so compare both on your own work. If you're past high, test the next model up at a lower effort instead." And the limit of the dial: "moving to a higher effort level won't give a model knowledge or skill it doesn't have. For that, you still need to move up a model."

When a model falls short, the guide gives an order: first "Check that the model can verify its own work, with a test, a build or a script that calls the endpoint." Then "Raise effort one level." Then "Move to the next model up, starting at a lower effort level than you used on the smaller one."

The vendor numbers behind it, all Anthropic's:

• xhigh is expensive for what it adds. On SWE-bench Pro, Opus 5.5 at xhigh "scored about 1.4 points higher for 2.5 times the cost of high."
• A cascade beats a high floor. "Opus 5.5 at low with failures re-run at high passed about 97% of tasks for about $0.17 each, against 95.3% for $0.29 with every task at high." The cost docs add the two conditions: "you need a failure signal", because "a checker that passes bad work lets those failures through", and "every first-pass failure takes two runs' worth of wall-clock time."
• At the top, the cheaper model depends on the benchmark. On FrontierCode 2.0, "Fable 5.2 at high scored about level with Opus 5.5 at max (45.3% vs. 45.5%) for roughly half the cost per task." On a SWE-bench Pro subset in the same cost docs, it runs the other way: Opus 5.5 at xhigh is "level with Fable 5.2 at high for a little over half the cost."

That pair is the real case for the guide's method, and it isn't a model recommendation. Two vendor benchmarks disagree about which model is the cheap one at the top, so the only number that settles it for you is one you measure on your own work.

The docs say the same about max from two directions. Claude Code's model configuration: max "may show diminishing returns and is prone to overthinking, so test before adopting it broadly." The API effort guide, on Fable 5.2: "Start with high. Most of the gain in capability is already present at high", and "Reserve max for measuring the model's ceiling and for the rare task where time and tokens don't matter." I wrote about effort and when max loses a few weeks ago.

One kind of work, one model

The guide's own demo shows the routing idea in half a minute.

Fable 5.2 migrates the store from JavaScript to TypeScript, Opus 5.5 builds the subscription, Sonnet 5.5 writes the product pages and Haiku 5.5 sorts the customer messages. The guide's advice for that split is to keep the reasoning out of the router: "When the routing rule is simple, such as one model for each step type, let code pick the model rather than asking a model to."

A role table is exactly that. In my harness each kind of delegated work is a subagent with a model: and an effort: in its frontmatter, generated from one registry, ~/dotfiles/ai/config/models.json. The guide's division of labour fits it: "Keep small models on work where a mistake is cheap to spot, like finding files, running tests and reading logs. Keep code edits and judgment calls on the main model." And it explains why the table matters most for the expensive session: "a lean main context matters more the bigger the main model is."

One trap sits under every role table. Per the subagent docs and model configuration, a subagent on the main conversation's model with no effort: of its own runs at the session's level, and the built-in Explore runs on the session's model. As an earlier Anthropic post, What a task costs on Opus 5.5, puts it: "Every subagent that inherits the main model inherits its price too." That's why my Explore and general-purpose definitions override the built-ins.

Where the spend went

Before changing anything, I priced seven days of the harness's own ledger, to November 10:

Per-run costs are 14-day averages from ai roles status. A role's effort isn't always what runs: a caller can override it per call, so some researcher and implementer spend ran at max. The independent second opinions (ai review) keep their own ledger: about 99,000 output tokens per review, 96% of it reasoning.

By effort, max took 56.5% of the spend and xhigh 40.7%. By kind, cache reads were 48%, cache writes 27% and output 25%; in the biggest groups the mean request carried 200,000 to 285,000 input tokens.

The dollars aren't the constraint, though. On a subscription the binding limit is the weekly bar, and in one recent week it ran out after about five and a half days. A routing change is worth making only if it moves that bar without moving quality.

Four ideas that died on the numbers

Fable 5.2 as the main session

The question was whether to run the interactive session on Fable instead of Opus. For my mix, the same tokens would cost about 1.52 times as much. That's a price ratio, not a measurement: cache reads cost the same $0.20 per million on both models (pricing), while cache writes and output cost twice as much on Fable. The vendor's own orchestration figure points the same way: "Claude Fable 5.2 as the orchestrator in Claude Opus 5.5's place cost 19% more and scored about the same." I priced Fable 5.2 per task the day it shipped.

The plan limit settles it. Fable use is capped at half of the weekly limit, and the interactive session alone was 37.8% of the baseline week's spend at Opus rates, 54.9% over the last thirty days. On Fable, which uses the limits faster, a week that uses the whole limit would hit that cap before it was out and fall back to another model, and the guide spells out what that costs: "The prompt cache belongs to the model that wrote it," and "A move from Fable 5.2 to any other generally available model drops its reasoning."

A one-hour cache for subagents

Claude Code's prompt caching gives subagents a five-minute cache lifetime even on a subscription, and subagentPromptCacheTtl can raise it to an hour. It looks like a free saving. I replayed 24,671 real subagent responses from seven days under both lifetimes: the one-hour cache would have cost 4.5% more. Implementers came out 2.1% cheaper; every other role 12% to 23% more expensive. Only 136 cache rewrites in the whole week came from a five-minute expiry, and a one-hour write costs 1.6 times a five-minute one ($8 against $5 per million on Opus 5.5).

Compacting earlier

The harness compacts at 500,000 tokens. Requests at 300,000 or more were 50.7% of the main session's cost, so compacting at 300,000 looked like a big lever; in the last article I guessed it would cut a long session's cost by about a quarter. Measured over a week, the most it could save in cache reads is about $112, 6.9% of main and headless spend, before paying for the extra compactions themselves. At 400,000 it's about $17.

An advisor on the main session

The advisor tool lets a main model consult a stronger one mid-task. Its read of the conversation is never cached: at about 250,000 tokens of context, each call is about 250,000 uncached Fable input tokens, roughly $2. The one pairing in Anthropic's table whose executor consulted often, Opus 5.5 at high with a Fable 5.1 advisor, scored "1.7 points over Opus 5.5 alone at high for about 2.1 times the money," which the guide calls "about what raising effort would have bought." I covered the pattern in July in Advisor and Executor, with Fable 5 advising Sonnet 5; for a long interactive session the uncached read kills it.

The bench

The harness has a benchmark, ai bench, that runs each role as a real Claude Code subagent on tasks shaped like its delegated work and grades every run with a script, never a model. On November 10 it gained Fable 5.2 cells and prices, marked "measured only": a Fable cell is reported but never picked automatically. Then a sweep for each role I meant to touch.

Implementers, six tasks with hidden tests:

A confirmation sweep with three repetitions, 36 runs, settled it: Opus 5.5 at high solved 18 of 18 at $0.29 a run and a median 71 s; at xhigh, 17 of 17 valid runs at $0.75 and 230 s, with one run excluded by the bench's integrity check. The bench's guarded decision: Opus at high.

Reviewers, five diffs with seeded bugs and decoys, two repetitions:

Scouts, ten read-only search tasks, four of them written that day to be harder, three repetitions:

Verifiers, eight tasks, three of them new and harder (a test that only looks flaky, a CI script that passes for the wrong reason, a failure in a second module), three repetitions:

For implementation, high matched or beat xhigh on every count: one more task solved in the first sweep, the same in the confirmation, at about 40% of the cost and a third of the time. Fable at high cost about three times as much as Opus at high and solved fewer, so it got no implementation role. General-purpose has no bench tasks of its own; it moved with the implementer, on the implementer's numbers, so November 17 is its first real measurement. For review, every cell was perfect, and the price spread was five to one.

For scouts and verifiers, even the harder tasks didn't separate the top cells: Haiku 5.5 at medium scored a perfect 1.000 on both at about a tenth of the Sonnet cost. When the cheapest cell aces everything, the tasks may simply be too easy, so the bench's guard keeps the current row. For the verifier, that row was already Haiku 5.5 at medium, set earlier that day on the guide's advice. The scout stays on Sonnet at high, with Haiku as the candidate for a harder round. Sonnet at medium, Claude Code's default for Sonnet 5.5, solved the fewest scout tasks, 90%.

The limits, stated plainly. Bench tasks are far shorter than real work: a real implementer run averages about 137 requests and $12.98, a bench run cents to a dollar. The first implementer sweep had two repetitions, which the bench's own guard calls "incomplete" and won't act on. I moved the row by hand on it anyway, with a revert rule and a review date, because 12 of 12 against 11 of 12 at less than half the price is not the result that should keep a row at xhigh. The three-repetition confirmation then made it the guard's own decision.

The new role table

The role table after this change, with each rung: the next setup a result climbs to, once, when it fails its check.

Three rules came with it. No ladder climbs to max anymore. A rung needs a trigger: a test, the batch loop's verifier, or the orchestrator checking a delegated result; a row with nothing that can fail has no rung. And the guide's "next model up" stays a candidate, not a default: my bench says Fable doesn't pay for implementation, so the implementer's rung is Opus at xhigh.

The verifier hadn't been used once in the previous 14 days, so real work will be its first test. The batch-loop worker's row is read at call time by a live headless loop, so it moves only once that loop has a row of its own. The goal-loop default came off max but only to xhigh, and the daily improvement worker stays at xhigh, both unattended and above high. That's the honest gap in this change: no bench of mine has tested either one at high yet.

The two review rows are protected: only a recorded decision moves them, never the tuner. The in-session reviewer goes to Opus at high: on the bench above it found every seeded bug, like max, for a fifth of the cost and about a tenth of the time, on two repetitions, so it's provisional.

The formal second opinion, ai review, took a detour first. I ran ai review itself on the same five review tasks, 19 seeded bugs in all. Opus at max, Opus at high and Fable at high each found 19 of 19 and flagged none of the decoys. Opus at max cost $3.96 for the set at a median 288 s, Opus at high $0.62 and 34 s, Fable at high $1.74 and 46 s. Five max reviews that same day filled the 128,000-token output cap and returned no opinion at all.

Max was out. I first put the row on Fable at high, with an Opus fallback, on the guide's step past high, "the next model up at a lower effort," and on the idea that a gate review should come from a different, stronger model than the Opus that wrote the code. It held for about an hour. The next independent review of the routing docs ran on that new row, so Fable reviewed its own seat, and it flagged the stronger-model premise as unmeasured: on those cells Opus at high found the same 19 bugs at 36% of Fable's cost. Under the decision's own rule, a tie goes to the cheaper cell, and my rule for Fable is to spend it only where it pays. The row went to Opus (1M) at high.

Both rows are provisional. On November 17 a harder review bench runs three repetitions, and a recorded decision on it promotes Fable to the second opinion only if it finds more seeded bugs than Opus at high in at least two of them with no more decoys flagged. The numbers are reported whatever the result. After a promotion, a review billed to usage credits, or a higher failure or timeout rate than Opus at high had, sends the row back to Opus at high at once.

Fable, behind a guard

No row names Fable by default, and any Fable row goes through a guard (~/dotfiles/ai/lib/ai/models.py). A Fable entry runs on Fable only while the account has room. It falls back to its row's fallback model when the Fable bar is at 90% or more, the plan has no Fable limit, the usage reading is missing, unreadable or older than six hours, or the weekly limit is at 95% or more. ai exec now runs the same check itself, and retries once on the fallback after a Fable-limit refusal. The bench's tuner never adopts a Fable cell; a Fable row changes only by hand.

For the hardest work there's an explicit front door: ai -m fable starts the interactive session on Fable 5.2, at effort high unless I pass another. When the account has no Fable room it asks first, and Enter means no; without a terminal it warns and launches. A Fable bar sits in the harness's usage view and the statusline. The guide's case for Fable is real, for "the hardest technical projects in coding, finance and the sciences" and "when Opus 5.5 at high still falls short."

Fable's separate limit, explained

The Max plan page lists "a weekly usage limit that applies across all models, and a separate weekly limit for Fable," and the usage settings show two bars, which reads like two allowances. It's one allowance with a sub-cap. The Help Center: "You can use up to 50% of your weekly limit on Fable models, but your use of other models draws from the same usage limits and you can never use more than your weekly limit." Unused Fable allowance is not capacity left on the table.

How much faster Fable drains it isn't published. The plan pages say Fable models use the limits "faster than other Claude models" and give no ratio. API prices suggest at most twice as fast, and less for cache-heavy agent work, since cache reads cost the same on both. That's my inference, not a documented weighting.

The useful exception is the Fable reset from the launch offers. Max, Ultra and premium seats with paid billing in place before the launch get "One to three Fable limit resets, depending on how long you've subscribed." A reset "gives you back the usage you've spent on Fable models. Usage you've spent on other Claude models stays where it is." Anthropic's own example: "say you've used 80% of your weekly limit: 50% on Fable models and 30% on other models. After a Fable reset, you're back to 30% of your weekly limit." The resets "expire on March 8, 2027 at 11:59 pm PT," and you press them in claude.ai under Settings > Usage; per What is a limit reset?, the button isn't available in Claude Code in the terminal. I wrote about free limit resets a month ago; a Fable reset is the narrow kind.

So the rule, while you still hold a reset: in a week you'll exhaust anyway, Fable spending can be refunded, once per reset. The hard work can go to Fable, and a reset pressed near the cap gives that share back. Used early, before much Fable usage, a reset gives back little, and the offer ends with the March deadline.

One more trap, for headless work. In -p mode, per the model configuration docs, "When a Fable request there would bill to usage credits, Claude Code bills it without asking." On a plan with credits on, an unattended Fable run past the cap is a bill, not a refusal. That's why ai exec falls back whenever credits are on.

Headless spend, finally on the ledger

Structured headless workers, the claude -p runs with no session persistence and hooks off, left no transcript, so their spend was invisible to the harness's own reports. Now ai exec reads the final result event of every run with --output-format json or stream-json and records its usage beside the run's reason: tokens summed over modelUsage (which covers subagents and compaction), Claude Code's cost estimate, turns, duration and permission denials, by tool name only. Reading it never changes the child's output or exit code. ai report gained a "headless by reason" table.

It doesn't save a token by itself, and the baseline above predates it: every share in it is a share of the spend the harness could see. It makes the next routing decision measurable.

The inbox

The harness keeps an inbox of its own problems, fed by sessions, a daily news watch, the improvement worker and the unattended article pipeline. The day started with 131 open items: 103 from sessions, 16 from the watch, 9 from the improvement worker and 3 from the article pipeline. During the day 20 more were filed, and by the evening 151 were closed and none was left open. The ones worth knowing about if you run anything similar:

• A search daemon starved at low priority. QMD, the local search over the knowledge base, ran as a launchd Background process. Under load, one query took 31.7 minutes while every other session's query waited behind it. Claude Code also cuts an HTTP MCP request at 60 seconds without a first byte unless the server declares a tool timeout (MCP docs), and QMD answers only when a query is done. Now the daemon runs at Interactive priority, the server is registered with a 300-second timeout, and a nightly cleanup removes orphaned vectors: they had reached 76% of the index, 568,103 were removed, and the index shrank from 4.2 GB to 2.4 GB. How QMD works has the background.
• Headless runs couldn't use it. In claude -p runs the search tools failed: 0 of 4 calls got through. The cause was the server's handling of subscriptions/listen; after the fix, 4 of 4.
• Nine test suites, one machine. Nine implementer subagents ran the full harness suite at once and pushed the machine to a load of 202 on 16 cores; live headless runs timed out. The rule now: at most two full suites at once machine-wide, niced, through two lockf slots, and only the affected test modules while iterating. Parallel agents need the same discipline as parallel sessions.
• @path in a headless prompt is a file read. Claude Code, from 2.1.318, expands @path in a claude -p prompt into the file's contents, even with tools off, so outside text that reaches a headless prompt (an issue, a web page, a diff) could pull a local file into it. The harness now puts a U+2060 word joiner after every @ in outside text it builds into a prompt; a caller's own ai exec prompt passes through byte for byte.
• A PreCompact hook's stdout is a prompt. Claude Code uses it as instructions for the compaction summary and discards its systemMessage. The hook now prints plain instructions: quote the latest requests word for word, then re-read the checkpoint and the request ledger before continuing.
• Background work dies with a headless run. A headless run stops its background shells and agents 10 minutes after its last turn, and their work is lost. The agent definitions now say: foreground only.

What happens on November 17

The change has a review date: November 17, one week out. What gets compared:

• per-role cost per run against the baselines above: implementer $12.98, general-purpose $6.61, reviewer $7.53;
• for the second opinion, a harder review bench, three repetitions, Fable at high against Opus at high;
• how often each rung fires, and how many delegated results fail their checks;
• the weekly bar per active day, because that's the limit that binds;
• the Fable bar's change per Fable run, if there are any, the first real measurement of how fast Fable drains it.

The revert rule is per role. If, over the week, more than two of a role's delegated results fail the main session's check, or its escalations pass 15% of its runs, the implementer or general-purpose row goes back to xhigh, and the reviewer row moves up to its xhigh rung. One commit reverts the rows. It doesn't revert the docs or the goals created under the new defaults, which keep the settings they were created with.

What didn't change, and why

The interactive session stays on Opus 5.5 at max. That one is my decision, made on October 25, and it's the floor the tuner may never lower. The guide disagrees: it starts Opus at medium, and Anthropic's Spending your effort gives max to the opposite case, "When I want Claude to operate fully autonomously to solve difficult problems." I keep it anyway, for two reasons. I'm in that loop, reading every turn, so overthinking costs me time I can see and stop. And in the last article's measurement, all the thinking at max was about 8% of the main sessions' cost while context was 84%. Max is session-only in Claude Code, so ai passes --effort max at every launch.

Compaction stays at 500,000 tokens, subagent caches stay at five minutes, the advisor stays off. Each lost on the numbers above.

Fable stays out of every default. On my measurements it tied Opus at high on review at 2.4 to 2.8 times the cost and solved fewer implementation tasks for more. It stays a deliberate launch for the hardest work, ai -m fable, and a way to use a Fable reset. That's narrower than the guide's table, which also gives Fable "leading many subagents" and deep research; Anthropic's own cost docs measured it at "2.9 times as much as Claude Opus 5.5 for a score 1.9 points lower" on deep research.

Until this week my role table had no bench that could say whether its expensive rows earned their price. In every sweep, a cheaper cell scored as well as the dearest. Six rows now cost less: the implementer, general-purpose, verifier, goal-loop default and both reviews. November 17 decides which stay there.