Slash AI costs: cut token usage by 45% with this simple Claude Code tweak

By 3pm on a Tuesday I had burned through a week of Claude Code allowance and had half a feature to show for it. That is the moment you start reading docs for fun. The fix turned out to be a single control Anthropic shipped — Claude Code's effort setting — and one author's measurement put the saving at 45%, as reported by XDA Developers. The interesting part is not the number. It is that a knob this useful sat there with nobody telling you.

Why Claude Code burns tokens before it answers

When you ask an LLM a question, it does not instantly spit out an answer. The model works through the problem internally before producing the response you actually see. The more complex the task, the more reasoning it needs, and reasoning is paid for in tokens. The XDA report frames it bluntly: extra thinking means more tokens consumed along the way, which means more waiting and more of your usage allowance burned in the background.

That tradeoff is real. For genuinely hard problems — multi-file refactors, deep debugging, unfamiliar frameworks — you want the model thinking hard. But for routine work — formatting a file, writing a unit test, generating a docstring — paying for a long internal monologue is a waste. You are subsidising thinking you do not need.

Claude Code's newer models layer in what Anthropic calls adaptive reasoning, which lets the model decide whether a particular step needs deeper reasoning and how much is actually worthwhile — confirmed in the XDA piece and documented in the official Claude Code docs. In theory that means routine steps fly past and hard problems get the extra attention. In practice, the model's default is still "think more, just in case", which is where the bill comes from.

The one setting: Claude Code's effort level

The main lever you have is Claude Code's effort setting. Each effort level trades token usage against capability. Lowering it encourages Claude to be more economical with its reasoning. Raising it gives the model more room to think before it answers. The XDA piece credits this single change with a 45% drop in token burn — read that as one author's workload measurement, not a benchmark or a promise.

That number is directional, not gospel. But the shape is consistent with how token costs actually work: most of the budget on a routine task goes to internal reasoning that did not change the answer, not to the answer itself.

The honest caveat: the effort control's exact location and config key move between releases. Open Claude Code, find the reasoning or effort control in settings, and check the current value before changing it — the official docs are the authority on the current UI path, not a third-party screenshot. If you are on the CLI, scan claude --help for any flag touching reasoning or effort:

# Sanity-check what your client exposes
claude --help | grep -iE "effort|reasoning|think"

If you maintain a project-level config, that is the file the effort value lives in alongside your model and permission settings. Verify the exact key against the current docs before shipping it to a team. Standing instructions like these belong in version-controlled rules — our Cursor rules for Next.js checklist is a good template for keeping agent config reviewable.

Picking the right effort for the right job

The slider is not "always set it low". It is "set it to the cheapest level that still gets the job done". A rough rubric — treat the levels as a band rather than a fixed list of names:

• Bottom of the band — formatting, renaming, single-file edits, docstrings, repeat boilerplate. Anywhere the answer is mostly mechanical and you can spot a wrong one in seconds.
• Middle of the band — most debugging, most feature work on familiar code, anything where Claude needs to read a few files but not architect a system.
• Top of the band — cross-file refactors, brand-new modules, unfamiliar libraries, design decisions with multiple valid answers. The places where wrong thinking costs you an hour of cleanup.

The mistake is leaving it pinned at the top for everything. Most sessions are a mix. Drop to the bottom for the boring passes, kick back up for the hard one, drop again. The 45% figure in the XDA piece came from treating it as a per-task dial, not a global default.

Other places tokens quietly leak

The effort slider is the biggest win, but it is not the only one. A few other places tokens go to die:

Repeated tool calls. Every grep, every file read, every bash invocation burns input tokens on the way in and output tokens on the way out. If you can paste a file's contents into the prompt instead of asking Claude to re-read it, that is often a wash — sometimes a win. Cache aggressively. For agents running unattended, the discipline in our AI production background jobs guide applies: supervise the loop, bound the retries.

Re-asking the same thing. "Now do it again but with X" is two prompts where one would do. Bundling constraints into a single clear prompt saves a round trip and the model gets to think once, not twice.

// Bad: two turns, two reasoning passes
// turn 1: "rename foo.ts to bar.ts"
// turn 2: "now also update the imports"

// Better: one turn, one pass
// "rename foo.ts to bar.ts and update every import that references it"

Asking Claude to do work you already know how to do. Renaming 30 files by hand is five minutes. Asking Claude to rename 30 files is a prompt that costs more than five minutes of your time. The bar is not "can Claude do it" — it is "is the model cheaper than me here".

Long system prompts you never audit. Every turn starts with your full system prompt and CLAUDE.md. If those files have grown to thousands of words of legacy context, you are paying for that on every message. Trim aggressively.

None of these are as big as the effort setting. But on a heavy day, they compound — and they do not depend on whatever Anthropic renames the knob next quarter. Our ship AI MVP to production checklist covers the broader cost-and-risk review this belongs in.

What stays the same when the tool changes

Here is the part worth keeping after the Claude Code news cycle moves on. Tools change — last month's model is this month's discount, today's reasoning knob is tomorrow's deprecated setting. The thing that does not change is the cost of getting an answer wrong, which is paid in your time and your user's experience.

That is the layer OTF sits at. While you optimise tokens in whatever the current agent happens to be, the durable work is shipping a product where the same component renders the same on web, iOS, and Android — one API, one source of truth, no "wait, why does this look different on Android" bug at 11pm. Token efficiency decides how fast you iterate. The kit decides what survives the iteration. Start from OTF templates and keep the product layer boring while the model layer churns.

The 45% saving is great. Use it. Build faster. And when the next model lands and the next setting lands and the next "one trick" lands, the cross-platform UI you shipped last quarter still works on the device your user pulls out of their pocket tomorrow.

Sources

• XDA Developers — I changed one setting in Claude Code, and my token burn dropped by 45% (Aug 8, 2026) — effort-setting claim, 45% single-author measurement, adaptive-reasoning description. All figures attributed as one author's workload, not a general promise.
• Claude Code docs — official product baseline; confirm the current effort/reasoning control location and config key here before changing settings.