# Claude Code Effort Levels: Low, Medium, High or Max?

> Claude Code effort levels explained: what low to max really change, real build times, Terminal-Bench 3.0 results and a cheat sheet for picking a level.

Source: https://bytevancer.com/blog/claude-code-effort-levels · Published 2026-09-27 · ByteVancer · AI Engineering

**Low took 1.5 minutes. Max took 67. What Claude Code's effort dial actually changes, where it pays off on Terminal-Bench 3.0, and the one failure that gets worse at max.**

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 `/effort` is 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](https://bytevancer.com/blog/what-is-harness-engineering) covers the feedback-loop side, and our [Claude Opus 5.5 breakdown](https://bytevancer.com/blog/claude-opus-5-5) 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)**
1. **PROMPT** — "build a personal fitness and workout tracker app" — Opus 5.5. No spec. Same prompt at every level.
2. **LOW · 1.5 MIN** — a log + one simple graph. it's giving MVP — A base to iterate on.
3. **MEDIUM · 4 MIN** — a bit more going on 👀 — Every step up, the app gets more complex.
4. **HIGH · 11 MIN** — Claude makes more calls for you — More effort = more choices made along the way.
5. **MAX · 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.

**📊 Minutes per build, by effort level (Opus 5.5)**
- **Low** — Vague prompt (fitness app) 1.5 min · Detailed spec 16 min
- **Medium** — Vague prompt (fitness app) 4 min · Detailed spec 22 min
- **High** — Vague prompt (fitness app) 11 min · Detailed spec 33 min
- **Max** — Vague prompt (fitness app) 67 min · Detailed spec 79 min

*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*

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:

**The effort loop for a new feature**
Interview → Build on low → Review the gist → Verify on high

1. **Interview** — Give Claude a spec and ask it to interview you about the missing details.
2. **Build on low** — Implement on low effort for a fast first pass.
3. **Review the gist** — Check it got the idea; iterate on low as needed.
4. **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.

**📊 Terminal-Bench 3.0 pass rate: low vs top effort (Fable 5.1)**
- **Security (7 tasks)** — Low effort 64% · Top effort 87%
- **Hardware (5 tasks)** — Low effort 34% · Top effort 75%
- **ML (13 tasks)** — Low effort 54% · Top effort 73%
- **Science (15 tasks)** — Low effort 41% · Top effort 61%
- **Software (20 tasks)** — Low effort 43% · Top effort 56%
- **Media (4 tasks)** — Low effort 18% · Top effort 30%
- **Operations (10 tasks)** — Low effort 12% · Top effort 22%

*"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)*

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**
1. **LOW · ~2 MIN** — one-pass filter. tested on ONE page. ✅ ship it — A single hand-written test page.
2. **RESULT · LOW** — 1/5 passes 💀 — Hidden edge cases: 1. Vibes: 0.
3. **HIGH EFFORT · ~33 MIN** — adversarial self-review 🕵️ — It attacks its own draft first.
4. **STILL COOKING** — reads the installed parser's source — How does this HTML actually get parsed?
5. **SIDE QUEST** — clean docs until output = input, then an XSS suite — Nothing safe gets mangled; nothing nasty gets through.
6. **FINAL BOSS** — writes a random-document fuzzer — Let chaos find what it missed.
7. **RESULT · XHIGH** — 5/5 passes 🫡 — Every attempt passed.

*html-js-filter, Fable 5.1 — Thariq Shihipar, claude.dev (Terminal-Bench 3.0 internal runs).*

**The high-effort run, step by step (~33 min)**
Draft the filter → Adversarial self-review → Read the parser's source → Clean cases, then an XSS suite → Fuzz it

1. **Draft the filter** — Write a first draft. (The low-effort attempts stopped after roughly one pass, ~2 min.)
2. **Adversarial self-review** — Reviewed its own draft as an attacker would.
3. **Read the parser's source** — Read the source of the installed HTML parser.
4. **Clean cases, then an XSS suite** — Ran clean test cases until output matched input, then a standard XSS suite.
5. **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.

**Low vs max effort, Fable 5.1 (370 attempts each)**
- **73k → 222k** Median tokens / attempt — Roughly 3x the tokens at max.
- **59 → 24** Missed-a-case failures — Works on my machine, overfitting, close-but-not-exact, bugs its tests missed.
- **140 → 214** Passed — Out of 370 attempts, low vs max.

*Source: Thariq Shihipar, claude.dev (Terminal-Bench 3.0 internal runs).*

**📊 Where the failures went (Fable 5.1, 370 attempts each)**
- **Works on my machine** — Low effort 2 · Max effort 1
- **Overfit to examples** — Low effort 7 · Max effort 3
- **Close but not exact** — Low effort 10 · Max effort 6
- **A bug its tests missed** — Low effort 40 · Max effort 14
- **Misread a requirement** — Low effort 45 · Max effort 26
- **Wrong or incomplete fix** — Low effort 31 · Max effort 10
- **Got the domain rule wrong** — Low effort 32 · Max effort 24
- **Picked the wrong reading** — Low effort 25 · Max effort 47
- **Other failures** — Low effort 38 · Max effort 25

*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)*

