A Practical Guide to Claude Code effort: When to Use Low and When to Raise It

Claude’s new Opus 5.5 model can adjust how much work it puts in according to the effort setting, and switching levels in Claude Code does not break the prompt cache. The tests in the original article also suggest that it can achieve similar results at a lower setting: Opus 5.5 at High had a pass rate close to Fable 5.1 at Max. Yet users still often ask: what exactly is effort, why do we need it, and how should we choose a level? Anthropic’s Thariq Shihipar wrote an article explaining how to use it.

To answer these questions, Shihipar ran everyday development experiments and examined internal Terminal-Bench 3.0 runs. His focus was on which additional independent decisions, verification steps, and edge-case tests the extra work actually produced. This guide follows the sequence “understand the mechanism → examine the tests → apply it to development.”

What effort is, and what it actually changes

Effort tells the model approximately how much computation a task is worth. It is neither a strict time limit nor simply a switch controlling the length of the final reply. Both low and high settings aim to complete the task, but a lower setting tends to deliver a version that meets the requirements sooner. A higher setting is more likely to continue researching, try alternative approaches, review its own implementation, and check edge cases that the prompt did not list individually. The author compares it to a person’s working time: give someone one hour and they can produce something to discuss; give them twelve hours and they have room to refine and verify it independently.

This also explains why “higher” does not always mean “more suitable.” When a task is still unclear, the extra work may go into making product decisions for you. For a security filter or a storage-engine bug, where unusual cases are easily missed, additional verification can be exactly what matters. Before choosing a level, decide whether you need another round of feedback or a deliverable that is as self-contained as possible.

Three experiments: how clear requirements change the choice

The author used three small development tasks to observe behavioral differences across effort settings. The times below are records of the showcased runs. They help explain the trade-offs; they are not a timetable that every task will reproduce.

Vague requirements: a quick foundation or more independent decisions

The first task asked Opus 5.5 to start with a single sentence: build a personal fitness and workout tracking app. In this demonstration, low produced logging and simple charts in about 1.5 minutes; medium took about 4 minutes and high about 11. Max took about 67 minutes and produced a more complete app, with details such as a heatmap. The interactive comparison in Figure A shows the low version centered on logging, weekly training volume, and history, while the max version also had more complete navigation and workout flows. The additional work included both more features and Claude’s own decisions about which features and interfaces were worth building.

How to choose: use Low if you want a foundation and intend to give feedback immediately. Raise the setting if you want to see how far the model can refine the result on its own in one run, while accepting that it will make more choices for you.

Exploratory design: establish a direction or inspect a polished prototype

Another task was to redesign Claude Code’s /config menu. The basic idea was similar across levels: submenus and better search. Low produced an interactive sketch in about 1 minute that conveyed a direction but did not look much like the existing Claude Code interface. Max took about 28 minutes to produce something closer to the product and walk through different interaction paths. The author actually preferred low for this task because he wanted to see the direction first and then give his own feedback. Max’s more complete result becomes more attractive when the goal is to get as much as possible in a single delivery.

How to choose: start early exploration at Low. Once the direction is settled, spending time on fuller details and interaction flows makes more sense.

Detailed specifications: closer outputs, still very different runtimes

The author then changed the conditions. He first had Claude conduct a detailed interview to fill gaps in the fitness app’s requirements, and then gave the same detailed specification to different models at different effort settings. Low, medium, high, and max took about 16, 22, 33, and 79 minutes respectively, but their designs and implementations were much more alike. Max still simplified some details. The comparison shows that clear specifications reduce what Claude has to guess for you. Increasing effort cannot replace explaining the requirements. All three experiments are specific runs showcased by the author; their durations illustrate working styles, not a promise about how long your task will take.

How to choose: for an initial implementation with a thorough specification and a human reviewer, start with Low or Medium. Schedule important tests as a later stage. One app demonstration does not establish that every complex task can be completed at a low setting.

Tests on difficult tasks: where higher effort earns its place

The everyday app demonstrations were within the models’ capabilities. To see when effort affects success or failure, the author also examined Terminal-Bench 3.0, whose community-contributed tasks cover security, hardware, machine learning, science, software, business operations, and media. They are generally harder than ordinary development requests. Tasks include building an 8-bit game console in Verilog that can run a test ROM, formalizing a theorem in Lean 4, merging 16 shards of mixture-of-experts model weights, completing a company’s month-end EU trade statistics filing end to end, and recreating a poster as an editable layout. These go well beyond a routine request to write a piece of code.

Higher settings can improve pass rates while consuming more resources

An overview chart puts pass rates alongside token consumption per attempt. In these tasks, the author reports that Opus 5.5 rose from 36.6% at low to 65.7% at max. Its 58.9% at high was close to Fable 5.1’s 58.0% at max, with roughly half the median token use. The horizontal axis measures median tokens consumed per attempt, not price or runtime. It shows that different models and levels offer different combinations of success rate and resource use. The chart also contains an example of gains flattening out: Fable 5 remained at 43.4% when moving from xhigh to max. We therefore cannot assume that raising effort will produce the same benefit for every model and task.

