The article is a practical deep dive into the effort setting in Claude Code, based on internal runs and personal experiments. At a high level, effort tells the model roughly how much compute to spend on a task. Higher effort does not simply mean “try harder”: it shifts Claude toward more independent judgment, verification, and edge-case testing, at the cost of much more time and tokens.

The author first tested effort on small build tasks. Given an underspecified request like “build a personal fitness and workout tracker app,” low effort produced a minimal log-and-graph app, while max effort produced a richer app with a heat chart. On a lightly specified design task, redesigning the /config menu in Claude Code, low effort took about 1 minute and returned an interactive sketch, while max effort took 28 minutes and returned a polished mockup with walkthroughs. When given a detailed spec, models at different effort levels behaved much more similarly. For regular feature work, the author recommends a loop: have Claude interview you about missing details, implement on low effort, review and iterate on low effort, then verify and test on high effort.

The second half turns to hard problems from Terminal-Bench 3.0, a community-sourced benchmark. Looking at 370 attempts, the author found that higher effort mostly helps when tasks have many hidden edge cases. One clean example is an HTML sanitizer task: Fable 5.1 went from 1/5 at low effort to 5/5 at xhigh. A typical low-effort attempt took about 2 minutes and tested one hand-written page; a high-effort run took about 33 minutes and included adversarial review of its first draft, reading the installed parser’s source for bugs, running clean test cases, running an XSS suite, and writing a random-document fuzzer.

Opus 5.5 showed similar patterns. On mvcc-lsm-compaction, a storage-engine bug fix, it went from 0/5 at low effort to 4/5 at xhigh: low attempts edited code before reproducing the crash, while high-effort runs reproduced the crash first, wrote a randomized test against a reference that never compacts, and checked that tests failed on half-finished fixes. On cli-2ph-simplex, a linear-programming solver, Opus 5.5 went from 0/5 at low to 5/5 at high by testing against a brute-force solver and reworking search when big inputs ran too long. On gsea-proteomics, it went from 0/5 to 4/5 by trying two data-prep approaches and investigating why the significant-treatment list changed.

Category-level pass rates for Fable 5.1, pooling low versus top effort, show where effort matters most: Security went from 64% to 87%, Hardware from 34% to 75%, ML from 54% to 73%, Science from 41% to 61%, Software from 43% to 56%, Media from 18% to 30%, and Operations from 12% to 22%. Importantly, effort reduces failures caused by missing edge cases, but it does not fix cases where the model takes the wrong approach.

The author’s rule of thumb: use low effort for quick, in-the-loop responses like brainstorming, sketching, and easy changes; medium for regular software engineering such as new features; high for work where verification matters, like fixing a bug in a brownfield codebase; and max when Claude should operate fully autonomously on difficult problems, such as end-to-end app building or finding security vulnerabilities. A footnote clarifies that the numbers come from internal runs with five attempts per task, production safety interventions off for Fable 5.1, and no internet access for security tasks, so they will not line up exactly with the public leaderboard.