Effort is the most underrated dial in Claude Code, and it just got a proper vibe-check. On September 25, 2026, Thariq Shihipar published "Using Claude Code: Spending your effort" on the claude.dev blog: his own build experiments plus a deep dive into Terminal-Bench 3.0 runs with Opus 5.5 and Fable 5.1. We turned it into charts, flowcharts and a few looping panels. Every number below comes from that post; the jokes are ours.
TL;DR
- Effort is roughly how much compute you want Claude to spend. In practice it sets how much verification, edge-case testing and independent judgement Claude does.
- Shihipar says the newest models respond to effort without breaking the prompt cache in Claude Code, so switching mid-conversation with
/effortis fair game. - Same vague app prompt: low took 1.5 minutes, max took 67. Low hands you a starting point; max makes more choices on your behalf.
- On Terminal-Bench 3.0, higher effort helped most on tasks with hidden edge cases (security, hardware) and least on rulebook-style operations work.
- Effort reduces missed-edge-case failures. It doesn't fix a wrong approach. Plot twist: one failure kind went UP at max. 👀
What effort actually is
Shihipar frames effort as an approximation of how much compute you want spent on a task — closely tied to how hard you think the task is. His analogy: if someone gave you a task and 12 straight hours, you'd try very hard. Give you the same task and one hour, and you'd ship the best version that meets the brief, then iterate. Or you'd push back: "this needs at least 3 hours."
The important bit: Claude always tries to do the task reasonably. Low effort isn't Claude slacking off 😴. Higher effort means more independent action for judgement and verification — checking its own work, poking at edge cases. That's why the post found extra effort paid off in hardware, code review and security, where verification is the whole game.
Our framing at ByteVancer: effort is how much verification the model does by itself. A harness is the verification you build around it — tests, CI, hooks, review. They stack, they don't replace each other. Our guide to harness engineering covers the feedback-loop side, and our Claude Opus 5.5 breakdown covers the model behind most of these runs.
The effort dial: low → max
The post names five levels: low, medium, high, xhigh and max. Shihipar calls the Fable 5.1 and Opus 5.5 effort curves "our best yet": every step up brings an uptick in benchmark score and in tokens consumed. Effort is never free — you pay in tokens and wall-clock time. Here's what that looks like on one very vague prompt:
The effort dial (vague prompt edition)
01PROMPT
"build a personal fitness and workout tracker app"
Opus 5.5. No spec. Same prompt at every level.
02LOW · 1.5 MIN
a log + one simple graph. it's giving MVP
A base to iterate on.
03MEDIUM · 4 MIN
a bit more going on 👀
Every step up, the app gets more complex.
04HIGH · 11 MIN
Claude makes more calls for you
More effort = more choices made along the way.
05MAX · 67 MIN
heat chart unlocked 🔥
The best one-shot. Also: over an hour.
Opus 5.5 build times from Thariq Shihipar's experiments, claude.dev.
Three builds, four effort levels
Shihipar ran build tasks on Opus 5.5 at different effort levels, from a one-line prompt to a full spec.
1. Vague: "build a fitness tracker"
Low took 1.5 minutes and produced a log and a simple graph. Medium took 4, high 11, max 67 — each more complex, with max adding a heat chart. His call: low when you want a base to iterate on, max when you want the best one-shot. Higher effort also means Claude makes more choices along the way. Main-character energy you may or may not want.
2. Light spec: redesign the /config menu
Every pass landed on the same idea — submenus plus better search. Low took 1 minute and made an interactive sketch that didn't look much like Claude Code. Max took 28 minutes and produced a mockup very close to Claude Code, walkthroughs included. Shihipar preferred low here: it showed Claude's vision fast and left room to iterate.
3. Full spec, written from an interview
With a detailed spec, low took 16 minutes, medium 22, high 33 and max 79 — and the results were much more similar to each other. At max, Claude even simplified some details. A good spec shrinks the gap between levels.
Wall-clock minutes from one person's experiments. The /config redesign (1 min at low, 28 at max) isn't charted because only two levels were reported. Source: Thariq Shihipar, claude.dev.
View data table
| Category | Vague prompt (fitness app) | Detailed spec |
|---|---|---|
| Low | 1.5 min | 16 min |
| Medium | 4 min | 22 min |
| High | 11 min | 33 min |
| Max | 67 min | 79 min |
The takeaway for everyday software engineering: effort is about how in-the-loop you want to be. Low gives you a quick starting point you steer. Higher effort gets more work done, but makes more assumptions on your behalf.
The effort loop: interview → low → review → high
This is the workflow Shihipar uses for features. It's lowkey the best part of the post:
- 01
Interview
Give Claude a spec and ask it to interview you about the missing details.
- 02
Build on low
Implement on low effort for a fast first pass.
- 03
Review the gist
Check it got the idea; iterate on low as needed.
- 04
Verify on high
Switch to high effort to verify and test.
Why it slaps: cheap iterations while you're still figuring out what you want, expensive effort only once the target is locked and correctness matters. Switch with /effort between steps.
Where effort pays off: Terminal-Bench 3.0
Terminal-Bench 3.0 is community-sourced, with tasks across security, hardware, ML, science, software, operations and media. Examples: build an 8-bit console in Verilog for a small FPGA, prove Takens' embedding theorem in Lean 4, merge 16 mixture-of-experts checkpoint shards so they reproduce reference logits, file a month-end EU trade-statistics report, and turn a poster into an editable layout file. Not exactly todo apps.
The main takeaway: higher effort is best on tasks with lots of hidden edge cases.
"Low" pools the two lowest effort settings; "top" pools the three highest. Internal runs, 5 attempts per task — these won't match the public leaderboard. Source: Thariq Shihipar, claude.dev (Terminal-Bench 3.0 internal runs).
View data table
| Category | Low effort | Top effort |
|---|---|---|
| Security (7 tasks) | 64% | 87% |
| Hardware (5 tasks) | 34% | 75% |
| ML (13 tasks) | 54% | 73% |
| Science (15 tasks) | 41% | 61% |
| Software (20 tasks) | 43% | 56% |
| Media (4 tasks) | 18% | 30% |
| Operations (10 tasks) | 12% | 22% |
Hardware more than doubles, from 34% to 75%. Security climbs from 64% to 87%. Operations barely moves (12% to 22%) — Shihipar's note on it is simply "rulebook-style work stays low". Our read: when a task is about knowing the rules, more self-checking can't invent rules the model doesn't know.
Case file: low effort vs the HTML sanitizer
The task html-js-filter asks for an HTML sanitizer that strips every way to smuggle in JavaScript. Hidden edge cases, everywhere. Fable 5.1 passed 1 of 5 attempts at low effort and 5 of 5 at xhigh.
Low effort vs the HTML sanitizer
01LOW · ~2 MIN
one-pass filter. tested on ONE page. ✅ ship it
A single hand-written test page.
02RESULT · LOW
1/5 passes 💀
Hidden edge cases: 1. Vibes: 0.
03HIGH EFFORT · ~33 MIN
adversarial self-review 🕵️
It attacks its own draft first.
04STILL COOKING
reads the installed parser's source
How does this HTML actually get parsed?
05SIDE QUEST
clean docs until output = input, then an XSS suite
Nothing safe gets mangled; nothing nasty gets through.
06FINAL BOSS
writes a random-document fuzzer
Let chaos find what it missed.
07RESULT · XHIGH
5/5 passes 🫡
Every attempt passed.
html-js-filter, Fable 5.1 — Thariq Shihipar, claude.dev (Terminal-Bench 3.0 internal runs).
- 01
Draft the filter
Write a first draft. (The low-effort attempts stopped after roughly one pass, ~2 min.)
- 02
Adversarial self-review
Reviewed its own draft as an attacker would.
- 03
Read the parser's source
Read the source of the installed HTML parser.
- 04
Clean cases, then an XSS suite
Ran clean test cases until output matched input, then a standard XSS suite.
- 05
Fuzz it
Wrote a random-document fuzzer to hunt for what the suite missed.
What effort can't fix
Effort reduces failures from missing edge cases. It does not fix a wrong approach. Shihipar broke down Fable 5.1's failures across 370 attempts at low and 370 at max, with each failure labelled by a model judge — so treat the categories as approximate.
- Median tokens / attempt
- 73k → 222kRoughly 3x the tokens at max.
- Missed-a-case failures
- 59 → 24Works on my machine, overfitting, close-but-not-exact, bugs its tests missed.
- Passed
- 140 → 214Out of 370 attempts, low vs max.
Source: Thariq Shihipar, claude.dev (Terminal-Bench 3.0 internal runs).
Failed attempts by kind. The first four form the "missed a case" group (59 → 24); misread requirement, wrong fix, domain rule and wrong reading form "made the wrong call" (133 → 107). Kinds were labelled by a model judge and are approximate. Source: Thariq Shihipar, claude.dev (Terminal-Bench 3.0 internal runs).
View data table
| Category | Low effort | Max effort |
|---|---|---|
| Works on my machine | 2 | 1 |
| Overfit to examples | 7 | 3 |
| Close but not exact | 10 | 6 |
| A bug its tests missed | 40 | 14 |
| Misread a requirement | 45 | 26 |
| Wrong or incomplete fix | 31 | 10 |
| Got the domain rule wrong | 32 | 24 |
| Picked the wrong reading | 25 | 47 |
| Other failures | 38 | 25 |
Works on my machine: the glow-up
01LOW → MAX
works on my machine: 2 → 1
Rare to begin with. Now rarer.
02LOW → MAX
bugs its own tests missed: 40 → 14 📉
The biggest drop. Verification goes brrr.
03LOW → MAX
wrong or incomplete fix: 31 → 10
More checking, fewer half-fixes.
04LOW → MAX
misread a requirement: 45 → 26
Reading the brief twice pays.
05PLOT TWIST 🚨
picked the wrong reading: 25 → 47
The one failure kind that went UP at max.
Failure counts, low → max effort, Fable 5.1, 370 attempts each — Thariq Shihipar, claude.dev.
The "made the wrong call" group only fell from 133 to 107, and "picked the wrong reading" nearly doubled, from 25 to 47. Our read: more effort polishes whatever interpretation Claude committed to — if the interpretation is wrong, you get a very well-tested wrong answer. The fix isn't more effort, it's less ambiguity, which is exactly what the interview step in the effort loop is for. Shihipar makes a related point: with a user in the loop, Claude might have asked about the setup; without one, high effort does better.
More case files (Opus 5.5)
Passing attempts out of 5. Opus 5.5 unless marked; the higher setting used is in brackets. Worked examples are individual runs. Source: Thariq Shihipar, claude.dev (Terminal-Bench 3.0 internal runs).
View data table
| Category | Low effort | Higher effort (xhigh/high) |
|---|---|---|
| html-js-filter (Fable 5.1, xhigh) | 1 | 5 |
| mvcc-lsm-compaction (xhigh) | 0 | 4 |
| cli-2ph-simplex (high) | 0 | 5 |
| gsea-proteomics (high) | 0 | 4 |
- mvcc-lsm-compaction — 0/5 → 4/5 at xhigh. Low (~1 min) edited code before building or reproducing the bug, and never checked that its test would catch the bug. Xhigh (~11 min) reproduced the crash first, ran a randomized test against a non-compacting reference, and checked that the tests fail on half-finished fixes.
- cli-2ph-simplex — 0/5 → 5/5 at high. Low did one pass on a few small problems, stopped at around 10k tokens, and warned the solver might be slow without checking. High tested random problems against a brute-force solver, timed bigger ones and reworked the search.
- gsea-proteomics — 0/5 → 4/5 at high. Low used one data-prep approach. High tried two, noticed the results changed, and dug into why.
The pattern, in our words: low trusts its first draft; high tries to prove itself wrong. That's the whole game.
Cheat sheet: which effort level?
01Quick, in-the-loop work — brainstorming, sketching, an easy change?
YES → LowNO ↓
02Regular software engineering, like building a new feature?
YES → MediumNO ↓
03Do verification and edge cases matter — say, a bug in a brownfield codebase?
YES → HighNO ↓
Max: fully autonomous on a hard problem, like an end-to-end build or a security hunt
That's Shihipar's rule of thumb. Max is for Claude working fully autonomously on difficult problems: building and verifying an app end to end, or finding security vulnerabilities in critical software. You can change effort per task, or mid-conversation, with /effort in Claude Code. Touch grass on low, lock in on high. 🫡
Running several Claude sessions at once? Our guide to Claude Code agent teams covers splitting work across a team lead and teammates; pick the effort for each teammate's task with the same rule of thumb.