Reduce Claude Code token usage: 10 ways

Updated October 2026: model names and the thinking-budget guidance have moved on since this first went live. Opus 5.5, Sonnet 5.5 and Haiku 5.5 are the current lineup, and the model selection guide has the full routing table; /effort (levels low through max) is now the canonical way to control thinking, and current adaptive-reasoning models ignore the old MAX_THINKING_TOKENS flag. I’ve also folded in a few newer levers worth knowing: /fast for a faster Opus, and /rewind checkpoints for undoing a bad turn without burning a fresh session.

TLDR; Most Claude Code token waste comes from context bloat and habit, not the prompts themselves. The biggest levers: clear context between tasks, keep CLAUDE.md lean (~100 lines), route models deliberately, delegate exploration to cheap sub-agents, and cap thinking with /effort. Track spend so you know which pattern to fix first.

I’ve been running Claude Code heavily across multiple client projects for over a year. The costs are real. The patterns that drive token usage are predictable once you know what to look for. Most of the waste doesn’t come from the prompts themselves; it comes from context bloat, model choices, and a few easy-to-fix habits.

These are the ten techniques that have made the biggest difference. I use all of them.

The biggest wins, in order:

Clear context between tasks (/clear)
Keep CLAUDE.md lean (I target about 100 lines; Anthropic recommends roughly 200 or fewer)
Route models deliberately
Use sub-agents for file exploration
Cap thinking with /effort (levels low through max)
Track usage with ccusage daily --breakdown and Claude Code’s /usage view

1. Route models by task, not by habit

The default is to reach for whatever model you last used. That’s expensive. What works better is matching the model to the task.

On metered billing, use Sonnet 5.5 as your default for most work: code generation, refactoring, standard features. (/model switches instantly; the sonnet alias resolves to Sonnet 5.5 and opus to Opus 5.5.) Escalate to Opus 5.5 for complex architecture, intricate debugging across multiple systems, and reviews. For search and extraction sub-agents, running a grep, finding call sites, summarising a file, specify model: haiku explicitly. Haiku 5.5 matched Sonnet 5.5 on every code-search run I tested, at a twentieth of the price.

A pattern that works well: the opusplan alias, which uses Opus during plan mode for the architecture thinking and switches to Sonnet for execution. You get the reasoning quality where it counts without paying Opus rates for code Sonnet writes just as well. The catch: each model has its own cache, so every plan-mode toggle under opusplan is a model switch and the next request reads the whole conversation uncached. Use it for sessions with one planning phase, not for flipping in and out of plan mode. One note on my own setup: I’m on a Max 20x plan, where the per-token gap does not appear as a separate line item. Heavier models and higher effort still consume a limited allowance faster, so defaulting to Opus is a capacity trade-off rather than free usage. If you’re paying per token or regularly hitting plan limits, the Sonnet-default routing above is still the more economical habit. The model selection guide sets out both setups, with the evidence behind each row.

2. Manage the Claude Code context window

The single biggest hidden cost in most Claude Code setups is context bloat. Every message you send carries the weight of everything that came before it, and the weight compounds quickly.

Run /clear between unrelated tasks. This isn’t being precious about clean sessions; it’s treating context as a resource that needs managing. When you finish a feature and pivot to a bug in a different part of the codebase, you don’t need the history from the first task polluting the second. Clear it.

The newer /btw command is useful for the in-between case: you want to ask a side question without it entering the main conversation history. Lower-stakes than /clear, useful constantly.

Boris Cherny, who built Claude Code, has described running about five local sessions, each in its own git checkout, plus more on the web, one session per task, each with a lean context window. (The official best-practices docs recommend the same worktree pattern.) More overhead to set up but produces better output and lower cost per session than one sprawling session trying to hold everything.

3. Compact before you hit the limit

Claude’s performance degrades as the context window fills. The /compact command summarises the conversation while preserving the essential information. The right move when you’re mid-task and can’t start fresh.

I start considering it around 70% context capacity, based on my own sessions, before I am forced into the default compaction boundary. That is an operating threshold, not a documented quality cliff. Give it a focus: /compact Focus on the API changes we've made so far tells Claude what to preserve and what to summarise away. Compaction is still lossy, so verify the important decisions afterward.

4. Keep your CLAUDE.md lean

CLAUDE.md is loaded at the start of every session. Whatever’s in it costs tokens every time. An 800-line CLAUDE.md with extensive documentation, detailed examples, and long prose explanations is paying a token tax before you’ve typed a word.

The Claude Code team’s checked-in CLAUDE.md is about 2,500 tokens, Cherny has said. The official docs now recommend keeping CLAUDE.md under 200 lines. Strict workflow rules, things Claude should never do, the conventions that matter most. Everything else lives in a separate file loaded only when relevant.

For specialised knowledge, client-specific context, domain rules, edge case handling, move it into on-demand skills or sub-agent instructions. Loading domain knowledge only when you need it keeps the always-loaded portion of your context small; on my own setup, moving client context out of CLAUDE.md and into skills cut thousands of tokens from every session that didn’t touch that client. The difference adds up across hundreds of sessions.

Claude Code now also writes its own auto-memory at ~/.claude/projects/<project>/memory/MEMORY.md based on corrections and patterns it picks up during sessions. That’s separate from CLAUDE.md (which you maintain) and it scopes per project. You don’t need to do anything to enable it; just be aware it’s there.

5. Delegate exploration to sub-agents

When a task requires reading many files to orient itself, understanding a codebase area, reviewing a set of logs, surveying test coverage, I don’t do that exploration in my main session. I spin up a sub-agent.

