Claude Models and Effort Levels: What Actually Changes, and What It Costs

On nine of our own finished tasks, Claude Opus 5.5 got steadily better as we raised its effort level: from 80 % of the maximum score at low to 89 % at medium, 94 % at high and 98 % at xhigh. The cost per run grew from 0.57 times that of medium to 1.40 times at high and 3.42 times at xhigh. Fable 5.1, the largest model, cost about as much as Opus at xhigh and scored like Opus at low. Sonnet 5.5 scored the same at medium and high; high only doubled the price.

We ran 139 tests on 5 November 2026, on API credit, for $79.98 at list price. The tasks are real work we had already solved, so the correct answer was known before any model saw them. The tests ran Claude models through Claude Code, a Claude model graded part of the outputs (more on that below), and Claude also helped edit this article. Models change fast: every number here is dated 5–6 November 2026.

The results at a glance

Why did we run these tests?

We had been working with the recommended defaults: the newest top model, first at medium effort and lately at high. Our impression from daily work was that Opus 5.5 beats Sonnet 5.5 on coding and debugging, and that Fable 5.1 does not feel clearly smarter than Opus. An impression is not a reason to pay several times more, or less.

Anthropic publishes benchmark numbers, but they are measured on Anthropic’s tasks, and they are spread over model cards, documentation pages and launch posts. We wanted three things they cannot give us: results on our own kind of work, the cost of a usable result rather than of a request, and a clear picture of what the effort setting actually changes.

Our own usage logs made the question concrete. Over 30 days of our daily Claude Code work we sent 13,235 requests. On Opus at high, 45 % of the cost was cache reads, 33 % cache writes and 22 % output. One finding came before any model test: a memory plugin, meant to cut token use, accounted for about a quarter of the list-price total on its own. It is off now. That is the same lesson as in our Kubernetes cost reviews: measure first, because the biggest line is often not the one everybody argues about.

How did we test?

Nine tasks from our own finished work

Task 5’s input is a reconstruction: the original job log no longer exists, so we rebuilt the bundle from the saved plan, node and alert. Tasks 5 to 8 had no shell and no network, only the files listed in the prompt.

Eight settings

max stayed out because of the budget. The automatic tasks ran three rounds per setting. The blind tasks ran once, plus the repeats described below.

How the runs were isolated and graded

• Every run was a non-interactive Claude Code call in a bwrap sandbox: read-only root, empty home directory, one writable work directory, and a separate API key with its own spend limit.
• Claude Code’s --bare mode drops hooks, plugins, project instructions, memory and MCP servers, so the settings compare like with like. It also means this is not exactly our daily setup.
• Each run had a cost cap: the pilot run’s cost × the expected price multiplier of the setting × 3, at least $1. One run broke the pattern: Fable’s third round on task 7 ran with a $12 cap instead of the formula’s $19.80, because the formula would have pushed us over our $90 ceiling. It cost $4.62.
• Blind grading. The outputs of tasks 5–8 were renamed to random letters, and the key stayed closed until grading ended. The checklists were written and approved before any run, and not changed afterwards.
• Scale: 2 = usable unchanged, 1 = usable after at most 10 minutes of fixing, 0 = has to be redone.

What is the effort level, and what is it not?

Effort is one request parameter with five values: low, medium, high, xhigh and max. According to Anthropic’s effort documentation (checked on 6 November 2026; defaults change between model generations), it affects every output token: the text, the tool calls and their arguments, and the thinking. At lower effort the model makes fewer and more consolidated tool calls, and on simple problems it may skip thinking entirely.

• It is a signal, not a budget. The documentation calls it “a behavioral signal, not a strict token budget”. The hard limit on output, thinking included, is still max_tokens.
• The model decides how much to think. On the current models thinking is adaptive, and on Opus 5.5 it cannot be switched off at all, so effort is the main control over reasoning and cost.
• Defaults differ. Opus 5.5 and Haiku 5.5 default to medium; Sonnet 5.5 and Fable 5.1 to high. Sonnet 5.5’s levels were recalibrated, so high there does not mean what it meant on Sonnet 5.
• xhigh is meant for long work. The documentation describes it as “long-running agentic and coding tasks (over 30 minutes)”. Our runs took between 10 seconds and 15 minutes.
• Changing it mid-conversation can break the cache. A new top-level value starts the prompt cache over; the newest models also accept a per-message change that keeps it.

List prices per million tokens, input / output: Haiku 5.5 $0.10 / $0.50, Sonnet 5.5 $2 / $10, Opus 5.5 $4 / $20, Fable 5.1 $10 / $50 (Anthropic pricing).

What effort is not: a lesson from our own fine-tuned model. In our free-droid project we fine-tuned Llama 3.1 8B and Llama 3.2 3B models into a Hungarian-speaking persona for a small robot, over 14 versions. None of the levers there is a “think harder” dial. Behaviour comes from the weights the fine-tune produces, from the data that goes into it, and from the system prompt; facts come from a retrieval layer; and the rules the model must never break (answer only in Hungarian, stop the motors on an obstacle) are enforced in code, not in the weights. The levers that moved the result were dataset design and changing one variable per round, not hyperparameters.

Effort is a different kind of control. It does not change what the model knows or how it behaves; it changes how much of its reasoning and tool use it spends on a request. That is why it is cheap to try: a fine-tune round took us hours and a new evaluation, while an effort change is one word in a request. (The comparison is our interpretation; Anthropic does not describe effort this way.)

What did the tests show?

Every task, every setting