**🎞️ Works on my machine: the glow-up**
1. **LOW → MAX** — works on my machine: 2 → 1 — Rare to begin with. Now rarer.
2. **LOW → MAX** — bugs its own tests missed: 40 → 14 📉 — The biggest drop. Verification goes brrr.
3. **LOW → MAX** — wrong or incomplete fix: 31 → 10 — More checking, fewer half-fixes.
4. **LOW → MAX** — misread a requirement: 45 → 26 — Reading the brief twice pays.
5. **PLOT 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)

**📊 Passes out of 5, low vs higher effort**
- **html-js-filter (Fable 5.1, xhigh)** — Low effort 1 · Higher effort (xhigh/high) 5
- **mvcc-lsm-compaction (xhigh)** — Low effort 0 · Higher effort (xhigh/high) 4
- **cli-2ph-simplex (high)** — Low effort 0 · Higher effort (xhigh/high) 5
- **gsea-proteomics (high)** — Low effort 0 · Higher effort (xhigh/high) 4

*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)*

- **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?

**Which effort level should you pick?**
- Quick, in-the-loop work — brainstorming, sketching, an easy change? → **Low**
- Regular software engineering, like building a new feature? → **Medium**
- Do verification and edge cases matter — say, a bug in a brownfield codebase? → **High**
- Otherwise → **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](https://bytevancer.com/blog/ai-agent-teams-gemini-4-argon) covers splitting work across a team lead and teammates; pick the effort for each teammate's task with the same rule of thumb.

## Caveats

> **Internal runs, not the leaderboard** — The Terminal-Bench 3.0 numbers are internal runs with 5 attempts per task, Fable 5.1's production safety interventions switched off, and security tasks run without internet access. Shihipar says they won't match the public leaderboard or the launch post, and the worked examples are individual runs, some at intermediate settings. The effort curves used the same 70 tasks per model (4 GPU tasks left out). Failure kinds were labelled by a model judge and are approximate. Build times come from one person's experiments.

## Frequently asked questions

**What are the effort levels in Claude Code?**
The claude.dev post names five: low, medium, high, xhigh and max. Effort approximates how much compute Claude spends on a task. Higher levels mean more verification, edge-case testing and independent judgement, and more tokens and time. You change it with /effort in Claude Code.

**Which Claude Code effort level should I use?**
Thariq Shihipar's rule of thumb: low for quick in-the-loop work like brainstorming, sketching and easy changes; medium for most regular software engineering such as new features; high when verification and edge cases matter, like fixing a bug in a brownfield codebase; max for fully autonomous work on difficult problems, such as finding security vulnerabilities in critical software.

**Does higher effort always give better results?**
No. Higher effort reduces failures from missed edge cases, but it does not fix a wrong approach. In Fable 5.1 runs on Terminal-Bench 3.0, failures labelled "picked the wrong reading" rose from 25 at low effort to 47 at max.

**How much slower and more expensive is max effort?**
In Shihipar's Opus 5.5 experiments, a vague fitness-app prompt took 1.5 minutes at low and 67 at max, and a detailed spec took 16 versus 79 minutes. On Terminal-Bench 3.0, Fable 5.1's median tokens per attempt went from 73k at low to 222k at max.

**Does changing effort break the prompt cache in Claude Code?**
According to the claude.dev post, the newest models respond to effort without breaking the prompt cache in Claude Code. That makes it practical to switch levels mid-conversation with /effort — for example, building on low and then verifying on high.

## Keep reading

- [Claude Opus 5.5: Fable-Level Work at 40% Lower Cost Than Opus 5](https://bytevancer.com/blog/claude-opus-5-5) — Claude Opus 5.5 explained: new pricing, where the 40% saving vs Opus 5 comes from, benchmarks with caveats, safety changes and what it means for your team.
- [What Is Harness Engineering? Agent = Model + Harness (2026)](https://bytevancer.com/blog/what-is-harness-engineering) — Harness engineering explained: why Agent = Model + Harness, feedforward guides vs feedback sensors, and a starter harness for AI coding agents.
- [All ByteVancer engineering articles](https://bytevancer.com/blog)

## Want coding agents that ship, not just vibe?

We build cloud applications with Claude Code and other coding agents in the loop — specs, checks and CI that make low effort fast and high effort safe. See our [cloud application development with AI built in](https://bytevancer.com/services/cloud-applications) or [talk to the team](https://bytevancer.com/contact).

## Sources

- [Thariq Shihipar — Using Claude Code: Spending your effort, claude.dev (Sep 25, 2026)](https://claude.dev/blog/spending-your-effort/)
- [Terminal-Bench 3.0 release and task list — harbor-framework/terminal-bench on GitHub](https://github.com/harbor-framework/terminal-bench/releases/tag/v3.0.0)

---

*This is the Markdown copy of https://bytevancer.com/blog/claude-code-effort-levels — the page itself has the interactive charts and diagrams.*