Using Claude Code: Spending Your Effort  🔗 **Source:** [Using Claude Code: Spending Your Effort](https://twitter.com/trq212/status/2103576349499855160/?rw_tt_thread=True) > [!note]+ Document Notes > --- > tags: [effort-levels, agent-supervision, verification, benchmark-analysis, specification-quality] > author: Thariq > source: Twitter/X long-form post > reference: https://claude.dev/blog/spending-your-effort/ > date created: 2026-09-25 > --- > > [!info] Generated analysis — not the author's words. Sections below are machine-written > > from the captured source. Only text inside `> [!quote]` blocks is verbatim from the author. > > Do not quote or attribute any other line to the named author. > ## 🏷️ Title > **"Using Claude Code: Spending your effort"** — Thariq, long-form post on X, September 2026. Roughly 1,930 words plus seven diagrams. An investigation of what the effort parameter actually changes, built from the author's own Terminal-Bench 3.0 runs plus a set of informal build tasks. > **Disclosed vendor position.** The author writes from inside Anthropic — *"our newest Claude models,"* *"measured during my eval runs for this post"* — and evaluates only Anthropic models. Stated rather than hidden, and it bounds what the piece can establish. See **Logical Validity**. > **Two documents already in this corpus bear on it directly**, and one converges on its sharpest finding from the opposite direction. See **Permanent Candidates**. > ## 🧭 Table of Contents > 1. [References (in-page)](#-references-in-page) > 2. [Summary](#-summary) > 3. [Main Content](#-main-content) → [Notes](#️-notes) > 4. [References](#-references) > 5. [Paraphrase](#️-paraphrase) > 6. [Newsletter](#-newsletter) > 7. [Action Items](#-action-items) > 8. [Hypotheses](#-hypotheses) > 9. [Methodology](#-methodology) > 10. [Questions](#-questions) > 11. [Future Research](#-future-research) > 12. [Implications](#-implications) > 13. [Learning Styles Assessment](#-learning-styles-assessment) > 14. [Accessibility Assessment](#-accessibility-assessment) > 15. [DEIB Assessment](#-deib-assessment) > 16. [Logical Validity](#-logical-validity) > 17. [DARVO Analysis](#️-darvo-analysis) > 18. [Conclusion](#-conclusion) > 19. [Refactor Appendix](#-refactor-appendix) > ## 🔗 References (in-page) > The markup was enumerated before any sourcing claim was made. > **Outbound links — two:** > 1. [claude.dev/blog/spending-your-effort/](https://claude.dev/blog/spending-your-effort/) — the author's own longer version with interactive diagrams, flagged in an italic note near the top. First-party. > 2. [github.com/harbor-framework/terminal-bench/releases/tag/v3.0.0](https://github.com/harbor-framework/terminal-bench/releases/tag/v3.0.0) — the benchmark release, with the full problem set. **This is the one that matters:** it makes the task descriptions independently checkable, and the author explicitly invites readers to go read them. > **Images — seven, all on Twitter's media CDN:** a lede card, the Terminal-Bench-3.0-scores-by-effort curve, three build-task comparison grids, the failure-taxonomy diagram, the problem-area breakdown, and the effort rule-of-thumb card. **None carries alt text** — every one appears as a bare `![Image]`. Four of them carry the quantitative backing for the article's claims. > **Sourcing assessment.** Two links, one first-party and one to a public benchmark whose contents can be verified by anyone. The benchmark link is doing real work: it is what separates this from a vendor blog post asserting its own numbers. What is absent is any third-party comparison — no competing model appears anywhere, and no independent replication is cited. The document is well-linked for what it claims; it is single-vendor for what it measures. > ## 📝 Summary > **What happened.** The author set out to answer what the effort parameter in Claude Code actually does, running the same tasks at different effort levels and reading the Terminal-Bench 3.0 results in detail. The finding: effort primarily buys *verification and edge-case testing*, plus a greater willingness by the model to exercise independent judgement. Higher effort helped most in domains where verification pays — hardware, code review, security. Low and medium suited work where the human stays in the loop. He reports his own working loop: have the model interview him for the spec, implement at low or medium, review, then verify at high. > **Why it matters.** Two findings go beyond the parameter. First, and stated explicitly against his own product's interest: increasing effort reduces failures from missed edge cases but *does not fix a wrong approach*. Second, when he supplied a detailed specification, the effort levels converged — the models behaved much more similarly. Together those say effort substitutes for verification labour and, in one case he names outright, for a human in the loop; it does not substitute for correct framing. > **Stakeholders.** Anyone operating a coding agent with a tunable effort or reasoning-budget setting; teams writing agent-usage policy; and, second-order, anyone deciding whether a quality problem should be solved by spending more compute or by specifying better. > **Risks.** The author works at Anthropic and evaluates only Anthropic models — disclosed in the first sentence, and it means no cross-vendor claim is available here. Sample sizes are five runs per condition. The illustrative cases were selected *because* effort helped in them, which he says plainly but which still means the examples cannot speak to how often that happens. And the cost side is nearly absent: one task goes from about 2 minutes to about 33, and no token or dollar figure appears anywhere in the recommendations. > **Bottom line.** A careful, experiment-backed explanation of a parameter, whose most valuable claim is a limit on what the parameter can do. Take the edge-case-versus-wrong-approach distinction and the spec-convergence finding; treat the per-task numbers as directional, from a single vendor at n=5. > ## 📖 Main Content > **The definition given is a resource-allocation one, offered through an analogy.** Effort is *"an approximation of how much compute you want it to spend on the task,"* related to your own estimate of its difficulty. The analogy: being asked to do something in twelve hours versus one hour changes not just how long you work but what kind of work you do — the twelve-hour framing invites thoroughness, the one-hour framing invites a best-available version and an expectation of iteration. It is a good intuition pump, and it quietly does something the rest of the piece then substantiates: it frames the variable as being about *posture* rather than about quality. > **The operational definition is the useful one:** > > [!quote] > > Claude will always try and do your task reasonably, but higher effort will involve Claude taking more independent action for judgement and verification. > Two distinct things are bundled there — more verification, and more independent judgement — and the rest of the article shows they have very different value depending on whether a human is present. > **The build experiments isolate what changes when the task is underspecified.** Asked to "build a personal fitness and workout tracker app," low effort produced a log and a simple graph; max effort produced something considerably more elaborate, down to a heat chart. The author's reading is the right one: the difference is not only completeness but *how many choices the model made on his behalf*. His conclusion is a matter of intent rather than quality — low effort if you want a base to iterate from, max if you want the model's best single shot. > **The design task is where he argues against his own instinct**, and it is the most interesting of the three. Asked to redesign the `/config` menu in Claude Code, every pass reached roughly the same idea — submenus and better search. Low effort took about a minute and produced an interactive sketch that conveyed the idea without looking much like Claude Code. Max effort took about 28 minutes and produced a polished mockup plus walkthroughs for several flows. His preference: > > [!quote] > > For this particular task, I think I prefer using low effort to understand Claude's vision. > That is a 28-fold difference in wall-clock time for an output he considers *less* suited to his purpose. When the goal is to see the idea and respond to it, polish is a cost rather than a bene  One of the best parts of our newest Claude models is how they respond to effort without breaking the prompt cache in Claude Code, but I’ve received a lot of questions on this from users. What is effort really and when do you use which effort level? Why do we need effort at all? To answer this, I decided to do a deep dive into the evals and do my own tests of effort across normal work. *note: you can see more interactive diagrams and explainers for this post on https://claude.dev/blog/spending-your-effort/* At a high level, I found that effort was a great way of changing how much verification and edgecase testing Claude did and how much of its own judgement it used. Extra effort gave better results in areas where verification and edgecase testing was more useful like hardware, code review, and security. But low and medium effort was perfect for getting things done quickly and staying in the loop with Claude. For normal software engineering, I’m now running a loop of getting the model to interview me then implementing on low/medium effort, reviewing what it built, and then running verification on high effort. ### What is effort? At a high level, effort gives the model an approximation of how much compute you want it to spend on the task. It’s somewhat related to your modeling of the difficulty of the task. Think of it this way, if someone asked you to do something in 12 hours straight, you might assume they just want you to do it and try very hard. If someone asked you to do the same task in 1 hour, you’d try to get them the best version that meets their task and then expect to iterate from there. Or, you might push back and say the task requires at *least* 3 hours and then work for 3 hours to deliver it. You should think of effort in the same way. Claude will always try and do your task reasonably, but higher effort will involve Claude taking more independent action for judgement and verification. ### Effort curves Fable 5.1 and Opus 5.5’s effort curves are our best yet, at each level if there is an uptick in benchmark scores and tokens consumed. Below is a graph of Terminal Bench 3.0 scores by effort, measured during my eval runs for this post.  But what does this mean in practice? To evaluate this, I tried several tasks at different effort levels and poured over the benchmarks. ### Building with effort The best way to understand how models work is to run experiments. I tried doing the same tasks at several different effort levels on Opus 5.5 understand the work it would do. I did this on a wide variety of work, but am illustrating this with a few toy examples. #### Underspecified build task If I ask Claude to “build a personal fitness and workout tracker app,” effort changes dramatically how fleshed out the app is, but also results in Claude making more choices along the way. At low effort, the fitness app is just a log and a simple graph. At higher effort levels the app is more complex with additional detail. At max effort there’s a heat chart.  If I wanted a simple base to iterate from, low effort would get it done. Max effort would be if I wanted Claude’s best one shot. #### Lightly specified design task What if I have a task that is fairly specified already but I want some exploration with Claude? As an example I tried to ask it to redesign the /config menu in Claude Code. Every pass had roughly the same idea, to use submenus and better search. At low effort (which took 1 minute), I got an interactive sketch that conveyed the idea but didn't look very much like Claude Code. At max effort (which took 28 minutes), I got a mockup that looked very much like Claude Code, along with a bunch of walkthroughs for different flows. If my goal was to iterate and give feedback, low effort would get there much faster. But max effort gives me something much more polished right off the bat. For this particular task, I think I prefer using low effort to understand Claude’s vision.  #### Highly specified build task What if I gave Claude lots of details? I tried asking Claude to interview me in-depth about the fitness app and then gave that spec to be implemented by different models at different effort levels. I found that given this spec, the models behaved much more similarly. I got designs that looked fairly similar and had similar implementations but with different details, at max effort Claude took some time to simplify a few of the details.  #### Takeaways For regular software engineering, particularly new feature work, the effort level depends a lot on how in the loop I want to be. Low effort allows Claude to respond quickly with a starting point, higher effort levels will get more work done but Claude will also make more assumptions on my behalf. A particularly fruitful loop for feature development I’ve been using is: * Give Claude a spec and ask it to interview me about any details I’m missing * Implement it on low effort * Review to make sure it got the gist of it correct, iterate on low effort as needed * Verify and test on high effort ### How effort levels impact output on difficult tasks But these are obviously toy examples, where Claude is well able to complete them. What about when the difference is between Claude completing the task or not completing the task? To find these difficult problems, you have to go to the benchmarks so I dove into one I like: Terminal Bench 3, a community sourced benchmark. Terminal-Bench 3.0 problems can broadly be separated into categories like security, hardware, ML, science, software, operations and media. You can see all of the problems here: <https://github.com/harbor-framework/terminal-bench/releases/tag/v3.0.0>, they’re sourced from the community so anyone can contribute. It’s worth reading to get a sense of the type of problems these models face. I found I was surprised by the scope and ambition of a lot of these tasks. The are much more complicated than the average task I’d face. For example, some of the tasks included: * **Hardware** (retro-console-soc): build an 8-bit game console in Verilog that fits a small FPGA and renders a test ROM. * **Science** (takens-embedding-lean): formally prove Takens’ embedding theorem in Lean 4. * **ML** (mp-checkpoint-consolidation): merge 16 shards of a mixture-of-experts checkpoint into one file that reproduces the reference logits. * **Operations** (intrastat-meldung): run a company’s month-end EU trade-statistics filing end to end. * **Media** (layout-config-recreation): rebuild a poster image as an editable layout file. #### Higher effort levels help when there are many edge cases My main takeaway from reading the Terminal Bench 3 results was that **higher effort is best for tasks with lots of hidden edge cases.** A clean example is html-js-filter, a Terminal-Bench 3.0 task that asks for an HTML sanitizer that strips every way of smuggling JavaScript into a page. Fable 5.1 went from 1/5 at low to 5/5 at xhigh. A typical attempt at low effort takes about 2 minutes. Each of these attempts wrote a filter in roughly one pass, then tested it against a single hand-written page. A high effort run finishes in about 33 minutes. In the run I traced, it adversarially reviewed its first draft, then read the installed parser’s source to check for bugs, ran many clean test cases until they gave the same output as the input, ran a standard XSS test suite, and finally, wrote a random-document fuzzer. For something as edge-cased as a HTML sanitizer, this extra effort is well worth it. Spending more tokens for thoroughness also makes sense for complex tasks with high production requirements such as performance optimization or security review. But you don’t need this level of effort for every task. The diagram below shows every Terminal-Bench 3.0 result and how it failed, across different models and effort levels. Overall, increasing effort tends to reduce failures due to missing edgecases (purple blocks), but does not fix when the model has the wrong approach (blue blocks).  #### Problem areas where effort helps One of the most interesting takeaways for me from evaluating these models on TerminalBench was that there were some problem areas that benefited from effort more than others. You can see a breakdown in the following diagram:  To illustrate this, I chose a few problems from different areas from Terminal Bench 3.0 where Opus 5.5 failed at low effort but succeeded at high effort–mostly because it tested and accounted for edge cases: **mvcc-lsm-compaction:** a Terminal-Bench 3.0 task that asks for a fix to a storage-engine bug from its crash report, without breaking compaction. Opus 5.5 went from 0/5 at low to 4/5 at xhigh. At low (about a minute per attempt), Claude would edit the code before building it or running the reproducer, and did not check that its new test would have caught the original bug. At xhigh (about 11 minutes), Claude reproduced the crash first, wrote a randomized test against a reference that never compacts, and checked that its tests failed on half-finished fixes. **cli-2ph-simple:** is a Terminal-Bench 3.0 task that asks for a CLI linear-program solver written in Python. Opus 5.5 went from 0/5 at low to 5/5 at high. The low attempts wrote a solver in one pass, checked it with a few small problems and stopped around 10k tokens. In the final message, Claude warned it might be slow on big problems, but did not check. During the high attempts Claude tested its solver on random problems against a separate brute-force solver, then timed bigger ones, hit cases that ran far too long or crashed, and reworked its search. **gsea-proteomics**: a Terminal-Bench 3.0 task that asks for a gene set enrichment analysis (GSEA) on proteomics data to find which of eight treatments resemble a target tissue. Opus 5.5 went from 0/5 at low to 4/5 at high. At low effort, Claude picked a reasonable-sounding way to prep the data, ran the analysis that one way, and reported the result. At high Claude tried two ways of prepping the data, it noticed that the list of significant treatments changed, and dug into why before choosing the correct one. If a user were in the loop, Claude may have asked the user about the way to setup the problem, but without a user in the loop high effort does better. #### When to use different effort levels in Claude Code Here’s my rule of thumb on when to use which effort level: * **Low**: for when I want quick responses that are in the loop, e.g. brainstorming, sketching, easy changes * **Medium**: for most of my regular software engineering work, e.g. new feature implementation. * **High**: for work where verification is important or there are edge cases, e.g. fixing a bug in a brownfield codebase. * **Max**: When I want Claude to operate fully autonomously to solve difficult problems, e.g. end to end building and verification of an app, finding security vulnerabilities in critical software. Try varying effort for Opus 5.5 and Fable 5.1 based on your task or even mid-conversation by using /effort in Claude Code and let me know if this matches your intuition., Using Claude Code: Spending Your Effort, Thariq, 01m3d55zw9tq49rtt08z3stt03.