Claude Code Token Usage: What Actually Eats Your Limit (and How to Make It Last)

Token usage in Claude Code is the total amount of text the model processes on each turn, measured in tokens - small chunks of text roughly the size of a few characters or a short word. Every turn has two halves: input tokens (everything Claude Code reads before it responds) and output tokens (everything it writes back). Both count against your usage, and output tokens are the more expensive half.

The part most people miss is that Claude Code is stateless between turns. It does not remember your last message on its own - the full conversation so far is re-sent as input on every single turn so the model can see the whole thread. That means a session that has run for twenty messages is sending twenty messages of history as input on message twenty-one, before you have even added your new request. This is why long sessions feel like they get slower and burn usage faster: the input is growing every turn.

The single largest source of wasted token usage is Claude Code reading large files in full when it only needed a small part of them. When you ask a vague question in a big project, Claude Code opens files to figure out where the relevant code lives - and a single large file can be thousands of tokens of input, most of which was irrelevant to the change you wanted.

The fix is to point it at the exact target. Instead of "fix the login bug," say "in src/lib/auth.ts, the token refresh on line 40 is not clearing the old session - fix that." Now Claude Code reads one file, or one section, instead of hunting through five. In the Claude Code desktop app you can drag the specific file into the conversation so it never has to search. Every file it does not have to open is input you did not spend.

Because the whole conversation is re-sent as input on every turn, a marathon session gets more expensive the longer it runs - even if your individual messages stay short. The first message in a session might send a few hundred tokens of input. The fiftieth message sends the accumulated history of the first forty-nine turns before your new request is even read. You are paying to re-transmit the entire backstory over and over.

The fix is conversation hygiene: start a fresh session when a task is done. End a focused work block with a one-line summary - "we added the invoice PDF export and fixed the date bug; next is the email step" - then open a new session and paste that summary as the first message. You carry forward the decisions without dragging the entire transcript, which resets your input cost back to near zero.

Output tokens are the expensive half of usage, and the most wasteful output is a large build that went in the wrong direction. When you ask Claude Code to implement a big feature in one shot, it may write hundreds of lines across several files before you get to see whether the approach was right. If it was wrong, you have paid for all that output and now have to pay again for the rewrite.

Plan mode fixes this. You ask Claude Code to produce a plan first - the files it will touch, the approach, the order of steps - and you approve or correct it before it writes a single line of implementation. The plan is cheap output; the wrong implementation is expensive output. Catching a bad approach at the plan stage is the highest-leverage way to cut output token usage on anything non-trivial.

Your CLAUDE.md file loads as input at the start of every session, so its length is a fixed tax on every conversation. A tight, 300-word CLAUDE.md that states your stack, your conventions, and your no-go zones is a good investment. A 5,000-word CLAUDE.md that tries to document everything is spending token budget on rules the model rarely needs, on every single turn, forever.

Aim for the shortest CLAUDE.md that reliably stops the mistakes you actually see. If Claude Code keeps using the wrong import, add a line about your stack. If it keeps touching a folder it should not, add a no-go line. Do not pre-load rules for problems you do not have. Lean context is cheaper and, again, more accurate - the model is not diluted by rules that do not apply to the task in front of it.

If you feel like you are hitting limits faster than the work justifies, the cause is almost always one of the drains above rather than the volume of real work. Run through this checklist before assuming you need a bigger plan. Most usage problems are a context problem in disguise.

If you have tightened all of that and still consistently run out, that is the signal that your workload genuinely needs more headroom - and that is a plan question, not a usage-discipline question. The [which Claude plan for Claude Code](/blog/which-claude-plan-for-claude-code) post breaks down Pro versus Max by real usage, and the [Claude Code usage limits guide](/blog/claude-code-usage-limits-what-to-do) covers what to do the moment you hit a cap mid-build.