Claude Code's Effort Levels: A Cost-Control Playbook for GTM Engineers

What an effort level actually controls

I used to assume token spend was mostly a model question: pick a cheaper model, spend less. Then I read Anthropic's own breakdown of how effort levels work in Claude Code, published July 7, 2026, and realized I had the wrong lever in mind. Model choice picks which fixed set of weights answers you. Effort level picks how hard those weights work on this particular turn, how many files get read before Claude answers, how much it double-checks its own output, and how far it pushes through a multi-step task before stopping to ask you something. Anthropic's own post puts it plainly: effort means more than just thinking time.

That distinction matters for anyone building their own GTM tooling on Claude Code, because it means you have two independent dials, not one. You can run a cheap model at max effort, or an expensive model at low effort, and get very different cost and quality outcomes from either combination.

Why Anthropic explained this in July 2026

Anthropic did not publish this explainer for no reason. Effort level has existed as a setting for a while, but developers kept treating it as an obscure flag rather than a first-order cost decision. The trigger, as one independent writeup from MCP Directory describes it, was developers like Vincent Schmalbach posting usage logs showing weekly token burn dropping to roughly a sixth of its prior level after Opus 4.8 rolled out, with no change to per-token pricing. The explanation was not a pricing change. It was a default effort level change baked into the new model's rollout, and most developers had no idea that lever existed until their bill moved on its own.

For a solo GTM engineer or a two-person team running Claude Code against a monthly plan with usage limits, that is not a rounding error. It is the difference between hitting a weekly cap on Tuesday or Friday.

The five levels, at a glance

Effort in Claude Code is set as a named level, not a token budget you calculate yourself. Here is what each one is for.

Which models default to which level

The defaults are not uniform across the model lineup, which is exactly how teams end up surprised. Opus 4.7 is the outlier, it defaults to xhigh. Sonnet 5, Opus 4.8, Opus 4.6, and Fable 5 default to high. Older models, Opus 4.6 and Sonnet 4.6 among them, do not support xhigh at all, if you request it Claude Code silently downgrades to high instead. Anthropic's post frames Opus 4.8 as generating better results for roughly the same token count as Opus 4.7 was using at its default, which is a real efficiency gain, but it is easy to miss if you are not reading model release notes closely alongside your own usage graphs.

The practical takeaway: when you switch models inside a GTM tooling project, check what effort level came along with the switch. You may have just changed two variables while thinking you changed one.

The number that matters: roughly 7x

Anthropic's explainer includes one concrete data point worth remembering over everything else in the post: run the identical prompt at two effort levels, and the high effort path generates roughly 7x more tokens than the lower one to reach a higher confidence answer. Anthropic is careful to say its illustrative curves are not benchmark data, but that specific multiplier is stated directly, not illustrated.

Put that next to how most GTM tooling actually gets built. A waterfall enrichment script, a CRM hygiene pass, a reporting pipeline, these are exactly the long, multi-step, multi-file jobs where Claude Code is most likely to sit at xhigh or max by default, because that is what the task shape calls for. A 7x multiplier applied to the kind of session length a real pipeline build takes is not a rounding error on a monthly plan with a fixed usage cap.

Effort and model choice are two separate levers

It is worth saying this twice because it is the part people conflate. Model choice is about capability and knowledge, which weights answer you. Effort level is about thoroughness, how hard those weights work on this specific turn before stopping. A cheaper model at max effort can burn more tokens on a simple task than a stronger model at low effort spends on the same task. Neither lever alone tells you your cost, only the combination does.

This is also why "just use a cheaper model to save money" is incomplete advice for anyone building GTM tools on Claude Code. If the effort level defaults to xhigh regardless of which model you picked, the model swap may barely move your bill. Check both settings, not just one.

Where GTM engineers overspend without noticing

In my own experience wiring Claude Code into enrichment scripts and CRM cleanup jobs, the overspend rarely comes from one obviously wasteful session. It comes from three quiet patterns.

First, a long-horizon task, like a multi-file waterfall pipeline, runs at its natural xhigh default for the entire session even after the hard part is done and what remains is boilerplate. Second, a model upgrade silently drags a higher default effort level along with it, and nobody checks. Third, exploratory sessions, poking at an API, testing a CRM field mapping, run at the same effort level as the final production build, when they would work fine at low or medium.

None of these are dramatic. All three compound across a month of daily building, which is exactly the shape of the "credits and usage limits" complaint that keeps showing up as the top pain point in GTM teams' own surveys about Claude Code, ahead of accuracy.

The playbook: setting effort per task

Here is the sequence I actually run through before starting a new build session.

1. Name the task shape first. Is this a quick lookup, a routine edit, or a long multi-step build? Decide before you open the session, not after you notice the token count.
2. Check the model's default effort level. If you are on Opus 4.7, assume xhigh unless you set otherwise. On Sonnet 5, Opus 4.8, or Fable 5, assume high.
3. Drop to low or medium for exploration. Field mapping checks, API pokes, one-off questions about existing code, none of these need full capability.
4. Reserve xhigh and max for what actually needs it. Long-horizon pipeline builds, anything where a wrong answer costs you more than the extra tokens would, that is where the higher levels earn their spend.
5. Re-check effort after every model switch. Treat it as part of the same decision, not an afterthought.
6. Track weekly usage against the cap on your actual plan. If you are hitting the limit on the same day every week, effort level is the first thing to audit, before you consider upgrading plans.

A quick reference for matching task to level

Why this matters more than the model debate

GTM teams keep telling surveyors that usage limits, not accuracy, are their top complaint with Claude Code and Cowork. Most of the public conversation about controlling that cost focuses on plan tier or model choice. Effort level gets almost none of that attention, despite being the setting Anthropic itself says can swing token usage 7x on an identical prompt. If your team is debating which plan to upgrade to, that is worth doing after you have first confirmed your sessions are not defaulting to more thoroughness than the task actually needs.

My take: how I actually set it

I leave effort on the model default for the bulk of my own building, because Anthropic's guidance to treat it as a general preference rather than a per-task decision is right most of the time. Where I deviate is at the two ends: I drop to low for anything exploratory, checking a field name, testing whether an API returns what I expect, and I let xhigh or max run uninterrupted on the handful of long pipeline builds a month where getting the enrichment logic right matters more than the token count. I do not spend time hand-tuning effort on routine edits. The 7x number is the reason I bother tuning it at all rather than ignoring the setting the way I did before Anthropic's post made the tradeoff explicit.

FAQ