If your Claude Code usage is climbing faster than expected, start by checking what your sessions are carrying. Instructions, conversation history and tool results can all contribute to usage before you get the answer you need.
This guide covers concrete configuration and workflow changes that reduce token volume. Lower cost and lower token usage are related but different: cheaper models can increase total spend if they need more turns to complete the same work. The focus here is reducing how much context Claude must process on every request.
Quick answer (30 seconds)
Run /context to see what's loaded at startup. Audit your CLAUDE.md and MCP connections to remove unnecessary material. Use /clear between unrelated tasks and /compact when continuing related work. Match model capability to task difficulty. Be specific in your first request to avoid correction loops. Consider tools that compress tool output before it reaches your main session.
1. Check what is consuming your tokens
Before changing anything, establish where tokens are actually going.
The /context command shows how your context is allocated at any point in a session. At startup, you'll see how much is consumed by Claude Code's own harness, your MCP servers, and any CLAUDE.md instructions loaded automatically. As you work, you can compare snapshots to see how turns and tool calls compound the total.
Requests carry the conversation's active context, including tool results. Caching can lower the cost of repeated input, while compaction and other context management can change what remains in the conversation. A short new prompt can still accompany a substantial amount of earlier material. Anthropic explains how long sessions affect usage.
Use /usage alongside /context: one helps you inspect consumption and allowance, while the other helps you inspect the context window. On a subscription, the displayed session dollar estimate is not an additional bill for that session.
Context can grow as instructions, conversation and tool results accumulate. Tool details may load on demand; compaction or clearing can reduce retained context. The diagram is illustrative, not a measured token chart.
Reader action
run
/contextnow, then again after a few turns. Identify whether growth comes from startup overhead, accumulated history, or tool responses.
2. Reduce the context loaded at startup
Startup material becomes part of every subsequent request. The goal is keeping what's genuinely useful and deferring specialized references until needed.
Audit your global and project-level CLAUDE.md files. Recurring instructions should be lean and actionable. Move specialized reference documentation to on-demand retrieval rather than automatic inclusion. Splitting a document into files imported with @ does not itself save context: those imports still load. Claude Code's memory documentation explains the distinction.
Review your MCP server configuration. Claude Code optimizes tool discovery by listing available tools without loading full schemas by default, though names and instructions still consume context. Disconnect servers you aren't actively using. Run /mcp to see what's configured and disable genuinely unnecessary connections. Check your deployment's behavior before assuming every server loads every schema; MCP tool search defers definitions by default, with provider and configuration exceptions.
Reader action
inspect your startup context and remove material that doesn't serve your immediate work.
3. Stop carrying old work into every new task
Accumulated conversation history contributes to input tokens on every new request. The right continuity strategy depends on whether your next task relates to what came before.
Use /clear when switching to unrelated work. This starts a fresh session without historical baggage.
Use /compact when continuing related work that has grown unwieldy. Compaction summarizes the conversation so you can proceed without full history. Be aware that compaction itself consumes tokens and involves some lossiness; key decisions may need explicit preservation.
Old conversation history can become baggage for a new task. Start fresh for unrelated work, or preserve a useful summary when you need continuity.
Reader action
choose clear versus compact at genuine task boundaries, not habitually.
4. Review your model and reasoning settings
Common advice suggests using cheaper models for routine work. This can reduce per-token cost, but not necessarily total spend or time.
In my early experiments, I tried cheaper models when I ran out of allowance or wanted to see what else could do the job, and some of those early experiments required much more steering and correction from me. That experience is why I value frontier models for architecture, planning and complex coding, even when another model's tokens cost less.
Choose sufficient reasoning depth for the task. The /model command selects your model; /effort adjusts reasoning intensity on supported models. Make these choices deliberate rather than defaulting to maximum or minimum. Supported effort settings vary by model; consult the model configuration guide for your setup.
Reader action
match model capability to task difficulty, including the choice to keep the stronger model where judgment matters.
5. Reduce repeated prompts and unnecessary response text
Extra turns carry history forward. Generated explanation consumes output tokens. Both compound.
Specify what you need and the response detail required in your initial request. Avoid loops where you repeatedly correct or narrow scope. When lengthy explanation isn't useful, ask for concise responses or specific formats upfront.
Large pasted inputs deserve attention here too. Pasting a full API response or log file adds that material to context for subsequent turns. Consider summarizing or filtering before inclusion when the full text isn't required for ongoing work.
Reader action
front-load specificity to minimize correction cycles and unwanted verbosity.
6. Use tools that reduce how much data reaches Claude
Tool output often contains far more than the model needs to proceed. Raw API responses include metadata, formatting, and fields irrelevant to your task. Test output can span hundreds of lines when a pass/fail summary suffices.
Command-output compression and focused code retrieval are concrete mechanisms for keeping context lean. While exploring APIs, I found myself getting huge JSON responses full of metadata when a representative record would have helped me understand the shape, followed by code to extract the fields the application needed. Test output created a similar frustration: I needed to know whether the tests passed and, if not, what failed.
Get a sample API record, then pare it down to the fields your application actually needs. Use that smaller example to understand the data's shape and write code that extracts those fields from the full response. Check for optional fields and variations that the sample might not show.
For tests, ask for a pass/fail summary and the details of any failures. Keep the full log available if you need to investigate.
These optimizations address information-processing overhead without sacrificing the capable model's judgment. The goal is preserving high-value reasoning while reducing the cost of delivering information to it.
Reader action
evaluate optimization tools against the source of waste you've already identified.
7. Delegate large tasks without filling the main session
The orchestrator pattern keeps your main session focused while bounded work happens elsewhere.
Treat your primary Claude instance as a manager delegating to subordinates. The orchestrator maintains awareness of what's being built. Subagents work in separate context windows, investigate discrete topics, and return compact reports. Implementation details, research tangents, and intermediate files stay outside the main conversation.
This preserves continuity and reduces accumulation in your primary session. Worker tokens still count toward usage, and coordination has its own overhead. The subagent documentation explains how their separate contexts work. The benefit is keeping your main context lean for the architectural and judgment work where frontier models excel.
Keep detailed investigations with the workers and return useful reports to the main conversation. Worker usage and coordination still count; this illustration does not imply a measured saving.
Reader action
consider delegation for substantial bounded work; don't assume it automatically reduces total usage.
Checklist
- Diagnose: run
/contextand/usageto identify growth sources - Audit startup: trim
CLAUDE.mdand MCP connections - Manage continuity:
/clearfor unrelated tasks,/compactfor related continuation - Select deliberately: match model and effort to task requirements
- Request precisely: specify needed output upfront to reduce turns
- Optimize tool output: compress or filter before inclusion
- Delegate selectively: use subagents for bounded work with compact returns
FAQ
Does clearing or compacting delete my work?
They change conversation context, not the files already written to disk. /clear removes the current conversation context; /compact replaces older detail with a summary. Save important decisions in a file before relying on a summary to preserve them. See context management.
Will cheaper models always save money?
Not necessarily. Lower per-token cost can be offset by more turns, corrections, and personal time spent steering. The cheapest successful completion is the one that finishes correctly with minimal back-and-forth.
How does caching affect what I see in /usage?
Cached input is charged differently than fresh input. The session breakdown distinguishes cache usage. Caching helps but doesn't make context free; the cost documentation also distinguishes estimated session costs from subscription billing.
Can tools guarantee specific percentage savings?
No. Savings depend on your specific workflow, tool usage patterns, and what you delegate. Evaluate any tool against your actual sources of waste.