Thariq, a Claude Code team member, has published a detailed look at how the tool’s effort settings affect model behavior. In the “Spending your effort” post, he argues that higher effort generally leads Claude to perform more verification, test more edge cases and make more independent decisions—while lower settings are better suited to fast, collaborative work.

Claude Code’s effort settings trade speed for verification

Claude Code supports four effort levels: /effort low, /effort medium, /effort high, and /effort max. The setting changes how much compute Claude spends on a task without breaking the prompt cache, according to Thariq.

The settings appear to affect more than response length. Higher effort gives Claude more room to investigate problems, challenge its initial approach and verify its work. Lower effort produces quicker results but leaves more decisions and follow-up work to the developer.

Thariq’s recommended workflow for software engineering reflects that trade-off:

• Ask Claude to interview the developer about gaps in the specification.
• Implement the feature at low or medium effort.
• Review the result and iterate quickly.
• Run deeper verification and testing at high effort.

He describes low effort as useful for brainstorming, sketching and easy changes. Medium effort is intended for regular feature work, while high effort is better suited to bug fixes and tasks with difficult edge cases. Max effort is reserved for handing over a challenging task from start to finish, or for work such as security analysis where extensive checking is valuable.

Higher effort produces more elaborate builds

In one experiment, Thariq asked Opus 5.5 to build a personal fitness and workout tracker without providing much detail. At low effort, the result consisted of a basic log and a simple graph. Higher settings produced a more elaborate application, while max effort added a heat chart.

That extra detail also involved more assumptions from the model. Thariq characterizes low effort as a better starting point when the goal is to iterate, while max effort is more appropriate for a polished first attempt.

A redesign of Claude Code’s /config menu produced a similar pattern. Every version used submenus and improved search, but the low-effort run took about one minute and produced an interactive sketch. The max-effort run took 28 minutes and generated a mockup closer to Claude Code’s existing design, along with walkthroughs for several user flows.

When Thariq supplied a detailed specification after an in-depth interview, the outputs became more similar across effort levels. The max-effort version still spent time simplifying some details, but the initial specification reduced the number of decisions Claude had to make independently.

Benchmark results point to edge-case testing

Thariq also evaluated Opus 5.5 and Fable 5.1 using Terminal Bench 3.0, a community-sourced benchmark covering security, hardware, ML, science, software, operations and media tasks.

The benchmark includes problems such as building an 8-bit game console in Verilog, formally proving Takens’ embedding theorem in Lean 4, consolidating distributed ML checkpoints and recreating a poster as an editable layout file.

According to Thariq’s analysis, extra effort helped most when tasks contained numerous hidden failure modes. In one HTML sanitizer task, Fable 5.1 went from one successful result out of five at low effort to five out of five at xhigh effort.

The low-effort attempts generally wrote a filter in one pass and tested it against a single hand-written page. A high-effort run reviewed its initial implementation adversarially, inspected the parser’s source code, ran clean-input tests, used an XSS test suite and created a random-document fuzzer.

Thariq reports similar results in several Opus 5.5 tasks:

• A storage-engine compaction fix improved from 0/5 at low effort to 4/5 at xhigh effort after Claude reproduced the crash, wrote randomized tests and compared behavior against a reference implementation.
• A Python linear-program solver improved from 0/5 at low effort to 5/5 at high effort after Claude tested random problems, measured larger inputs and reworked a search strategy that was too slow.
• A proteomics analysis improved from 0/5 at low effort to 4/5 at high effort after Claude compared different data-preparation methods and investigated conflicting results.

The benchmark analysis also suggests a limit to the setting. More effort reduced failures linked to missed edge cases, but did not consistently correct an fundamentally wrong approach. Spending more compute can make verification more thorough; it cannot guarantee that the model selected the right strategy at the outset.

For day-to-day development, Thariq reports using low effort more often when he wants to remain involved in the process. Max effort is mainly reserved for autonomous work or searching for security vulnerabilities. The experiments therefore present effort as a control over initiative and verification, rather than a universal quality switch.

Source: Thariq’s X post