Key takeaways:
Stop wasting tokens in Claude Code by:
- Using /clear between unrelated tasks
- Referencing files with @ instead of pasting code
- Running /compact before you hit 60% context usage
- Saving Opus for hard problems and defaulting to Sonnet, and
- Keeping your CLAUDE.md under 50 lines.
You open Claude Code. You start a session. Three hours later you check your AI token usage and wince.
What happened? You weren’t doing anything wrong. You asked reasonable questions. You got good answers. The AI did what you asked. But somewhere in that three-hour stretch, your tokens quietly hemorrhaged. Not because of a single mistake but because of a dozen small patterns you didn’t know to watch for.
I use Claude Code daily. Here’s what I’ve learned about stopping the bleed.
Why your tokens are disappearing
Claude Code is stateless. Every message you send triggers a full re-read of the entire conversation history. Every file you loaded. Every error message you pasted. Every “actually, try it this way instead” you typed.
If you’re 200 messages deep in a session and you send one new question, Claude re-processes all 200 prior messages to answer it and it means token waste compounds fast.
A typical Claude Code session can run somewhere between $2 and $15 in API costs, depending on model choice, session length, and how much context you carry. The other guides out there will give you the full catalog. This article is the short list and focuses only on the fixes that actually move the needle.
Fix 1: Stop the marathon sessions
This is the one. The pattern I see most developers fall into (and the one that cost me the most before I broke the habit).
You start working on a feature. You ask Claude to scaffold it. Then you ask for a refactor. Then you spot a bug and ask for a fix. Then you remember a related edge case. Then you want a test. Then you’re deep in a different file entirely, and Claude is still re-reading the conversation about scaffolding from two hours ago.
Every message you send is paying to reprocess that scaffolding conversation. For no reason.
What to do instead:
Run /clear every time you switch tasks. A task isn’t “I’m done for the day.” A task is one bounded piece of work. Scaffold the component. Run tests. Done. /clear. Now fix the bug in the auth module. /clear. Now refactor the database layer. /clear.
It feels wrong at first. You’re throwing away context. That’s the point. The context you’re throwing away is stale and irrelevant to the next task. It might feel like you’re losing value, but really you’re losing dead weight.
There is one exception here: if your next task genuinely depends on what just happened, use /compact instead (see Fix 2). But the default should be /clear, not “keep going.”
I cut my daily token spend by roughly a third just by breaking marathon sessions into clean, bounded tasks.
Fix 2: Learn the compact vs clear decision
/compact condenses your conversation history into a summary. It keeps the key decisions and drops the back-and-forth noise. /clear wipes everything and starts fresh.
Knowing which to use is the difference between saving tokens and wasting them.
Use /compact when:
- You’re mid-task and the conversation is getting long but you still need context from earlier
- You’ve made architectural decisions you want Claude to remember
- You’re at ~60% context usage and the task isn’t done yet
Don’t wait until you’re redlined. At that point, /compact has too much to compress and will drop things you actually needed. 60% is the sweet spot.
Use /clear when:
- You finished one task and are starting an unrelated one
- The context you’d keep from a
/compactisn’t relevant to what’s next - You’ve been going for more than 30-45 minutes on a single task
If you’re not sure which to use: /clear. Worst case, you re-explain one thing. The alternative — carrying dead context through six more turns at a few cents per turn — costs more than that re-explanation ever will.
Fix 3: Stop pasting code, start referencing
This one took me embarrassingly long to learn.
I used to find the file I wanted Claude to fix, copy the whole thing, paste it into chat, and say “here’s the file, fix line 87.” Every single line of that file — all 400 of them — entered my context window and stayed there for the rest of the session.
The alternative: @src/components/auth.ts. Claude reads the file on demand. It enters context for that turn, and doesn’t carry over perpetually.
The token difference isn’t small. Paste a 400-line file: that’s roughly 600-800 tokens burned, plus those tokens get re-processed on every subsequent message. Reference it with @: the file loads when needed, and you’re not hauling 400 lines of irrelevant code through the rest of your session.
The one time pasting makes sense: short snippets. If you need Claude to see 10 lines, paste them. The overhead of a @ reference isn’t worth it for a handful of lines. The line is somewhere around 30-40 lines — below that, paste. Above that, reference.
Fix 4: Match the model to the task
I ran the same refactor across three models: Opus, Sonnet, and Haiku. Same prompt, same codebase, same task. Here’s how it shook out:
- Opus: Perfect result. $0.47.
- Sonnet: Same result. $0.19.
- Haiku: Missed a dependency. Needed a second turn. Total $0.08.
For that task, Sonnet was the obvious pick. Opus was overkill. Haiku needed hand-holding.
The pattern I’ve settled on: Sonnet is my default. It handles ~80% of real-world coding tasks — feature implementation, refactoring, bug hunting, test writing. Opus comes out for architecture decisions, complex debugging sessions, and anything where I genuinely need depth over speed. Haiku handles boilerplate, simple formatting, and quick one-line fixes.
What I don’t do anymore: stay on Opus because I forgot to switch back. If you finish a hard architecture discussion on Opus and then ask it to fix a typo on line 12, you just paid the Opus rate for a typo fix. Switch to Sonnet (or Haiku) before you move on.
Switching from Opus to Sonnet for routine work cut my daily token costs by about 60% and the output quality didn’t drop.
Fix 5: Stop being polite
“Hi Claude, I hope you’re doing well! Could you possibly help me with a small issue I’m having in my React component? I would really appreciate it if you could take a look at…”
That’s 37 tokens. Here’s the same request:
“Fix the state loop in src/components/Dashboard.tsx. The useEffect on line 23 is firing on every render.”
That’s 18 tokens. Same information. Half the cost.
Politeness is a tax in Claude Code. Every “please,” every “I was wondering if,” every “thanks so much for your help” — these are tokens that Claude processes, stores in context, and re-processes on every subsequent turn. For a single message, the difference is negligible. Across a 50-message session, it adds up.
You’re not being rude. You’re being efficient. Claude isn’t a person who needs social lubrication. It’s a tool. Give it the job, the constraints, and the target files.
The caveman pattern — direct, fragment-heavy, no articles — isn’t just a gimmick. It can cut token usage by roughly 10-20% per session.
Fix 6: Audit your MCP servers
Every active MCP (Model Context Protocol) server adds tool definitions to your context window on every turn. If you’ve got 12 servers connected and you’re only using 3, the other 9 are paddling your token bill for no reason.
Check what’s active. If a server isn’t serving the current project, disable it in your project config:
"disabledMcpServers": ["server-you-dont-need", "another-idle-one"]This is a “set and forget” fix. Do it once when you start a project and you save tokens on every subsequent interaction. Not dramatic per turn — maybe a few dozen tokens — but across days and weeks, it’s real money.
Fix 7: Batch your requests
Every message you send triggers a re-read of the entire conversation history. So if you’re asking three separate questions in three separate messages, you’re paying to re-read the history three times.
If you send all three questions in one message, you pay once.
This seems obvious. It’s not, in practice. The natural instinct in a chat interface is to go back and forth — ask a question, get an answer, ask a follow-up, get an answer. That’s exactly what makes the token bill climb.
Before you hit send, ask yourself: is there anything else I’m going to need in the next two minutes? If yes, include it now. Batch related questions. Front-load constraints. Give Claude everything it needs to solve the problem in one pass, not five.
The trade-off: longer individual turns, but fewer of them. And since each turn re-processes the whole context, fewer turns almost always wins on total token spend.
The anti-pattern catalog
These are the specific behaviors I see developers do daily that quietly double their token usage:
1. “Now explain what you just did.” Claude just generated a solution. Then you ask it to narrate what it did. You just paid for the output tokens of the explanation — and you doubled the conversation length for every future turn. If you need to understand the code, read it. If something’s unclear, ask about that specific line. Never ask for a full walkthrough.
2. Correction loops. “No, that’s not right. Try it this way. Actually, not that either. Hmm, what about…” Every failed attempt stays in context forever. Instead of correcting, edit your original prompt and regenerate. One clean turn beats four correction turns.
3. “Also, one more thing…” The classic. You finish a task, celebrate, then remember a related edge case and fire off one more message. That “one more thing” re-processes the completed task’s entire history. If you catch yourself doing this, ask: is this actually related, or is this a new task? If it’s new — /clear first.
4. Pasting full error logs. You hit an error. You copy the entire 200-line stack trace. You paste it. Claude now processes 200 lines of trace to find the one line that matters. Just paste the error message and the relevant 5-10 lines around where it threw.
5. Asking Claude to run commands you can run yourself. !npm test costs you nothing. Asking Claude to run tests, read the output, and report back costs tokens on the run, tokens on the output, and tokens for Claude’s summary. Use ! for shell commands whenever you can.
FAQ
How much do tokens actually cost in Claude Code?
Anthropic charges per million tokens. As of early 2026, Sonnet runs about $3 per million input tokens and $15 per million output tokens. Opus costs more. A typical developer using Claude Code for a full workday might spend $5-15 in API costs. Marathon sessions push that higher.
What’s the /compact command and when should I use it?
/compact summarizes your conversation history, compressing the back-and-forth into a concise record of key decisions. Use it when your session is getting long (around 60% context usage) but you’re still working on the same task. Don’t wait until you’re maxed out — at that point the compression has too much to chew through and may drop important details.
Should I use /clear or start a new session?
Same thing, effectively. /clear wipes context and keeps you in the same terminal. Starting a new session does the same but gives you a fresh terminal. Use whatever’s faster. The point is the clean slate.
What goes in CLAUDE.md?
The short answer: standing instructions that apply to every task in this project. Your tech stack, your architectural conventions, your preferred patterns, and things you want Claude to never do (like “never add comments” or “always use named exports”). Keep it under 50 lines. If it’s longer than that, you’re loading documentation — not setting defaults — and you should move the bulk to separate files referenced with @ only when needed.
Does this stuff actually save money or is it marginal?
On a heavy coding day, the difference between optimized habits and sloppy ones is roughly $5-10. Across a month of daily use, that’s $100-200. For a solo developer paying their own API bills, that matters. For a team of five, it’s real budget territory.
Focus on Fix 1 first. Break the marathon habit. Everything else compounds from there.