Medium effort: one report measured 45% fewer output tokens

One practitioner ran five real coding tasks at effort high then medium: ~26,000 vs ~14,300 output tokens, a ~45% cut, all five completed with no quality drop visible by eye. The docs confirm the mechanism (thinking bills as output) but publish no measurement.

You have already trimmed your CLAUDE.md, stopped pasting whole files, and started /clear-ing between tasks — and your token burn barely moved. The lever you have not touched is probably the effort level, which on most models sits at high by default and never announces itself as a cost decision.

The mechanism is documented. Extended thinking is on by default, thinking tokens bill as output tokens, and output is the expensive side of the bill. The costs page says the default thinking budget "can be tens of thousands of tokens per request depending on the model," and names lowering effort with /effort as a way to cut that. The model-config page describes medium as the level that "reduces token usage for cost-sensitive work that can trade off some intelligence."

What the docs do not publish is a number. That is where this tip comes from, and where the honesty has to start.

The claim, and exactly whose claim it is

One practitioner ran five real coding tasks at high and again at medium, on one codebase, and reported roughly 26,000 output tokens versus roughly 14,300 — about a 45% cut. All five tasks completed. Per-task reductions ranged from about 25% on a small bug fix to about 54% on a refactor. On the two open-ended tasks — finding a performance problem, and choosing a refactor target — both levels independently landed on the same answer.

That is n=5, one author, one repo, one run each, with quality judged by eye. It is a data point, not a benchmark.

Level	What the docs say about it	What this report adds
`low`	For short, scoped, latency-sensitive work that is not intelligence-sensitive	Not tested
`medium`	Reduces token usage, trading off some intelligence	~45% fewer output tokens across five tasks; no visible quality loss
`high`	Balances tokens and intelligence; the default on every model except Opus 4.7	The baseline it was measured against
`xhigh`	Deeper reasoning, higher spend; the default on Opus 4.7	Not tested
`max`	May show diminishing returns, prone to overthinking; test before adopting broadly	Not tested

What is unverified, and what would settle it

Take the mechanism as documented and the 45% as an order of magnitude:

Single run, no repetition. Agent trajectories vary run to run. A 45% delta from one run each could be substantially noise; nobody has reported a variance figure.
No model named. The docs state plainly that "the effort scale is calibrated per model, so the same level name does not represent the same underlying value across models." A high-to-medium ratio measured on one model does not transfer to another.
Quality was eyeballed. "No visible quality drop" on five bounded tasks is not the same as no drop. The author still reserves high for hard debugging and architecture decisions — the exact cases the sample excludes.
Bounded tasks only. A long, exploratory session at low effort can burn more total tokens by taking more turns to converge. Fewer tokens per request is not the same as fewer tokens per task.

To move this from plausible to measured, run the same prompt on the same repo at both levels, several times each, and read the reported cost rather than guessing:

bash

bash -c 'for lvl in high medium; do
  claude --effort "$lvl" -p "summarize the architecture of this repo" \
    --output-format json | jq "{lvl: \"'"'"'$lvl'"'"'\", cost: .total_cost_usd}"
done'

Write that to a file and run it with bash, rather than pasting the loop — your interactive shell is zsh, which will not word-split it the way you expect.

The habit that is not in dispute

Whatever the true ratio, the operational advice here is documented rather than inferred. The prompt-caching page's own tip: pick your model and effort level at the top of a session, and save /compact for natural breaks. The reason is concrete — on most models each effort level has its own cache, so changing effort mid-session recomputes the entire request with no cache hits. Claude Code asks you to confirm while the cache is still warm. Fable 5.1 on an API key or Claude subscription is the exception — effort changes there keep the cache, and Claude Code applies the new level without asking. That exception is a recent arrival rather than a standing property of the model: "Before v2.1.260, changing effort on Fable 5.1 with an API key or a Claude subscription also invalidated the cache." It also does not apply on Amazon Bedrock, Google Cloud's Agent Platform, or a Claude apps gateway — so it is a property of one model on one set of billing routes, not a general relaxation of the rule.

So the cost of experimenting is real but one-time and front-loaded. Set it at launch:

bash

claude --effort medium

In an interactive session on your own machine, /effort medium also saves per model and applies in later sessions. /effort auto clears the saved level for the active model.

Cheaper than a global downgrade

If you do not want one blunt session-wide setting, effort is settable at finer grain. Subagent and skill frontmatter accept an effort field, which overrides the session level while that subagent or skill is running — so a noisy, mechanical subagent can sit at medium while your main thread stays at high. And ultrathink anywhere in a prompt requests deeper reasoning for that turn as an in-context instruction, without changing the API effort level or touching your cache.

That combination is arguably the better read of the report: not "drop everything to medium," but "stop leaving one global high in place for work that does not need it."

Checkpoint

Why does lowering effort change your bill more than trimming the files you paste in?

Show answerAnswer
Because extended thinking is on by default and thinking tokens bill as output tokens, which is the expensive side of the bill. The costs page says the default thinking budget can be tens of thousands of tokens per request depending on the model, and names lowering effort with /effort as the way to cut it. Trimming what you paste in never touches that line item.
You are 40 messages into a session at high and want to save money. What does switching to medium right now actually cost you?

Show answerAnswer
On most models, the whole prompt cache. Each effort level has its own cache, so the change recomputes the entire request with no cache hits and you pay to re-read all 40 messages — the opposite of the saving you were chasing, which is why Claude Code asks you to confirm while the cache is still warm.
Finish this session at high and start the next one at medium: claude --effort medium at launch, or /effort medium, which on your own machine also saves per model for later sessions. The exception is Fable 5.1 on an API key or Claude subscription, where the cache survives and the level is applied without asking — not on Bedrock, Google Cloud's Agent Platform or a Claude apps gateway, and not before v2.1.260.
Why can a 45% figure measured on one model not be quoted for a different one?

Show answerAnswer
Because the docs say the effort scale is calibrated per model — the same level name does not stand for the same underlying value across models — so a high-to-medium ratio measured on one tells you nothing about another. This report does not even name the model it ran on.
Carry the rest of its shape with the number whenever you repeat it: n=5, one author, one repo, one run per level, quality judged by eye. It is an order of magnitude, not a constant.