Claude's effort dial mainly buys better verification

Cranking Claude's effort to max costs 3x the tokens without a smarter plan, per Thariq Shihipar's post on claude.dev.

That's because effort mostly buys verification. It rarely produces a smarter approach. On Terminal-Bench 3.0, Fable 5.1 used a median 73,000 tokens per attempt at low effort and 222,000 at max.

The score gains cluster in verification-heavy categories. Security accuracy went from 64% to 87%, hardware climbed to 75%, up from 34%. Tasks where the initial approach was already right barely moved.

Shihipar's suggested workflow starts with interviewing Claude against a spec, moves to implementation on low effort, and saves /effort high for verification and test writing. I've been running something close to this by accident for months without knowing why it worked. Low effort with a good spec produces code fast; high effort review catches the edge cases I miss.

The corollary is sharper. When a failure survives high effort, the spec was the problem. More thinking doesn't invent requirements nobody stated.

A companion cost breakdown from Addy Osmani puts numbers on that cache sensitivity. Opus 5.5 runs $4/$20 per million input/output tokens, with cache reads at $0.20 per million. A 40-turn task whose context balloons to 120K tokens from a 20K start resends about 2.8 million tokens total. At a 96% cache hit rate that costs $0.99; with no caching it's $11.20, an 11x swing on identical work.

Osmani's advice: /compact before a break, /clear between unrelated tasks, batch tool calls, and raise effort before switching to a bigger model. The same cache lesson shows up in research. The CAR-bench Track 2 winner served 78% of input tokens from cache using a byte-identical static prompt with per-task state appended at the end, versus 73% during development when prompt edits kept resetting it. Freezing the prefix and appending volatile state last is a five-minute change for most harnesses.