Slash AI Costs: Cut Token Usage by 45% with This Simple Claude Code Tweak

By 3pm on a Tuesday I'd burned through a week of Claude Code allowance and had half a feature to show for it. That's the moment you start reading docs for fun. The fix turned out to be a single slider Anthropic quietly shipped — Claude Code's effort setting — and it dropped my token burn by 45%. The interesting part isn't the number. It's that a knob this useful sat there with nobody telling me.

Why Claude Code burns tokens before it answers

When you ask an LLM a question, it doesn't 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're subsidising thinking you don't 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. 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.

That number is one developer's workload, not a benchmark — treat it as 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 didn't change the answer, not to the answer itself.

The honest caveat: the version of the article I read cuts off mid-sentence before walking through the exact UI path or config key. So I can tell you what the setting does, but I'm not going to print a config snippet I'm not sure is right. Open Claude Code, find the reasoning or effort control in settings, and check the current value before changing it. If you're on the CLI, scan claude --help for any flag touching reasoning or effort — the names in this space move fast.

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

If you maintain a project-level config, that's 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.

Picking the right effort for the right job

The slider isn't "always set it low". It's "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% number 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 isn't 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's often a wash — sometimes a win. Cache aggressively.

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 isn't "can Claude do it" — it's "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're 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 don't depend on whatever Anthropic renames the knob next quarter.

What stays the same when the tool changes

Here's 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 doesn't change is the cost of getting an answer wrong, which is paid in your time and your user's experience.

That's 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.

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.