Use Claude Code in earnest and you will meet "usage limit reached" sooner or later. This chapter is about the practices that keep it away.
Saving for its own sake is not the point, though. The point is having allowance left when it matters. Pinching pennies until the work suffers defeats the purpose, so the last section is about where to draw the line.
Why consumption grows
Consumption is counted in tokens. What most people get wrong here is assuming it is set by the length of the instruction you sent.
Every file Claude went and read for itself rides along in the input. Have it read a large file whole and the count jumps.
Every exchange sends the history so far along with it. A long conversation raises the unit price of each round trip.
Fixing until the tests pass spends one round trip per failure. The flip side of the strength.
Of the three, the one you can move most is FACTOR 2. Which files get read is set by the work, and the number of attempts by the difficulty, but the length of the history is something your habits control.
"Short instructions are cheap" is a misunderstanding. When an instruction is too short to carry your intent, Claude searches more, builds the wrong thing, and starts over. The round trips multiply and it ends up costing more. What is cheap is not a short instruction but one that lands on the first try.
There is more than one kind of allowance
Chapter 4 touched on this, but it is the single most useful thing to understand. There is a short-cycle allowance and a long-cycle allowance, and they are separate.
The short one recovers fairly quickly, so waiting gets you back to work. The long one takes days to come back, and using it up leaves you unable to work for several of them. "It came back a moment ago and then stopped again right away" is the short one returning while the long one was still spent.
How the allowances behave is covered in what to do about usage limit reached, and measurements of the weekly allowance coming back earlier than expected are collected in the truth about early weekly-limit resets.
Get the heavy work done before the deadline, and save exploratory experiments for hours when there is room to spare.
Burning the long allowance on trial and error, then being unable to work on the day the real job is due. All you can do is wait for it to recover.
Effort — choosing between speed and smarts
Claude Code has a setting for how much thinking to do. Thinking harder raises accuracy, but it also costs more time and more tokens.
Neither "always maximum" nor "always minimum" pays off here. The right answer is to switch by how hard the task is.
Routine replacements, formatting, adding tests, implementing something whose approach is already decided. Work with nothing left to figure out.
A bug with no known cause, a design choice, a change whose blast radius you cannot read. Work where a wrong turn costs a lot to undo.
What the setting contains and when to use which is covered in What is the effort setting? Faster vs smarter. The axis for deciding is comparing against the cost of rework. If thinking hard gets it right the first time, that is cheaper than going light and redoing it three times.
Folding the context is a cost decision too
Chapter 3 framed folding as something you do because it stops being able to remember, but there is a second motive. A long history is resent every time, so working on without folding makes each round trip steadily more expensive.
That said, folding itself consumes something too. Fold too aggressively and you lose premises you still need, have to explain them again, and end up paying more. The criteria are collected in Should you run /compact on a schedule?.
When to fold
Good : right after one piece of work finishes
before moving on to a different set of files
Bad : partway through (premises you are about to use disappear)
"it just got kind of long" (no judgment involved)
The ways it most easily goes to waste
Most consumption comes from round trips that produce nothing. Here are the common shapes.
With no tests, "done" cannot be checked, so you look, point out the problem, and it redoes it. More round trips.
Of the thousands of lines, a few dozen matter. Hand over only the relevant part and you get the same result cheaper.
Unrelated work piles into the same history, and you carry it with you from then on.
Project-specific conventions can live in the persistent memory from Chapter 6 instead of being typed out again.
Knowing your own consumption
Before cutting, it pays more to know what you are spending it on right now. Saving by feel usually trims the places that were not the problem.
There are two things to look at: how much the current conversation has swollen, and how much allowance is left. The first informs the decision to fold, the second the decision of whether to start this piece of work today.
The allowance left. It decides whether to begin something heavy. If little is left, switch to lighter work or wait for recovery.
How far the conversation has swollen. It decides whether to fold before the next task. No need to look partway through.
What matters is not checking more often. Looking at the remaining balance every few minutes does not reduce anything. The seams between tasks are enough.
Savings that backfire
Some things done in the name of saving have the opposite effect. All of them are common sights.
The premises do not land, the wrong thing gets built, and the redos multiply. Trim what you paste, not what you explain.
Fold partway through a task and the premises you are about to use disappear. Explaining them again costs more.
Make it think shallowly about a bug with no known cause and it tries one wrong hypothesis after another. More time and more tokens.
Fiddling while everything is stopped means you cannot see whether it helped. Wait for recovery, then try one change at a time.
What grows when a team uses it
Consumption you never noticed working alone surfaces in a different form once a team is involved.
The most common case is everyone explaining the same premises separately. Project conventions, naming rules, the places nobody should touch—if each person writes them out every time, the duplication scales with headcount. The right move is to put them in the persistent memory from Chapter 6 and share it through the repository.
The other is the pattern where someone burns the allowance on exploratory work and someone else is stopped mid-delivery. Behavior differs depending on whether the allowance is personal or organizational, so confirm at least that much before rolling it out.
Fixing the shared material works better than imposing rules. Telling people to "save tokens" only scatters their individual judgment, but when the persistent memory and a way to verify are both sitting in the repository, everyone's round trips drop on their own.
In practice — seven ways to consume less
In order of impact. The first two solve most of it.
The shorter the history, the cheaper each round trip. This is the big one.
Put it in a state where it can check and fix on its own, and the round trips with you drop.
Name the directory or the files. The whole exploration phase falls away.
Routine work does not need the maximum. Do not skimp on the hard parts.
Anything you explain every time is something to write down once (Chapter 6).
Right after a task finishes. Folding partway through means explaining it all again.
Move investigation into a separate context and the main history stays clean (Chapter 6).
Cost optimization across AI coding in general is covered from a wider angle in the complete guide to AI coding cost optimization.
Where to draw the line so you do not over-save
Finally, the thing this chapter most wants to say. Saving is not the goal.
Worrying about the allowance so much that you run even hard work on a light setting, then fix a wrong implementation over and over—that costs more tokens and more time both. It is the classic case of wasting in the name of saving.
Decide by the size of the rework. Work you can undo in minutes goes light and fast. Work where a mistake dissolves half a day gets deep thinking from the start. The allowance is what you keep back for the second kind.
And one more thing. Resting when you are stopped is part of the practice too. Rather than pulling settings apart the moment you hit the limit, waiting for recovery and resuming in good shape finishes the job sooner.
Summary
- Consumption is set by the files it read, the conversation history, and the number of attempts. What you can move is mostly the history
- "Short instruction = cheap" is a misunderstanding. What is cheap is an instruction that lands on the first try
- There are two allowances, one short-cycle and one long-cycle. Use up the long one and you are out for days
- Switch effort by difficulty. Always maximum and always minimum both lose
- Folding is about memory and about cost at the same time. But folding partway through costs more
- The two with the biggest effect are splitting up the conversation and handing over a way to verify first
- Saving is not the goal. Decide by the size of the rework, and keep allowance back for the hard parts