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. > <!-- deep-read:sections start --> ## 🏷️ 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 benefit. **The third experiment is the one with the largest implication and the least emphasis.** Given a detailed specification — produced by having the model interview him first — *"the models behaved much more similarly. I got designs that looked fairly similar and had similar implementations but with different details."* Specification collapses the effort difference. The obvious corollary, which the article does not state: if you are reaching for more effort to fix an underspecified task, you may be buying with compute what you could have obtained with a better prompt. That reading is consistent with everything else in the piece and is set out in **Permanent Candidates** below. **The recommended loop follows from all three**, and its shape is worth noting: spec by interview, implement at low, review, *then* verify at high. Effort is applied at the verification step, not the generation step — which matches the finding that verification is what effort actually buys. **The benchmark section moves from toys to hard problems, and the author says so.** Terminal-Bench 3.0 is community-sourced and spans security, hardware, ML, science, software, operations and media. The sampled tasks are genuinely demanding — an 8-bit game console in Verilog fitted to a small FPGA; a formal proof of Takens' embedding theorem in Lean 4; merging sixteen shards of a mixture-of-experts checkpoint to reproduce reference logits; an end-to-end EU trade-statistics filing; rebuilding a poster as an editable layout file. He notes he was *"surprised by the scope and ambition"* and that these exceed his own typical work, which is an honest framing of what the benchmark can and cannot tell him about ordinary tasks. **The headline benchmark finding is stated in bold and supported by a traced run.** Higher effort is best for tasks with many hidden edge cases. The clean case is `html-js-filter`, which asks for an HTML sanitizer that blocks every route to smuggling JavaScript into a page: Fable 5.1 went from 1/5 at low to 5/5 at xhigh. The contrast in *behaviour* is more informative than the score. A low-effort attempt took about two minutes and wrote a filter in roughly one pass, tested against a single hand-written page. The high-effort run took about 33 minutes and, in the traced instance, adversarially reviewed its own first draft, read the installed parser's source for bugs, ran many clean test cases checking output against input, ran a standard XSS suite, and finally wrote a random-document fuzzer. That is not a better one-pass answer. It is a testing programme. **The single most valuable sentence in the article limits its own subject:** > [!quote] > 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). Effort buys thoroughness within a chosen approach. It does not buy a better choice of approach. Someone at the vendor, writing about the vendor's parameter, publishing the case where the parameter does not help — that is the kind of claim that makes the rest more credible, and it is also the finding with the widest application. **Three further cases illustrate the mechanism, and each shows verification behaviour appearing rather than cleverness.** On `mvcc-lsm-compaction` (fix a storage-engine bug from a crash report without breaking compaction), Opus 5.5 went 0/5 at low to 4/5 at xhigh: at low, about a minute per attempt, it edited code before building or running the reproducer and never checked that its new test would have caught the original bug; at xhigh, about eleven minutes, it reproduced the crash first, wrote a randomised test against a reference implementation that never compacts, and verified its tests failed against half-finished fixes. On `cli-2ph-simple` (a CLI linear-program solver), 0/5 to 5/5: the low attempts wrote a solver in one pass, checked a few small problems, stopped near 10k tokens, and *warned* the solution might be slow on large inputs without testing whether it was; the high attempts tested against a separate brute-force solver, timed larger problems, hit cases that ran far too long or crashed, and reworked the search. **The third case names a substitution the others only imply.** On `gsea-proteomics`, low effort picked a reasonable-sounding data preparation, ran the analysis one way, and reported. High effort tried two preparations, noticed the set of significant treatments changed between them, and investigated before choosing. Then: > [!quote] > 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. High effort is standing in for a question that would otherwise have been asked of a human. That reframes the whole parameter: effort is partly a substitute for supervision, and its value therefore depends on whether supervision is available — which is exactly why the author's own loop uses low effort while he is watching and high effort when he is not. **The closing rule of thumb is clear and has one conspicuous omission.** Low for quick in-the-loop responses — brainstorming, sketching, easy changes. Medium for most regular software engineering. High where verification matters or edge cases lurk, such as a bug in a brownfield codebase. Max for fully autonomous work on hard problems: end-to-end build and verification, or finding security vulnerabilities in critical software. The omission is cost. A recommendation framework for a parameter whose whole function is spending more compute contains no compute figure, no time figure, and no guidance on when the spend stops being worth it. ## 🗒️ Notes - **The limiting finding is the most valuable one.** Effort reduces edge-case failures and does not fix a wrong approach. Published by the vendor, about the vendor's own parameter. - **Specification collapses the effort difference.** Given a detailed spec, models at different effort levels produced similar work. The unstated corollary: reaching for more effort on an underspecified task may be buying with compute what a better prompt would supply. - **Effort substitutes for a human in the loop**, stated outright in the `gsea-proteomics` case. That explains why the author's own loop inverts the usual instinct: low while he is watching, high when he is not. - **The behavioural traces are more informative than the scores.** "Wrote a fuzzer," "reproduced the crash first," "tested against a brute-force reference," "checked its tests failed on half-finished fixes" — these are descriptions of a testing discipline appearing, not of a model getting smarter. - **The cli-2ph-simple detail is the sharpest small observation in the piece.** At low effort the model *warned* its solver might be slow on large problems and did not check. It identified its own risk and did not act on it. That is a precise picture of what low effort withholds. - **28 minutes versus 1 minute, and he prefers the 1-minute output.** For a task where the goal was to see the idea, polish was a cost. Worth remembering whenever "better" is assumed to mean "more." - **The illustrative cases were selected on the outcome.** He writes that he chose problems "where Opus 5.5 failed at low effort but succeeded at high effort." The criterion is stated openly; it still means these examples cannot speak to frequency. - **n=5 per condition.** 0/5 → 4/5 is a striking contrast and a small sample. - **Single-vendor throughout.** No competing model appears anywhere in the analysis. - **Cost is absent from the recommendations.** One task runs 2 minutes to 33; no token or dollar figure accompanies any of the advice. - **The failure taxonomy exists only as an un-alt-texted diagram**, with the purple/blue distinction carried by colour. The prose rescues it by describing the finding in words — fortunately, since it is the article's best claim. - **Capture is clean and complete.** Full body, all seven image positions, no truncation or widget furniture. ## 📚 References **Primary, linked, and genuinely verifiable:** - [Terminal-Bench 3.0 release](https://github.com/harbor-framework/terminal-bench/releases/tag/v3.0.0) — the community-sourced benchmark, with every problem readable. The author invites readers to go look, which is the correct move and the thing that distinguishes this from an unfalsifiable vendor claim. Task names cited: `html-js-filter`, `mvcc-lsm-compaction`, `cli-2ph-simple`, `gsea-proteomics`, `retro-console-soc`, `takens-embedding-lean`, `mp-checkpoint-consolidation`, `intrastat-meldung`, `layout-config-recreation`. - [claude.dev/blog/spending-your-effort/](https://claude.dev/blog/spending-your-effort/) — the fuller version with interactive diagrams. First-party; the place to go for the charts this capture lost. **Companion documents in this corpus:** - *"You should all be asking way more questions"* (Sean Goedecke) — argues models make design mistakes rather than code mistakes, because they lack accumulated environment context. This article's edge-case-versus-wrong-approach finding is the same claim measured from the inside. Read together. - *"I was using Fable wrong, this is how I fixed it"* (Theo) — covers the same effort parameter from a practitioner's seat and reaches a partly opposite operational conclusion. The tension is productive and is worked out in **Logical Validity**. **Not present and worth seeking:** - Any third-party or cross-vendor evaluation of effort scaling. - Token counts and cost per effort level on the benchmark tasks — the missing axis in every recommendation here. - The base rate: across *all* Terminal-Bench 3.0 tasks, on what share does raising effort change the outcome? The illustrative cases were chosen because it did. - Any independent replication of the n=5 results. **Sourcing assessment.** Well-linked, and the benchmark link makes the central claims checkable by a third party — which is more than most vendor-authored evaluation writing offers. The limit is scope, not citation: one vendor, its own models, its own runs. ## 🗣️ Paraphrase *Restated in the analyst's words. None of the following is the author's phrasing.* **The question.** Users kept asking what the effort setting actually does and when to change it, so the author investigated — reading the benchmark results closely and running his own comparisons across ordinary work. **The answer in brief.** Raising effort mainly increases how much checking and edge-case probing the model performs, and how much it decides for itself. Domains where checking pays — hardware, reviewing code, security — benefit most. Lower settings suit work where the person stays involved and wants quick turns. **What effort is.** A rough statement of how much computation you are willing to have spent, which tracks your own sense of how hard the task is. The comparison offered: being given twelve hours for something invites exhaustive work, while being given one invites a decent version and an expectation of revision. **The vague-request experiment.** Asked for a fitness tracking app with no further detail, the model produced a bare log at the lowest setting and something considerably richer at the highest — more features, and more decisions taken without asking. **The design experiment.** Asked to rework a settings menu, every attempt arrived at the same core idea. A one-minute attempt gave a rough but communicative sketch; a 28-minute attempt gave a polished mockup with several flows worked through. For the author's purpose — understanding what the model had in mind — the rough one served better. **The detailed-brief experiment.** When the author first had the model question him thoroughly and then handed over the resulting brief, the different settings produced noticeably similar work. A clear brief narrowed the gap. **His routine.** Have the model interview him to surface what he left out; build at a low setting; check that the idea landed and revise cheaply; then raise the setting for testing and verification. **On genuinely hard problems.** Turning to a public benchmark of demanding tasks — formal proofs, hardware design, regulatory filings — the pattern was that higher settings helped where many failure modes hide. A sanitiser task went from almost always failing to always succeeding. The difference in conduct is the point: the cheap attempts wrote something and tried one example; the expensive attempt attacked its own draft, inspected the library's source, ran a standard attack suite, and built a fuzzer. **The limit.** Across all results, spending more reduced failures caused by overlooked cases but did not rescue attempts that had taken the wrong route to begin with. **Three worked cases.** Fixing a storage bug: cheaply, it edited code before reproducing the fault; expensively, it reproduced first and confirmed its test would have caught the original problem. Writing a solver: cheaply, it flagged a possible performance issue without testing for it; expensively, it measured, found real failures, and redesigned. Analysing proteomics data: cheaply, it chose one preparation and reported; expensively, it tried two, noticed the conclusions diverged, and worked out which was right — a question, the author notes, it might simply have asked a person had one been present. **The recommendation.** Lowest for quick exchanges while you watch. Middle for ordinary development. High where correctness must be demonstrated or the ground is treacherous. Highest when the model is working unsupervised on something genuinely hard. ## 📰 Newsletter **More effort buys thoroughness, not judgement** There is a sentence in Thariq's [effort walkthrough](https://claude.dev/blog/spending-your-effort/) that deserves to outlive the parameter it describes, and it is a sentence limiting his own product: > 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). Spend more, and the model tests harder inside the approach it already chose. It does not choose better. Someone at the vendor published the case where the dial does not help, which is the main reason to believe the rest. Put that beside Sean Goedecke's piece from the same week — models rarely write broken code any more, they write broken *designs*, assuming two services can talk when they cannot — and you have the same finding arriving from two directions, one from a practitioner watching agents fail and one from a vendor counting failures on a benchmark. Wrong approach is the residual category in both. Turning up the compute does not touch it. The behavioural traces are the fun part. On an HTML sanitiser task, the cheap runs wrote a filter in one pass and tested it against a single hand-written page. The expensive run tore into its own first draft, went and read the parser library's source looking for bugs, ran a standard XSS suite, and then — this is the bit — *wrote a fuzzer*. That is not a smarter model. That is a testing programme showing up. And on a solver task, the cheap attempts warned the code might be slow on large inputs and then did not check. It spotted its own risk and shrugged. If you want one sentence for what low effort withholds, that is it. Two things WordPress people can use tomorrow. **One: a good spec flattens the difference.** When he had the model interview him first and handed over the resulting brief, the effort levels converged — similar designs, similar implementations. Which means if you are reaching for more compute to fix a vague request, you are buying with tokens what a better ticket would have given you for free. Every plugin maintainer who has watched an underspecified issue produce three wrong PRs already knows this; it is pleasant to see it measured. **Two: effort substitutes for you.** On a data-analysis task the high-effort run tried two preparations, noticed the answers diverged and investigated — and the author says plainly that with a person in the loop it would likely just have *asked*. So the dial is partly a proxy for supervision, which is why his own routine looks backwards at first glance: low effort while he is watching, high effort when he is not. If you are sitting there, be cheap and fast. If you have gone to bed, pay for the paranoia. One genuine gap, and it is the same one the DocsBot reranking write-up in this batch kept hammering: **there is no cost axis anywhere.** A design task runs 1 minute at low and 28 at max. The sanitiser goes 2 minutes to 33. The recommendation section — low for sketching, max for autonomous security work — contains no token figure, no dollar figure, and no word about when the spend stops paying. Measure the whole bill, including the part your change added. Also, for a piece whose best finding is encoded in purple and blue blocks on a chart: seven images, not one alt attribute among them. The prose rescues it. It should not have to. ## ✅ Action Items **Core AI** - Adopt the distinction explicitly in any agent-assisted contribution guidance: raising effort addresses thoroughness within an approach, not the choice of approach. A wrong-approach failure needs review or better framing, not more compute. - The recommended loop is directly adoptable — spec by interview, implement cheap, review, verify expensive. Note that it applies effort at the *verification* step, which is what the evidence supports. **Documentation / Core Program Team** - The spec-convergence finding is an argument for issue-template quality with a measurable payoff: a well-specified ticket narrows the gap between a cheap and an expensive attempt at it. That is a stronger case for template work than "it helps contributors." **Core / Core Performance** - The verification behaviours named here are a usable checklist for any agent-assisted patch on tricky code: reproduce the fault before editing, confirm the new test fails against the unfixed version, test against a reference implementation, measure rather than warn. - `cli-2ph-simple` is the cautionary one — a model that flags a performance risk without testing it. If an agent's output contains a caveat, treat the caveat as an untested claim. **Security** - The sanitiser case is the most transferable: high effort produced adversarial self-review, source reading, a standard attack suite and a fuzzer. Those are the behaviours to require of agent-assisted security work, whether or not a parameter produces them. - Note the author's own placement of "finding security vulnerabilities in critical software" at max effort — and that his data says it still will not rescue a wrong approach. **Support / Community** - The effort-substitutes-for-supervision finding has a plain reading: if a person is available to answer a question, asking beats spending. Relevant to any triage automation design. **Training** - Teachable in one line: more effort buys checking, not judgement. Pair with the spec-convergence result for a lesson on why writing the requirement well is the higher-leverage move. **Meta / Playground** - If agent-assisted contribution grows, an effort or budget policy per task class is a real configuration question, and it needs a cost column the source does not supply. **DevRel** - A well-calibrated talking point about agent limits that is neither hype nor dismissal, and it comes from the vendor's own measurements. **OSPO** - Note the disclosed vendor position when citing: single vendor, own models, own runs, n=5. The benchmark is public, which makes the claims checkable — worth stating both halves. **Remaining subteams** (Mobile, Marketing, Design, Photos, TV, Polyglots, Accessibility, CLI, Hosting, Tide, Openverse, Themes, Plugins) **/ FAIR / The WPOCC** - No direct action. The Core AI and Documentation items carry the general value. ## 🧪 Hypotheses 1. **Specification quality and effort level are substitutes for a bounded range of tasks, and the substitution has a measurable exchange rate.** *Testable:* run the same underspecified task at max effort and the same task well-specified at low effort; compare outcome quality and total token spend. The spec-convergence finding predicts the specified-low condition wins on cost at equal quality. 2. **Effort reduces edge-case failures and leaves wrong-approach failures approximately flat.** The article's central claim, stated as a trend from one diagram. *Testable:* classify every Terminal-Bench failure by category across effort levels and check whether the wrong-approach count is statistically flat. The data to do this already exists in the author's runs. 3. **Where a human is available to answer one clarifying question, that question outperforms raising effort at lower total cost.** *Testable:* on tasks with a genuine setup ambiguity, compare a low-effort run with one clarifying exchange against a high-effort unsupervised run; measure correctness and total time. 4. **The share of Terminal-Bench tasks where effort changes the outcome is much smaller than the illustrative cases imply.** The cases were selected because effort helped. *Testable:* report the base rate across all tasks — a number the author already has. 5. **Beyond some effort level, added verification produces diminishing correctness per token on tasks with few edge cases.** *Testable:* plot correctness against tokens by task category; the article's own category breakdown predicts the curve flattens early for low-edge-case domains. 6. **An agent that states a caveat without testing it at low effort will test that same caveat at high effort.** From `cli-2ph-simple`. *Testable:* collect low-effort outputs containing hedges, re-run at high effort, and measure how often the hedge becomes a measurement. ## 📊 Methodology **The source's method.** Two strands. First, informal comparison: the same task run at several effort levels on Opus 5.5 across three deliberately chosen shapes of request — underspecified, lightly specified, and heavily specified — reported qualitatively with wall-clock times. The author calls these toy examples himself. Second, benchmark analysis: his own runs of Terminal-Bench 3.0, reported as success ratios out of five per condition, plus traced behavioural descriptions of individual runs, plus a failure taxonomy separating missed-edge-case failures from wrong-approach failures. The benchmark is public and linked, so the task definitions are independently checkable even though the runs are not. The method's real strength is the failure taxonomy: classifying failures by *type* rather than counting them is what produces the limiting finding, and that finding runs against the author's interest. Its weaknesses are stated or visible: n=5, single vendor, and illustrative cases chosen on the outcome by an explicitly stated criterion. **This analysis's method.** The captured body was read in full and its markup enumerated before any sourcing claim was made — two outbound links, seven images, none with alt text. The links were classified by target, which produced the observation that one is first-party and one is a public benchmark whose contents a third party can verify. The case-selection criterion was taken from the author's own sentence describing how he chose the illustrative problems, so the selection finding is a reading of the text rather than an inference about intent. The convergence with the Goedecke document already in this corpus was checked by comparing the two claims in their own terms — wrong-approach failures here, design-versus-code errors there — rather than assumed from topical similarity. The tension with the Theo document was likewise resolved by locating the condition each author was writing under (supervised versus unsupervised), which reconciles them rather than declaring one wrong. **Limits.** Neither the benchmark repository nor the author's longer blog version was consulted. The seven diagrams were unavailable, so four quantitative claims rest on the prose alone — including the failure taxonomy, whose purple/blue distinction exists as prose here only because the author happened to describe it in words. No independent verification of any reported score was attempted, and none is claimed. ## ❓ Questions - What share of all Terminal-Bench 3.0 tasks change outcome with effort? The illustrative cases were chosen because they did; the base rate is the number that would make them interpretable. - What does each effort level cost in tokens on these tasks? Wall-clock times are given for a few; spend is given for none. - Is the wrong-approach failure count genuinely flat across effort levels, or merely flatter? "Does not fix" is a strong claim resting on a described trend in an unavailable diagram. - How far does spec convergence go? At what point does a specification become good enough that effort stops mattering at all? - Does the effort-substitutes-for-a-human finding hold generally, and what is the exchange rate — how much compute equals one clarifying question? - Do other vendors' reasoning-budget parameters show the same edge-case-versus-approach split? If so it is a property of the technique, not of one implementation. - Why does the author prefer low effort for the design task? "Understanding Claude's vision" suggests something about legibility that the article does not develop. ## 🔮 Future Research - **Publish the base rate.** Across all Terminal-Bench 3.0 tasks, how often does raising effort change the result? The author has this data and it would reframe the illustrative cases. - **Add the cost axis.** Correctness per token by task category would convert a rule of thumb into an economic recommendation. Nothing in the piece currently tells a reader when to stop paying. - **Test the spec-versus-effort exchange directly.** The most useful follow-up available, and the cheapest: well-specified-low against underspecified-max, measuring both quality and spend. - **Check the wrong-approach flatness statistically**, rather than as a described trend. - **Seek cross-vendor replication.** If the edge-case/approach split appears in other implementations, it is a fact about reasoning budgets rather than about one product. - **Read the benchmark tasks directly.** The repository is linked and public, and the author is right that the task descriptions are worth reading in their own right. ## 💡 Implications **Practice.** Two immediately usable rules. Apply effort at verification rather than generation — which is what the author's own loop does and what his evidence supports. And when tempted to raise effort on a vague task, write the spec instead; the convergence finding says that is the cheaper purchase of the same improvement. **Policy.** Any organisational guidance on agent use should distinguish the two failure classes, because they need different remedies: missed edge cases respond to compute, wrong approaches respond to review and framing. A policy that treats "turn it up" as the general answer to quality will systematically fail on the second class while spending more. **Security.** The most directly applicable section. The behaviours high effort produced on the sanitiser task — adversarial self-review, reading the parser's source, running a standard XSS suite, writing a fuzzer — are the right expectations for agent-assisted security work, and they are specifiable as requirements independent of any parameter. The necessary caution sits in the same article: effort does not rescue a wrong approach, so a thorough exploration of the wrong threat model remains wrong, and thoroughly so. **Education.** "More effort buys checking, not judgement" is a one-line teachable that resists both AI hype and AI dismissal. The spec-convergence result pairs with it to make the case that writing the requirement well is the higher-leverage skill — which is a more useful thing to teach than parameter tuning. **Funding.** A parameter whose function is to spend more compute, recommended without any cost figure, is an open-ended commitment. For volunteer or grant-funded projects the relevant question is not which effort level is best but which is affordable at the volume actually needed — and the article supplies nothing to answer that. ## 🧠 Learning Styles Assessment - **Visual.** Strong in intent, absent in the capture. Seven diagrams carry the effort curves, three build-task comparisons, the failure taxonomy and the recommendation card. None survives as information. The author explicitly points to the blog version for interactive versions, which is a genuine mitigation. - **Aural.** Not applicable to this source. No audio or video component. - **Verbal.** Strong. Clear declarative prose, each concept introduced before use, behavioural traces described concretely enough to picture. - **Kinesthetic.** Moderate and real. The benchmark is public and linked, the tasks are runnable, and `/effort` is a command the reader can try mid-conversation — the closing invitation is to go experiment. - **Logical.** The dominant mode. A definition, three controlled comparisons, a benchmark analysis, a failure taxonomy, and a rule of thumb that follows from the findings. The chain is easy to follow and, where the diagrams are missing, partly uncheckable. - **Social.** Weak. One author reporting his own experiments; the closing invites replies, which is the only social element. - **Solitary.** Strong. Self-contained, linear, about ten minutes. - **Naturalistic.** Not applicable to this source. No environmental or natural-systems content. **Reading level.** Roughly US grade 12–13 for a technical audience. Sentences are short and clear; the load is domain vocabulary used unglossed — prompt cache, effort levels, edge cases, fuzzer, XSS suite, compaction, logits, mixture-of-experts, brownfield. A working developer reads it easily; the benchmark-task descriptions alone would stop most other readers. ## 📊 Accessibility Assessment Mapped to WCAG 2.2 AA, assessed against the captured artifact. 1. **Text alternatives (1.1.1 Non-text Content).** Fails, and materially. Seven images, every one a bare `![Image]` with no alt text. Four carry quantitative content: the effort-versus-score curve, the failure taxonomy, the problem-area breakdown, and the recommendation card. A reader using assistive technology loses the evidence for four claims. 2. **Time-based media (1.2.x).** Not applicable to this source. No audio or video. 3. **Adaptable / info and relationships (1.3.1).** Passes. Clear heading hierarchy, semantic lists for the task examples and the rule of thumb, bold used for genuine emphasis on the central findings. 4. **Distinguishable — use of colour (1.4.1).** **The most serious failure here.** The article's best finding is expressed as *"purple blocks"* versus *"blue blocks"* in a diagram — information conveyed by colour alone, inaccessible to a colour-blind reader and invisible to a screen-reader user. The prose does state the finding in words, which rescues it entirely; that rescue appears to be incidental rather than designed, and it is the only reason the claim survives this capture. 5. **Navigable / link purpose (2.4.4).** Passes. Both links are bare URLs in context that explains them — the blog is introduced as having interactive diagrams, the repository as the place to see all the problems. 6. **Readable (3.1.3 Unusual Words).** Partially fails outside the target audience. Fifteen or more technical terms appear unglossed. Appropriate for the readership, a hard stop beyond it. 7. **Robust / parsing (4.1.x).** Passes as captured. Clean linear text, no widget furniture, no interface controls in the reading order. **Overall.** The prose is well structured and the key findings are stated in text, which limits the damage considerably. The single highest-value fix is alt text on the failure-taxonomy diagram, followed by replacing the colour-only encoding with a pattern or a direct label — the article's most important claim should not depend on distinguishing purple from blue. ## 🌍 DEIB Assessment **Cultural breadth.** Narrow and unmarked, in the ordinary way of technical writing. English only, US-centric development framing, and an implicit assumption of unmetered access to compute. Worth noting that the whole subject — choosing how much computation to spend — presumes a budget that makes the choice free, which is not the position of most developers globally or of most volunteer projects. The article never mentions cost, so it never engages the question of who can afford max effort. **Inclusive language.** Clean. No gendered pronouns; the model is consistently "it." No idiom or culture-specific metaphor beyond the twelve-hours-versus-one-hour framing, which translates well. First person throughout, describing what the author tried rather than instructing the reader — "I tried," "I found," "I'm now running a loop" — which keeps the register collegial rather than authoritative. **Neurodiversity support.** Good. Short sections with descriptive headings, one finding each, concrete examples immediately after each abstraction, bold marking the load-bearing claims for scanning, and a summary rule of thumb at the end that does not require holding the preceding argument in memory. The missing alt text is the one real cost, for readers who depend on the visual encoding of a numeric relationship. **Representation.** One named author, no people depicted. Not applicable in the usual sense. One neutral observation: the benchmark tasks span hardware, formal proof, ML infrastructure, EU regulatory filing and media production, which is unusually broad for a coding benchmark and is worth crediting — community sourcing appears to have produced a wider problem set than a single vendor would likely have written. **Psychological safety.** Positive, and in a specific way worth recording. Publishing the finding that your own product's parameter *does not* fix a class of failures lowers the cost for everyone else of stating limits, and it is a costly signal in a field where confident claims dominate. The author also states a preference against the most expensive setting for one task — a small thing that models the idea that more is not automatically better. The closing invitation to reply if the framework does not match the reader's intuition is a genuine, if minor, opening for disagreement. ## ✅ Logical Validity **Strong reasoning.** The argument is built from experiments rather than assertion, and the experiments are chosen to vary one thing that matters — the degree of specification — across three otherwise comparable tasks. The failure taxonomy is the methodological high point: classifying failures by *kind* rather than counting them is what yields the limiting finding, and that finding constrains the author's own subject. Behavioural traces are reported in enough detail to be checked against the public benchmark. Wall-clock times are given for the comparisons. The author states that his build examples are toys, states that the benchmark tasks exceed his ordinary work, states his selection criterion for the illustrative cases, and states his vendor position in the first sentence. He also records a case where he prefers the cheapest setting to the most expensive one. Each of those is a disclosure that makes the rest more credible. **Fallacies.** *Selection on the dependent variable — present, and disclosed.* **Located** in: *"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."* **Why it fails as evidence:** the cases are selected precisely because the effect being demonstrated occurred in them. They can show a *mechanism* — what the model does differently — but they cannot support any claim about how often effort changes an outcome, and a reader who skims will take the three dramatic 0/5-to-4/5 transitions as representative. **Why it is venial:** the criterion is stated plainly in the sentence that introduces them, and they are explicitly framed as illustration. **The fix:** report the base rate across all tasks alongside the examples. He has the data; one sentence would convert an illustration into a finding. *Single-vendor generalisation.* **Located** throughout — every claim rests on Anthropic models evaluated by an Anthropic employee. **Why it matters:** the framing ("what is effort," "why do we need effort at all") reads as a general account of a technique, while the evidence supports a claim about two specific models. Whether the edge-case/approach split is a property of reasoning budgets or of this implementation is unanswerable from here. **Why it is not concealment:** the "our models" phrasing is in the opening paragraph and the models are named throughout. **The fix:** scope the conclusions to the models tested, or add a competitor. *Small samples reported as clean transitions.* **Located** in "1/5 at low to 5/5 at xhigh," "0/5 at low to 4/5 at xhigh," "0/5 at low to 5/5 at high." **Why it is weak:** five runs per condition, and the fractions are presented without intervals. A 0/5-to-4/5 shift is suggestive and is not a measurement anyone should quote as precise. **The fix:** more runs, or intervals, or a plainer statement that these are small-sample illustrations. *Suppressed cost dimension — an omission with practical consequences.* **Located** in the closing rule of thumb, which recommends effort levels by task type with no token count, no price and no stopping rule. **Why it matters:** the parameter's entire function is to spend more, the article documents a 1-to-28-minute spread on one task and 2-to-33 on another, and none of that reaches the recommendation. A reader is told when higher effort *helps* and never when it stops being worth it. **The fix:** a correctness-per-token curve by task category, which the benchmark runs would already support. *Anthropomorphic analogy — minor.* **Located** in the twelve-hours-versus-one-hour framing. **Why it is slightly misleading:** it implies the model reasons about a deadline, when effort is a compute allocation. **Why it is fine in practice:** it is offered as an intuition pump, the operational definition follows immediately, and the rest of the article works from the operational one. **A productive tension with another document in this corpus, which is not a fallacy in either.** Theo's walkthrough of the same parameter concludes the opposite operationally — default to high, avoid low and medium, because a failed cheap run plus a retry costs more than one expensive run. Thariq's own routine uses low and medium for most work. Both are defensible because they describe different conditions: the retry-cost argument holds when nobody is watching and a failure is discovered late, while low effort wins when a human reviews immediately and iterates. Thariq's own `gsea-proteomics` observation — that high effort substitutes for a question that would otherwise be asked of a user — is what reconciles them. The variable neither author isolates is *supervision*, and it appears to be the one that actually decides. **Tone of voice.** Plain, curious, first-person, unpromotional. The register is an engineer reporting what he tried, and the notable absence is advocacy — no superlatives, no claim that higher effort is better, and a documented preference for the cheapest setting on one task. The one lapse toward product register is *"our best yet"* applied to the effort curves, which is a comparative claim with no comparison shown. The closing invitation to disagree is consistent with the rest. ## 🛡️ DARVO Analysis **Deny.** No denial pattern. The article faces no accusation and defends against none. The structurally opposite move is present and conspicuous: it volunteers a limitation of its own subject — that effort does not fix wrong-approach failures — without being prompted. **Attack.** No attack. No competitor, alternative technique or critic is named, characterised or disparaged. No competing model appears at all, which is a scope limitation rather than a rhetorical stance. **Reverse victim and offender.** No reversal. There is no grievance, no harm claimed, no injured party and no blame assigned in any direction. Where the model performs badly at low effort, the failures are described neutrally as behaviour — it edited before reproducing, it warned without checking — with no attribution of fault to users who choose low effort. **Assessment.** No DARVO pattern present. Retained per the template with this explanation. Worth recording the positive finding: in vendor-adjacent writing about a vendor's own feature, a genre where the standard move is to establish the feature's necessity by dramatising the alternative, this article instead documents where the feature does not help and names a task where the author prefers not to use it. ## 🎯 Conclusion **Bottom line.** Effort buys verification and a greater willingness to decide unsupervised. It does not buy a better choice of approach — and the author states that limit himself, about his own employer's parameter, which is the main reason to credit everything around it. The behavioural traces make the mechanism concrete: at high effort the model reproduces the crash before editing, tests against a reference implementation, runs a standard attack suite, writes a fuzzer. At low effort it writes something, tries one example, and occasionally warns about a risk it declines to measure. Two findings travel further than the parameter. A detailed specification collapses the difference between effort levels — so reaching for more compute on a vague task may be purchasing with tokens what a better brief supplies for nothing. And effort substitutes for a human in the loop, stated outright in the proteomics case, which explains why the author's own routine looks inverted: cheap while he is watching, expensive when he is not. The variable that actually decides is supervision, and naming it also reconciles this piece with the practitioner account in this corpus that recommends the opposite default. What the document cannot establish: anything cross-vendor, anything about frequency (the illustrative cases were chosen because effort helped there, as the author says), and anything about cost — a recommendation framework for a compute-spending parameter that contains no compute figure and no stopping rule, while documenting one task that runs from 2 minutes to 33. **Next steps.** Take the edge-case-versus-wrong-approach distinction as the durable finding and file it against the Goedecke note already in the corpus, which reaches the same place from the practitioner side. Apply effort at verification rather than generation. And before raising effort on a disappointing result, check whether the task was specified — that is the cheaper of the two available purchases, and the article's own third experiment is the evidence for it. ## 🔄 Refactor Appendix ### 📚 Literature Atoms #### [H1] Effort fixes missed edge cases, not wrong approaches > [!quote] > 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). **Context & use** - The article's most valuable claim, and it limits the author's own subject. - Thoroughness within a chosen approach is purchasable; the choice of approach is not. - Implies two distinct remedies: compute for the first class, review and framing for the second. A policy that treats "turn it up" as the general answer will fail on the second while spending more. - Stated as a described trend in a diagram unavailable in this capture; the prose is the only surviving record of it here. **Tags:** #effort-levels #failure-taxonomy #agent-limits <!-- atomicity: 1 idea ✓ --> #### [H2] Effort adds verification behaviour, not intelligence > [!quote] > 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. **Context & use** - The mechanism made concrete: what appears at high effort is a testing programme, not a cleverer one-pass answer. - Against low effort on the same task — about two minutes, one pass, one hand-written test page. - These behaviours are specifiable as requirements independent of any parameter, which is the transferable form for security and review work. - `html-js-filter`, Fable 5.1, 1/5 at low to 5/5 at xhigh. n=5. **Tags:** #verification #security-review #agent-behaviour <!-- atomicity: 1 idea ✓ --> #### [H3] A detailed spec collapses the effort difference > [!quote] > 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. **Context & use** - The third experiment, and the least emphasised finding with the widest implication. - Corollary the article does not draw: reaching for more effort on an underspecified task buys with compute what a better brief supplies for free. - The spec was produced by having the model interview him first — the elicitation is part of the method, not a preliminary to it. - Directly applicable to issue templates and ticket quality: a well-specified request narrows the gap between a cheap and an expensive attempt at it. **Tags:** #specification-quality #prompt-design #effort-levels <!-- atomicity: 1 idea ✓ --> #### [H4] High effort substitutes for a user in the loop > [!quote] > 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. **Context & use** - Reframes the parameter: partly a proxy for supervision, so its value depends on whether supervision is available. - Explains why the author's own routine inverts the naive instinct — low effort while watching, high effort when away. - Also the variable that reconciles this article with the practitioner account in this corpus recommending high effort by default: different supervision conditions, not disagreement. - Suggests a cost comparison nobody has made: how much compute equals one clarifying question. **Tags:** #supervision #human-in-the-loop #agent-autonomy <!-- atomicity: 1 idea ✓ --> #### [H5] Low effort states risks it declines to measure > [!quote] > 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. **Context & use** - The sharpest small observation in the article: the model identified its own risk and did not act on it. - A precise picture of what low effort withholds — not awareness, but follow-through. - Practical rule for reviewing agent output at any effort level: treat every caveat in the output as an untested claim. - `cli-2ph-simple`, Opus 5.5, 0/5 at low to 5/5 at high. **Tags:** #agent-review #hedging #verification <!-- atomicity: 1 idea ✓ --> ### 🧠 Permanent Candidates #### [P1] compute-buys-thoroughness-within-a-frame-never-a-better-frame **Claim.** Increasing a system's reasoning or verification budget improves performance inside the approach it has already selected and leaves errors of approach substantially untouched. Framing errors therefore require a different intervention — review, clarification, or better specification — and no amount of additional compute is the remedy for them. **Evidence pointer.** [H1] — across the benchmark, effort reduces missed-edge-case failures while wrong-approach failures persist. Corroborated by [H2]'s mechanism: what appears at high effort is a testing programme, which can only test the approach taken. **Scope & conditions.** Applies to any system with a tunable verification or reasoning budget. Strongest where the approach is selected early and cheaply. Weakens where the budget explicitly funds exploration of *alternative* approaches rather than deeper verification of one — the `gsea-proteomics` case, where high effort tried two data preparations, is the partial exception, and it is notable that the author describes that as the model doing what a user would have been asked. **Links.** - Converges with [P1] the-fix-for-a-permanent-newcomer-is-a-legible-environment from the Goedecke analysis in this corpus, and the convergence is the strongest thing in either note. Goedecke, watching agents fail in practice: models rarely make code mistakes and routinely make *design* mistakes, because they lack accumulated environment context. Thariq, counting failures on a benchmark: effort fixes edge cases and not wrong approaches. Two independent methods, one vendor-internal and one practitioner-external, arriving at the same residual category. Neither cites the other. - The joint implication neither states: since the residual category is framing, and framing errors come from missing context, the remedy for both is *legible context and human review* rather than a better model or a bigger budget. That is the argument for the continuous-learning work, arrived at twice. - Connects to [P1] a-saving-measured-where-you-were-looking-is-not-a-saving from the DocsBot analysis: both concern an intervention whose benefit lands in one place while the thing you care about sits in another. #### [P2] specification-and-compute-are-substitutes-and-specification-is-cheaper **Claim.** For a bounded class of tasks, a detailed specification and a large compute budget purchase the same improvement, and the specification purchases it at lower cost. A team reaching for more compute to fix disappointing output should first check whether the request was underspecified, because that is the cheaper of two routes to the same place. **Evidence pointer.** [H3] — given a detailed spec, models at different effort levels produced similar designs and similar implementations. Against the underspecified case, where effort changed the output substantially and, in the author's reading, changed how many choices the model made unasked. **Scope & conditions.** Holds where the task's difficulty is largely in knowing what is wanted. Breaks down where difficulty is intrinsic — the benchmark's hardware and formal-proof tasks are not rescued by clearer requirements. The diagnostic: if the failure is "it built the wrong thing," specification is the lever; if it is "it built the right thing badly," compute may be. **Links.** - Connects to [H4] and to the supervision variable: specification, clarifying questions and high effort are three ways to supply the same missing information, and they differ mainly in who pays and when. - Connects to the enforcement-over-instruction thread in the knowledge-system audit. "Specify better" is an instruction and will decay; an issue template with required fields is a mechanism and will not. The finding argues for template work with a measurable payoff rather than for exhortation. - Practical corollary for the deep-read pipeline itself: its queue contract is an extremely detailed specification, and this finding predicts that is why it produces consistent output without needing a large budget per document. Worth noticing that the system already embodies the principle. ### ✏️ Fleeting Queue - The Goedecke convergence is the most valuable thing in this batch and deserves a standalone permanent note independent of either source: two methods, one vendor-internal and one practitioner-external, both landing on framing errors as the residual category. - The base rate is the missing number. Across all Terminal-Bench tasks, how often does effort change the outcome? The author has it; publishing it would reframe his own examples. - Nobody has priced a clarifying question against a high-effort run. "How much compute equals one question to a human" is a real and answerable question. - The supervision variable reconciles this with the Theo video in the corpus. Neither author isolates it, and it appears to be the one that decides. - "Treat every caveat in agent output as an untested claim" is a one-line review rule worth keeping, from [H5]. - The deep-read contract is itself a worked example of [P2] — heavy specification producing consistency without heavy budget. Uncomfortable and probably correct. - Seven diagrams, no alt text, and the best finding encoded as purple versus blue blocks. The prose rescue looks incidental. ### → Things 3 - [ ] Write the standalone permanent note on framing errors as the residual category — Goedecke (practitioner, design-vs-code errors) and Thariq (vendor, wrong-approach vs edge-case failures) reach it independently, and the joint implication is the argument for legible context over bigger budgets. - [ ] Before raising effort on any disappointing agent result, check whether the task was specified — and if issue templates are ever revisited, cite the spec-convergence finding as the measurable payoff. <!-- deep-read:sections end --> 📄 **Full text:** [[Full Document Contents/Tweets/Using Claude Code Spending Your Effort.md|Using Claude Code: Spending Your Effort by Thariq]] ## Highlights - One of the best parts of our newest Claude models is how they respond to effort without breaking the prompt cache in Claude Code ([View Highlight](https://read.readwise.io/read/01m3d9fk7ekx1m2swyhaf3qfk0)) - Note: The disclosed vendor position, in the opening sentence: "our newest Claude models." Fallacy (single-vendor generalisation): the framing ("what is effort", "why do we need effort at all") reads as a general account of a technique while the evidence supports a claim about two specific models from one vendor, evaluated by that vendor's employee. Whether the edge-case/approach split is a property of reasoning budgets or of this implementation is unanswerable from here. Not concealment — it's the first sentence. Fix: scope the conclusions to the models tested, or add a competitor. - Tags: fallacy/single-vendor-generalization - I found that given this spec, the models behaved much more similarly. ([View Highlight](https://read.readwise.io/read/01m3d9fgbmr527bjwb1940m5c7)) - Note: H3 — The least emphasised finding with the widest implication: specification collapses the effort difference. Corollary the article doesn't draw — reaching for more effort on an underspecified task buys with compute what a better brief supplies for free. Note the spec was produced by having the model interview him first; the elicitation is part of the method. Directly applicable to issue-template quality, with a measurable payoff. - Tags: atom/literature/h3, action/h2 - 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. ([View Highlight](https://read.readwise.io/read/01m3d9ffmwjbps64evdwjdwjqg)) - Note: H2 — The mechanism made concrete: what appears at high effort is a testing programme, not a cleverer one-pass answer. Against ~2 minutes and a single hand-written test page at low effort. These behaviours are specifiable as requirements independent of any parameter, which is the transferable form for agent-assisted security and review work. html-js-filter, Fable 5.1, 1/5 low → 5/5 xhigh (n=5). - Tags: action/h1, atom/literature/h2 - 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). ([View Highlight](https://read.readwise.io/read/01m3d9ff0b4acbacqy4t5c6dtx)) - Note: H1 / Z1 — The article's most valuable claim, and it limits the author's own subject: thoroughness within a chosen approach is purchasable, the choice of approach is not. Implies two distinct remedies — compute for missed edge cases, review and framing for wrong approaches. Converges exactly with Goedecke's practitioner finding in this corpus (models make design mistakes, not code mistakes). Two independent methods, one vendor-internal and one external, landing on framing errors as the residual category. - Tags: atom/literature/h1, atom/zettel/z1 - 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 ([View Highlight](https://read.readwise.io/read/01m3d9fjgx8aavm6pwc0d461hs)) - Note: Fallacy (selection on the dependent variable) — the illustrative cases are chosen precisely because the effect being demonstrated occurred in them. They show a mechanism; they cannot support any claim about how often effort changes an outcome, and a skimming reader will take three 0/5→4/5 transitions as representative. Venial because the criterion is stated plainly in this very sentence. Fix: report the base rate across all tasks — he has the data, and one sentence would turn illustration into finding. - Tags: fallacy/selection-on-dependent-variable - In the final message, Claude warned it might be slow on big problems, but did not check. ([View Highlight](https://read.readwise.io/read/01m3d9fhtjzj46mz7yxz25em1r)) - Note: H5 — The sharpest small observation here: the model identified its own risk and did not act on it. A precise picture of what low effort withholds — not awareness, but follow-through. Practical review rule at any effort level: treat every caveat in agent output as an untested claim. cli-2ph-simple, Opus 5.5, 0/5 low → 5/5 high. - Tags: atom/fleeting/f1, atom/literature/h5 - 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. ([View Highlight](https://read.readwise.io/read/01m3d9fh2r1g6b8d6af7d6rcda)) - Note: H4 — Reframes the whole parameter: effort is partly a proxy for supervision, so its value depends on whether supervision is available. Explains why the author's own routine looks inverted — low effort while watching, high effort when away. Also the variable that reconciles this with the Theo video in the corpus, which recommends high by default: different supervision conditions, not disagreement. Nobody has priced a clarifying question against a high-effort run. - Tags: atom/literature/h4, atom/zettel/z1