Using Claude Code: Spending your effort news update
. Using Claude Code: Spending your effort news update Why it matters for engineering teams What shipped and who is affected.
By Dillip Chowdary • Sep 26, 2026 • Source: HN Claude/Codex/Fable
In this post
Now I have all the source material. Here is the article:
Anthropic published a deep-dive guide on September 25, 2026 explaining how Claude Code's effort system works across Fable 5.1 and Opus 5.5, written by Thariq, a member of the Claude team. The guide surfaces eval data from Terminal Bench 3.0 and practical experiments to show when adjusting effort level meaningfully changes output quality — and when it does not.
This piece is for engineers who run Claude Code daily and want to understand the tradeoffs between speed, autonomy, and thoroughness before they commit tokens to a task. It covers what the effort system actually controls, which benchmark categories respond to it most, and how to wire effort levels into a real development loop.
01What shipped
Anthropic published "Using Claude Code: Spending your effort" on the claude.dev developer blog, accompanied by interactive diagrams and explainers not available in the thread itself. The post centers on a feature already live in Claude Code: per-session effort levels, adjustable mid-conversation with the /effort command, that tell Fable 5.1 and Opus 5.5 how much compute to dedicate to a given task.
The key technical property highlighted is that effort adjustments do not break the prompt cache, meaning developers can dial effort up or down during a session without paying the cold-cache token penalty that a full context reset would trigger. Thariq validated the effort curves by running evals across Terminal Bench 3.0, a community-sourced benchmark covering security, hardware, ML, science, operations, and media categories.
The experiments included three task shapes: an underspecified build task (a personal fitness tracker), a lightly specified design task (redesigning the /config menu in Claude Code), and a highly specified build task derived from an interview-generated spec. Across all three, effort governed how much independent judgment Claude exercised and how many autonomous decisions it made on behalf of the developer — not whether the task was attempted.
02What improved
Fable 5.1 and Opus 5.5 show measurable upticks in Terminal Bench 3.0 scores at each effort level. The improvement is not uniform across categories: security, hardware, and code review tasks benefit most from higher effort, while tasks with well-specified inputs converge at similar quality regardless of effort level. The table below captures concrete before/after numbers from the benchmark runs cited in the post.
| Task (Terminal Bench 3.0) | Low effort result | High / xhigh result | Time difference |
|---|---|---|---|
| html-js-filter (HTML sanitizer, Fable 5.1) | 1/5 | 5/5 at xhigh | ~2 min vs ~33 min |
| mvcc-lsm-compaction (storage-engine bug, Opus 5.5) | 0/5 | 4/5 at xhigh | ~1 min vs ~11 min |
| cli-2ph-simple (CLI LP solver, Opus 5.5) | 0/5 | 5/5 at high | ~10k tokens, no scale test |
| gsea-proteomics (GSEA on proteomics, Opus 5.5) | 0/5 | 4/5 at high | single-pass vs dual-prep |
| /config redesign (design task, Opus 5.5) | sketch in 1 min | polished mockup in 28 min | 28× time cost |
The pattern is consistent: higher effort reduces failures caused by missing edge cases but does not recover attempts where the model chose the wrong approach. A builder verifying this should confirm that their task is edge-case-sensitive before paying the time cost of xhigh.
03What you gain
The practical gain is a four-position dial that maps roughly to how much the developer wants to stay in the loop. At low effort, Claude responds in roughly a minute with a starting point that invites iteration; at max effort, it operates fully autonomously for up to 28 minutes or more and produces substantially more polished output — but makes proportionally more assumptions along the way.
For categories like security review and hardware design, those extra assumptions are precisely the edge-case checks that catch bugs a quick pass misses. For brainstorming or early-stage feature sketching, they are overhead.

The recommended development loop — have Claude interview you for missing spec details, implement on low effort, review and iterate on low effort, then verify and test on high effort — converts effort from a single-shot setting into a workflow instrument. A developer who previously ran all tasks at max effort to avoid reruns should verify whether their tasks are actually edge-case-heavy; the benchmark data suggests that for well-specified problems, high and max effort converge on similar designs, meaning the extra time cost does not always buy proportional quality.
04How to get it
Advertisement
Tech Pulse Daily
Get tomorrow's pulse first
Join engineers who read Tech Pulse before stand-up. Free, weekday mornings.
Claude Code ships through npm. To get the latest version with Fable 5.1 and Opus 5.5 support:
npm install -g @anthropic-ai/claude-codeOr update an existing install:
claude updateTo switch to Fable 5.1 inside a session:
/model claude-fable-5-1To launch Claude Code pinned to Fable 5.1 from the command line:
claude --model fableTo set the default model so every new session uses Fable 5.1 without a flag:
claude config set defaultModel claude-fable-5-1Once inside a session, change effort at any point without resetting the prompt cache:
/effort highValid levels are low, medium, high, and max. The interactive blog post at claude.dev/blog/spending-your-effort includes diagrams mapped to the Terminal Bench 3.0 results.
05What to watch next
The open question flagged in the thread is whether effort levels are a transitional mechanism — one reply to Thariq asks how close current models are to self-selecting compute duration based on perceived task difficulty. Anthropic has not published a timeline for that capability, but the current effort curves for Fable 5.1 and Opus 5.5 already show the model adjusting verification depth, edge-case coverage, and autonomous judgment based on the effort signal. Builders who want to stay ahead of the curve should track Terminal Bench 3.0 score movement across future model releases, particularly in the hardware and security categories where the effort delta is currently largest.
Developers running agentic pipelines with no human in the loop should also verify that their task prompts are well-specified before relying on max effort as a quality substitute. The benchmark data shows that wrong-approach failures — those caused by misunderstanding the task rather than missing edge cases — are not reduced by increasing effort, regardless of model. A pre-task interview step, as Thariq describes in his own loop, remains the most reliable way to close that gap before handing off to high or max effort runs.
Author
Dillip Chowdary
Writes Tech Bytes coverage of AI, engineering, and the tools that actually ship. Editor of Tech Pulse Daily.
Related on Tech Bytes
Advertisement