Sub-agents run in their own context window. They can read hundreds of files, do the investigation, and return a focused summary to your main conversation. The summary comes back at around 1,000–2,000 tokens. The alternative, doing the same exploration in your main session, loads all that file content directly into your primary context, where it stays.

The sub-agent result is what you needed. The sub-agent context is discarded when it’s done.

6. Preprocess data before it reaches Claude

Underused. If you’re passing logs, CSVs, or raw API responses to Claude, you’re probably sending more tokens than necessary.

I write a short shell hook to filter the data first. Instead of a 10,000-line log file, run it through grep -E "(ERROR|WARN)" before passing it to Claude. Instead of a full database export, pre-filter to the rows that are relevant. The pre-processing is trivial; the token savings are not.

This works particularly well with hooks that run before Claude sees generated logs or machine-readable exports: remove irrelevant fields, normalise repeated noise, and extract the relevant sections. Do not strip source-code comments by default; comments can contain constraints and design intent the model needs. Preserve the original artifact for audit and debugging.

7. Use CLI tools instead of MCP servers where you can

MCP servers are capable, but they carry overhead. When an MCP server is active, its tool listing is injected into every prompt, that’s persistent token cost for the entire session, whether you’re using the tool or not. (Tool Search lazy-loading, on by default in current Claude Code, has reduced this significantly, but the cost isn’t zero.)

For many common tasks, CLI tools are leaner. gh for GitHub operations, aws for AWS, psql for database queries, these produce exactly the output you ask for, with no ongoing per-prompt overhead. Anthropic’s own best-practices documentation now states that “CLI tools are the most context-efficient way to interact with external services.”

I tell Claude to prefer CLI tools over MCP connections for routine operations. Reserve MCP for the things it does better: complex multi-step workflows, tools that benefit from Claude’s contextual awareness across calls, integrations where the structured data format matters.

8. Force a plan before writing code

Extended thinking and open-ended code generation are two of the fastest ways to burn tokens on work you’ll discard. The fix: make Claude outline what it’s going to do before it does it.

Press Shift+Tab until the status bar shows ⏸ plan mode on (three presses from auto mode, the default since v2.1.283; two from Manual), or prefix the prompt with /plan, before any non-trivial implementation task. Claude produces an implementation plan first. Review it. If the approach is wrong, you’ve spent a few hundred tokens on a plan instead of thousands on code that solves the wrong problem. This discipline pays back every time Claude would otherwise have confidently generated the wrong thing.

The same principle applies to extended thinking. When you need it, it’s worth the cost. For standard implementation tasks, it often isn’t. Control thinking via /effort (levels low through max) or the CLAUDE_CODE_EFFORT_LEVEL environment variable. Current adaptive-reasoning models ignore the older MAX_THINKING_TOKENS flag; /effort is the canonical lever now.

9. Front-load the verification criteria

Correction loops are expensive. When Claude produces something that needs fixing, you explain the problem, Claude regenerates, you review again, each iteration burns context. The best way to reduce corrections is to reduce the ambiguity that causes them.

At the start of a task, provide the verification criteria:

expected output
test cases
screenshots of what the UI should look like
specific assertions the code should pass

When Claude knows how to check its own work, it catches more issues before they reach you, and the back-and-forth shortens. A thorough initial prompt is cheaper than three rounds of correction.

10. Track Claude Code token costs

You can’t manage what you can’t see. Claude Code’s current /usage view reports session and plan consumption, while API users can also inspect billed costs. For cross-session historical tracking, install ccusage and run ccusage daily --breakdown. Review several representative sessions before drawing a conclusion; usually one or two patterns account for most of my usage.

The thing to watch most closely is sub-agent and Agent Teams usage. Each active agent maintains its own context and uses its selected model, so total consumption scales with team size, task duration, and model routing rather than a fixed multiplier. That’s not a reason to avoid them. It’s a reason to use them deliberately, keep teams small, and shut teammates down when the work is done. I go deeper on how to structure that deliberately in multi-agent orchestration.

None of this requires changing how you think about Claude Code fundamentally. It’s mostly about attention to the resources you’re already using, context, model selection, session hygiene, and a few small habits that compound over time. The developers and teams I’ve seen reduce Claude Code costs have almost all done it the same way: they started tracking, fixed the biggest pattern, worked through the rest systematically.

If you want to understand the broader Claude Code workflow I’ve built around these principles, my post on managing six client projects covers the full setup. If you’re thinking about how to apply this kind of AI workflow across your organisation, that’s the work I do as a fractional CTO.

Common questions

How do I reduce Claude Code token usage?

Focus on the biggest levers first: clear context between unrelated tasks with /clear, keep CLAUDE.md concise, route models deliberately (Sonnet by default on metered billing, Haiku for search sub-agents), delegate bounded exploration to sub-agents, and control effort. Track usage with Claude Code’s current /usage view or a local history tool so you know which pattern is costing you the most.

Why is my Claude Code usage so expensive?

Usually it is context bloat and habit rather than the prompts themselves: an oversized CLAUDE.md loads repeatedly, unmanaged conversation history compounds, and heavier models or higher effort consume metered usage faster. Sub-agents and Agent Teams add separate context windows, so their cost scales with how many agents run, which models they use, and how long they stay active.

How do I track Claude Code costs?

Use Claude Code’s current /usage view for session and plan consumption. API users can also inspect billed costs. For cross-session historical tracking, install ccusage and run ccusage daily --breakdown; compare several sessions before deciding which pattern is driving spend.