The comparison uses the same 70 tasks, excluding 4 GPU tasks. The Opus 5.5 runs occurred about three weeks later, had a 128k output limit, and could not access GitHub or PyPI. Opus 5 max in the chart corresponds to its effort-120 run. These conditions matter when comparing models.

What the extra time was spent checking

The HTML sanitizer task, html-js-filter, makes the mechanism especially clear. It requires filtering out different ways of sneaking JavaScript into a page. In Anthropic’s internal runs, Fable 5.1 went from passing 1 of 5 attempts at low to passing all 5 at xhigh. A low-effort run the author traced took about two minutes, essentially wrote the solution in one pass, and tested it only on a handwritten page. A higher-effort run he traced took about 33 minutes: it reviewed the first draft from an attacker’s perspective, read the installed parser’s code, checked that benign input was not damaged, ran an XSS test suite, and finally wrote a random document generator to search for more vulnerabilities. For work where one missed entry point can cause failure, extra time can buy meaningful checks.

Fewer missed cases, but wrong directions can remain

This does not mean high effort fixes every mistaken judgment. Figure D classifies 370 Fable 5.1 attempts at each level. Moving from low to max increased passes from 140 to 214 and median tokens from 73,000 to 222,000. Failures from missing a case fell from 59 to 24, while failures from making the wrong call fell from 133 to 107. The latter remained common. One subcategory—choosing the wrong interpretation of the task—even increased from 25 to 47. These failure labels are approximate classifications produced by a model judge, not a precise causal breakdown.

A sound reading is that additional work substantially reduced some missed-case failures, but does not guarantee that the model will choose the right interpretation or solution approach.

Three hard problems: from “written” to “shown to work”

Other tasks in the article reveal similar differences in working style:

• For mvcc-lsm-compaction, a storage-engine compaction bug, Opus 5.5 went from 0/5 at low to 4/5 at xhigh. Low took about 1 minute per attempt and often changed code before building it or reproducing the fault. Xhigh took about 11 minutes per attempt, reproduced the crash first, ran randomized comparisons against a reference implementation without compaction, and checked that its tests caught partially fixed versions.
• For cli-2ph-simplex, a Python command-line linear programming solver, results went from 0/5 at low to 5/5 at high. Low ran only a few small problems and stopped after about 10,000 tokens. It warned that large problems might be slow but did not test them. High compared randomized problems against an independent brute-force solver, tested large problems under load, and reworked the search after finding slowdowns or crashes.
• For gsea-proteomics, which identifies treatments similar to a target tissue among eight treatment groups in proteomics data, results went from 0/5 at low to 4/5 at high. Low chose a seemingly reasonable preprocessing method and reported results. High tried two preprocessing methods, investigated why the list of significant groups changed, and then selected a method. Sometimes the real issue is an analytical assumption, not the last line of code. The author adds that, with a human involved, Claude might ask how to set up the analysis; without a human, high effort did better in this case.

Which domains benefited more from additional effort

Across task domains, Fable 5.1’s pass rate improved in all seven categories, though by different amounts:

“Lower” and “higher” pool the lowest two and highest three effort settings respectively because each category contains few tasks. These percentages are not the isolated effect of switching directly from low to max. The domain counts total 74 tasks, unlike the 70-task denominator in the overview chart that excludes GPU tasks. Security and hardware showed particularly large gains in these runs. Business operations tasks governed by business rules still had low pass rates after raising effort. This suggests spending more effort on tasks that require substantial verification and contain many hidden edge cases. When the main obstacle is understanding rules or choosing the right approach, more computation alone may not solve it.

A practical guide: allocate effort across the workflow

The author uses a practical cycle: describe the goal and let Claude interview you to identify specification gaps; use low for the first implementation; review the direction yourself and continue iterating at low if needed; then use high for verification and testing.

Pick a starting point for the current task

The author’s working scale is low for brainstorming, sketches, simple edits, and work that will receive immediate human feedback; medium for routine feature development; high for debugging existing codebases, important verification, and tasks with many edge cases; and max for difficult tasks Claude should complete with considerable autonomy, such as building and verifying an app end to end or auditing critical software for security vulnerabilities.

For your own work, start with the four situations below. Low, Medium, High, and Max are the author’s common starting points. Xhigh in the earlier experiments is an additional high-effort setting between High and Max.

• Low: get to feedback quickly. Brainstorming, interaction sketches, small changes, or clearly specified work whose first version you will review promptly. Check the direction and core flow first; do not treat the initial version as a thoroughly verified delivery.
• Medium: routine implementation. A daily starting point when the goal is fairly clear and you want a relatively complete new feature. If all you need is a skeleton to discuss immediately, start at Low instead.
• High: uncover problems. Bug fixes in existing codebases, performance verification, security checks, and tasks with many edge cases. “Brownfield” means changing code within an existing system and its constraints, where you need to confirm that a patch preserves existing behavior.
• Max: delegate more independent work. Consider it when you want the model to advance a difficult task, choose an approach, and finish verification autonomously, and you accept a longer wait and higher consumption. You still need clear goals, acceptance criteria, and permission boundaries.

