Spend fewer tokens

What it is and why it matters

A token is a small piece of text: it's the unit used to measure how much work the model does. Every message you send, every file Claude reads, every answer and every bit of reasoning uses tokens. On a subscription they count against your usage limits. On the API they end up on your bill.

The thing I didn't get at first is this: with every message, Claude Code sends the model the whole conversation, not just your last sentence. The cache makes that re-reading cheaper, but not free. So a long chat costs more with every question, even a one-line question.

The second thing: most of the waste isn't the model you pick, it's the wasted rounds. You write a vague request, Claude does something else, you say “redo it,” it re-reads everything and tries again. You pay for every round.

1. Short chats, long files

I don't leave important decisions in the chat. I write them in a file in the project. I call it DECISIONS.md, but you pick the name. It holds very little: what we decided, why, and what's left.

When the chat gets long, or when I move on to unrelated work, I close it and open a new one. In Claude Code you do that with /clear: you start again from an empty conversation, and the project files stay where they are.

Before closing, I write:

Update DECISIONS.md with what we decided today and what's still missing.

Then /clear, and in the new chat:

Read DECISIONS.md and pick up from there.

That way the new chat starts light, with only what it needs, instead of dragging along hours of attempts, errors and outdated messages. If you care about an old chat, you don't lose it: /resume takes you back to it.

A note on CLAUDE.md, the instructions file Claude Code loads by itself at the start of every session. I only put rules there that always apply, and I keep it short, because it goes into every session even when it's not needed. The day's decisions go in DECISIONS.md, which Claude reads when you ask it to.

2. Don't paste logs

A log is the record of what a program does while it runs: errors, warnings, messages. It's often hundreds or thousands of lines. If you paste them into the chat, they all go into the conversation and stay there. And since the conversation is sent again with every message, you pay for those lines again with every question after that.

I don't paste anything long anymore. I tell Claude where the file is, or ask it to run the command itself, and ask it to come back with only what matters:

Read logs/server.log and find me the error: tell me only the lines that matter.

Run the tests yourself and look at the output: tell me what fails and why.

One thing to know: whatever Claude reads also goes into the chat. The advantage is that it can search inside the file and read only the useful parts, instead of taking in everything like when you paste. If the output is really huge, like all the tests in the project, I hand the job to a helper: the noise stays in its conversation and only the summary comes back to me.

Use a helper to run the tests: report back to me only which ones fail and why.

3. High reasoning, not max

In Claude Code you can decide how much Claude thinks before it answers. It's called the effort level, and it has five steps: low, medium, high, xhigh and max. The higher it is, the more tokens it spends thinking, and reasoning tokens are billed like the tokens in the answer.

On current models the starting level is medium. I keep my base level on medium or high, depending on the job: that's my choice, not a rule. You change it with the /effort command: on its own it opens a slider, or you type the level directly.

/effort high

I only turn on max for the session where it's needed: a bug nobody can find, a job that touches the whole project. Then I start again from my base level. That's convenient, because max applies to the current session only and doesn't stay saved. And the docs themselves warn that at max the model tends to overthink, with a gain that often isn't worth the tokens.

4. Helpers on the small model

Claude Code can hand pieces of work to helpers, called subagents. Each helper works in its own separate conversation and at the end gives you back only the result. For simple jobs, like finding where a function is used, summarizing a file or checking some copy, you don't need the biggest model.

If you don't say anything, a helper usually uses the same model as the main chat. The smallest model, Haiku, is fine for these jobs and uses less. There are two ways to use it.

You ask for it on the spot

When Claude starts a helper, it can choose the model for that job. You just have to ask:

Use a helper on the small model to find every place where the login is used, then give me the list.

You create it once and reuse it

Helpers you use often can be saved as files in the project's .claude/agents/ folder. The simplest way is to ask Claude to create one. In the file, the model field decides the model: with model: haiku it always runs on the small one.

Create a helper for this project that searches the code and summarizes files. Save it in .claude/agents/ and give it model: haiku.

Helpers use tokens too, on top of the main chat's. The savings come from the smaller model and from the fact that their noise doesn't end up in your chat.

5. One clear request

Three vague requests cost more than one clear one. With “fix the profile,” Claude has to explore half the project to figure out what you mean, then maybe fixes the wrong thing, and you start over. A precise request has it read just a few files and go straight to the point.

Before writing, I put in four things:

• Where: which page, which file, which button.
• What's wrong: what happens now.
• What I want: what should happen afterward.
• How I check: a test, a check, a result I can see.

Instead of “fix the profile,” I write:

On the profile page, the Save button doesn't save the email. Fix it and add a test that proves it. Don't touch any other files.

The “how I check” part matters most: if Claude can check its own work, it finds the mistake before you have to. And one less “redo it” is a whole round of tokens saved.

And if Claude heads in the wrong direction, stop it right away with Esc instead of waiting for it to finish.

The numbers: a typical day, over a month of work

These numbers are a realistic example of how things change, not an invoice. They depend on how much you work, on the project and on the model. They're here to show you where the savings come from.

• Before, with long chats and pasted logs: every new feature took 4 or 5 rounds of “redo it” on average, and a day of work used about 6 million tokens.
• After the five habits: 1 or 2 rounds per feature, and the same day uses about 3 million.

Most of the savings come from two things: cleaned-up chats, because a long chat gets re-read in full with every message, and fewer “redo it”s. At the end of the month the spend is about half, with the same work done.

You can see your own numbers with /usage: it shows the session's tokens and, if you have a subscription, how much of your limits you've used. With /context you see what's filling up the chat right now.

The rule: what you spend isn't the price of the model, it's how many times you make it redo the same thing.

Common mistakes

• Keeping one chat open all day: every message sends the whole history again, so close it with /clear when you switch tasks.
• Leaving decisions only in the chat: once you close it they're no longer at hand, so have them written to DECISIONS.md first.
• Pasting whole logs and outputs: tell Claude where the file is and ask it for only the lines that matter.
• Leaving reasoning on max even for small things: use it only for the hard bug's session, then start again from your base level.
• Sending vague requests and then fixing things with round after round of “redo it”: write where, what's wrong, what you want and how you'll check.

Checklist

• I have a DECISIONS.md file in the project
• I have it updated before every /clear
• I don't paste long logs into the chat
• Base reasoning on medium or high, max only for the session that needs it
• Helpers for simple jobs run on the small model
• Every request says where, what's wrong, what I want, how I'll check
• Every now and then I check /usage

Frequently asked questions