Effort is the cost lever nobody tunes

The setting almost everyone leaves untouched

Ask a team what they've tuned to control their Claude spend and you'll hear about model choice first, prompt length second, and maybe caching if they're further along. Effort level rarely comes up unprompted, even though it's frequently the single largest lever on both cost and quality for any workload that involves real reasoning. It gets left at whatever the model defaults to almost by default, and that default, on several current models, sits at a genuinely capable but genuinely non-trivial cost point — not the cheapest option available, and not obviously the wrong one either, which is exactly why it survives unquestioned.

Why this lever gets ignored while others get scrutinised

Model choice is a decision made once, deliberately, usually with some comparison behind it — it feels like a real decision because it's made explicitly and rarely. Effort level, by contrast, is often set implicitly, by omission, and revisited even less often than the model choice it sits alongside. A setting that's invisible by default doesn't get the scrutiny a visible one does, even when it moves the bill by more.

Why "just lower it and see" is worse advice here than it sounds

For most cost settings, testing a cheaper option is close to free — if quality drops, you notice and revert. Effort level breaks that pattern, because a quietly under-provisioned setting doesn't produce a visibly worse answer most of the time; it produces an answer that reads as complete and is occasionally, silently, wrong on exactly the cases that needed the reasoning depth it didn't get. "Try it and see if quality holds" doesn't work as a test here the way it works for almost every other lever, because the failure isn't the kind of thing casual observation reliably catches.

What actually makes this safe to tune, then

The way out isn't caution — it's a real evaluation set, checked before and after, on the specific category of task a lower tier is being considered for. A blanket "try it in production and watch the bill" approach is exactly backwards for a setting whose failure mode doesn't show up in casual observation; the check that actually catches an under-provisioned tier is a deliberate comparison against known-good answers, not a wait-and-see rollout.

Why this compounds more in agentic workflows than in single requests

For a single API call, getting the effort level wrong costs you once. Inside an agentic session — Claude Code, or any multi-step workflow — the same setting applies across every reasoning step in that session, and an under-provisioned setting on a planning step can produce a flawed plan that then gets executed across a dozen subsequent actions before anyone notices the plan itself was the problem. The lever matters more, not less, the more steps depend on the reasoning it's controlling.

What actually changes once a team starts tuning it deliberately

Teams that move from "whatever the default is" to a deliberate, segmented effort strategy tend to find real savings on the easy majority of their workload without any quality cost, because that majority was never using the extra reasoning depth in the first place — and simultaneously find better output on their hardest cases once those get routed to a tier that was actually built for them, rather than sharing a single blended setting with everything else.

Why this lever deserves a place in regular cost review, not just initial setup

Cost reviews tend to focus on what's easy to see in a bill — total spend by model, by project — and skip past effort level because it isn't a separate line item anywhere; it's baked invisibly into every request's cost without a label calling it out. Making it an explicit part of a periodic review, not just a one-time setup decision, is what actually keeps a workload from drifting back toward an unexamined default over time, especially as new contributors add new call sites that default to whatever they copied from an existing example without necessarily querying why that setting was chosen in the first place.

See choosing effort level for cost, not just quality for the practical framework behind this, and the effort & thinking cost estimator to see the actual cost curve for your own task sizes rather than reasoning about it in the abstract.