Have Claude interview you and complete the specification

After providing an initial goal, ask Claude to question you. Prioritize choices that change the implementation: who will use it, what the core flow is, how data will be stored, which failures must be handled, and what counts as completion. Turn the answers into a checkable specification before implementation. Do not let vague requirements silently become product details the model decides for you.

Output from this step: agreed scope, decisions still awaiting confirmation, and acceptance criteria. If Claude is still guessing core requirements, keep clarifying. Simply raising effort cannot answer those business questions for you.

Use Low for a first version that lets you judge the direction

During rapid implementation, limit the scope to the most important user flow. Specify which decisions Claude may make and which it must bring back to you. A detailed specification has already reduced the guesswork, so Low can produce a discussable version sooner. If you need a reasonably complete routine implementation and do not intend to follow every step, Medium is another starting point.

Output from this step: a runnable first version that exposes the core logic, plus a list of what is and is not done. Basic execution checks still belong here; deeper verification comes in its own later stage.

Review it yourself and confirm that it does the right thing

Walk through the core flow and check three things against the specification: can the intended user complete the main task, do the important data and logic behave as expected, and has Claude expanded the feature scope on its own? A prettier interface or more code cannot replace this review.

If the direction is wrong, give specific feedback and continue iterating at Low. If the specification has a gap, fill it first. Move to High verification once the core logic is right and the remaining question is whether tests or hidden problems have been missed. This avoids spending extra computation on an approach you would need to discard anyway.

Switch to High and ask for evidence, not just “are there any issues?”

Give Claude the target of verification, acceptance criteria, and key risks together. For bug fixes, ask it to reproduce the original problem and confirm that the new test fails on the old implementation. For performance work, actually test data at the target scale. For complex algorithms, compare against an independent reference implementation. For a security filter, test both dangerous input and whether normal content is incorrectly affected.

These methods come from the article’s difficult-task examples. They give the model an external result it can check, so verification does not end at “I looked at it and it should be fine.”

Output from this step: the checks actually run, observed results, issues fixed, and areas still unverified. If failures come from missing cases or inadequate tests, add targeted verification. If they come from misunderstood requirements or faulty assumptions, return to the specification and approach. Additional work substantially reduced some missed-case failures, but does not guarantee that the model will choose the right interpretation or solution approach.

A reusable four-stage task prompt

The following example is adapted from the author’s workflow and can be used one stage at a time. It is not a verbatim prompt from the original article. Fill in the goal, project environment, and permitted scope of changes before starting. “Low / High” in the prompt simply reminds you which setting to choose. For Opus 5.5 and Fable 5.1, the author recommends using /effort in Claude Code to change levels by stage within the same conversation. The article also says switching effort on the new models does not break the prompt cache: reusable existing prompt content does not lose its cache solely because you changed the setting. You can therefore move from Low implementation to High verification in the current conversation.

[Requirements interview]
My goal is: [goal]. The users are: [users].
Project environment and permitted scope of changes: [environment, directories, limits].
First ask about missing information that would affect implementation.
Summarize scope, decisions awaiting confirmation, and acceptance criteria.
Ask me about key business choices; do not expand requirements for me.

[First implementation | Select Low first]
Implement the core flow from the confirmed specification: [core flow].
Produce a runnable version that is easy for me to review, and perform basic execution checks.
On delivery, list what is done, what is not done, and what still needs my decision.

[Iteration after human review]
My review found: [specific problems and expected behavior].
Address only these issues and recheck the affected core flow.
If my feedback conflicts with the requirements, identify the conflict first.

[Thorough verification | Switch to High]
Check the current implementation against the agreed acceptance criteria.
The key risks are: [risks].
Actually run relevant checks; for bug fixes, confirm the tests catch the original error.
Where needed, compare against reference results, target-scale data, or normal/abnormal inputs.
Report checks run, results, fixes, and what remains unverified.

When to raise or lower the setting

Signals to lower it: you only want to discuss the direction quickly, but the model keeps adding unrequested details; or the specification is already clear and you want to give frequent feedback. Narrow the current task and reduce how much the model needs to decide independently.

Signals to raise it: the direction is settled, but the task has many hidden edge cases, the patch must be shown to work, or the model needs to work independently for an extended period. Specify the key checks and completion criteria when raising the setting.

Signals to fix the input first: the model misunderstood the task, relies on a wrong premise, or does not know which behavior is correct for the business. Add information and correct the approach before deciding how much verification effort is needed.

The article’s data comes from Anthropic’s internal runs, with 5 attempts per task. Fable 5.1’s security tasks ran with production safety interventions disabled, and security tasks had no network access. In actual Claude products, some security requests are routed to Opus. The behavioral analysis draws on individual runs, some using intermediate effort settings. Do not treat the duration of one traced run as the average of five attempts at that level. These conditions affect comparability with public leaderboards and everyday usage. Treat the levels above as starting points, compare quality, time, and consumption on your own tasks, and adjust.