Automatic tasks show passed runs out of all runs; blind tasks show the score of each run (0–2). After the dot: the mean cost per run.

Per setting

Quality is the mean over the tasks a setting ran (pass = 1, fail = 0; blind score ÷ 2). One round is the sum of the mean costs per task: what all nine tasks cost once.

The Opus effort curve

Cost per run against Opus 5.5 at medium, and the mean thinking tokens per run from low to xhigh.

The step from high to xhigh is the expensive one: thinking tokens grew three to seven times, the cost about 2.4 times and the wait about three times. On our tasks it bought one thing: the only flawless English article. Everything else xhigh got right, high had already got right.

Where the points were lost

Task 1, Sonnet (0 of 6 runs) and one Opus xhigh run: wrong by the rules, right about the code. Every Sonnet run fixed the 10 links and also changed the shared function that builds blog post URLs, which was outside the task, so the pre-registered check failed it. The change itself was correct: post cards in our site generator really did link without the trailing slash, and every such click costs a redirect on Cloudflare Pages. We filed it as a ForgeStack issue. The score stays a fail, because a model that edits code it was not asked to edit is a problem even when it is right. Read the diff before you trust a red light, in either direction.

Articles (tasks 6 and 6a): every setting except the top ones left something to fix. The typical fix was an invented detail that was not on the fact sheet (a date, a cause, “single-node”, “cold backups”) or a claim inflated beyond its source (“a dozen” became “dozens”). Fable had the most: 9, 5 and 2 invented or wrong claims in its three English runs, and 5 in the Hungarian one. In Hungarian, Opus high was the cheapest setting with no language error, no calque and no invented claim.

SEO analysis (task 7): the losses were numbers. Fable mixed page-level and query-level clicks in one table without saying so in all three runs. Its reports also rounded 277 tag-page impressions down to “about 200”, reported the queries’ 45 clicks as 46, and wrote “every product has the same date” where 83 of 92 had. The two Sonnet runs that scored 1 had the same kind of slips. Opus at low scored 2 here for $0.38.

Security review (task 8): Opus low and two of Fable’s three runs gave too much weight to minor findings, miscounted or claimed more than the capture proved. No run refused the task.

Diagnosis (task 5): every setting found the real cause, a node taint with a missing toleration, and none blamed the misleading TLS errors. The task was too easy to separate the settings.

Repeats: one false alarm, one real weakness

We fixed one repeat rule before the runs: if a higher effort on the same model scored worse than a lower one, run both again. That hit Sonnet on task 7 (high 1, medium 2). Two more rounds gave medium 2, 2, 1 and high 1, 2, 2. The inversion was noise.

Outside the rule, we gave Fable two extra rounds on tasks 6, 7 and 8, because “the largest model is weaker” is a claim that needs more than one run. Task 6: 1, 1, 1. Task 7: 1, 1, 1. Task 8: 1, 1, 2. The weakness held.

Who graded the graders?

Task 5 was graded by a person. Tasks 6 to 8 were graded by Opus 5.5 agents against the checklists, with a quote as evidence for every error, and spot-checked by hand. An Opus grader may favour Opus outputs, so we also asked Gemini 3.1 Pro (preview) to grade tasks 5 to 7 blind. It agreed on 26 of 37 outputs. Where they differed, we recomputed the disputed numbers from the source data: the Opus grader was right, and Gemini had missed the errors. Its first attempt did not grade at all: it wrote keyword-search scripts instead of reading the outputs, and skipped some of them. A second grader from another vendor is not a check by itself; it needs checking too.

What these results do not show

• Most blind cells ran once. We only claim patterns that repeat across tasks.
• The runs were short, from 10 seconds to 15 minutes. Long, autonomous sessions, which is where Fable and xhigh are positioned, were not measured.
• Nine of our tasks, our inputs, without our usual hooks and project instructions.
• List prices, as reported by Claude Code.

Which model and effort level should you use?

This is the table we now work by. It comes from our nine tasks, so treat it as a starting point for your own measurement, not as a rule.

What we changed in our own setup after the tests: Opus 5.5 at medium is the default everywhere; writing, debugging (Kubernetes included) and every kind of review run at high; our research agent runs Opus 5.5 at medium; and where Sonnet 5.5 still runs, it runs at medium. That is roughly how we run client platforms too: the default is cheap and checked, and the expensive option is a deliberate choice.

Five lessons we took away:

1. Raise the effort on one model before you switch to a bigger one. Opus 5.5 at high beat Fable 5.1 at high for less than half the price.
2. On Sonnet 5.5, high bought nothing on our tasks and doubled the cost.
3. xhigh is a scalpel, not a default: 3.4 times the cost of medium and three times the wait for the last few points.
4. A failed check can mean the model was right. Read the diff.
5. Writing still needs a human pass at every setting except the most expensive one, and the invented details were small, plausible and easy to miss.

The second-biggest cost lever was not the model at all. In our own logs, cache reads and writes were 78 % of the Opus cost, and one plugin that was supposed to save tokens was a quarter of the bill. If your team’s AI spend is growing and nobody can say which line is which, that is the same problem as an unexplained cloud bill, and the same review finds it.

Who should not copy this table

• Teams whose work is long, autonomous sessions. We did not measure those, and that is where the larger models and xhigh are meant to earn their price.
• Anyone without a way to check the output. Our cheap picks only work because a test, a script or a person checks every result.
• Anyone who reads nine tasks as a general benchmark. Run the same kind of test on your own work: tasks with a known answer, blind grading, and cost per usable result. Ours took two days, from preparation to grading, and less than $80.