Saving Tokens with Claude: 6 Principles That Make Experts Twice as Fast
For a long time the most expensive line in my project wasn’t code at all. It was the AI that re-trawled half my repo on every task, announced in three paragraphs what it was about to do, and ended with a question whose answer was obvious. Multiply that by a hundred agent runs a day — that’s a real bill in tokens, waiting time, and patience.
At some point I stopped reading my CLAUDE.md as a style guide and started treating it as a performance budget. A file full of polite requests gets ignored. A file full of hard rules whose breach counts as a bug actually changes behavior. Here are the six principles that helped the most.
1. Search Narrow, Not Broad — Follow Pointers Instead of Digging
The biggest token sink is the blind search. An AI poking through the repo with twenty grep calls pulls in context on every hit that it won’t need 90 percent of the time. The context fills with noise, and noise costs again on every later step.
My countermeasure is a context gate as the very first step of any task: exactly one global RAG run — not to load the whole context, but to fetch code pointers, meaning file and line. Only then does it read at that exact spot. The principle behind it is “pointer always, content on demand.” The AI gets a map, not a read-aloud encyclopedia.
The difference isn’t cosmetic. It’s often the difference between “Sonnet handles this” and “I need Opus for that.”
2. Cap the Output Hard — with Tags, Not Good Intentions
“Keep it short” doesn’t work. It’s a request, and requests get interpreted away. What works is an output contract: every reply starts with a tag that carries a character limit.
[DONE] for completed tasks, [RECAP] for pure reading, [OPEN] for partial progress, [QUESTION] only for hard-to-reverse actions — each with a hard limit. The trick isn’t the limit itself, it’s that a breach counts as a bug, not a matter of taste. That flips the burden of proof: the AI has to earn its verbosity, not me my brevity.
Where the real leverage is
It isn’t the limit that saves tokens, it’s flipping the burden of proof. As long as brevity is a request, the monologue wins. Only once length has to justify itself does it become rare.
3. Let It Run Through Instead of Asking Back
The most expensive delay is the needless round trip. I switch screens, come back ten minutes later — and instead of a finished feature I find a trivial question about padding. That isn’t service, it’s a full stop.
So I run an autonomy default: start immediately, work through to the end. Reversible decisions — naming, ordering, refactor structure, library choice — the AI makes itself and flags briefly. It only asks on real risk: data deletion, prod deploy, migration, security.
My rule of thumb is written verbatim in the rules file: if the answer would be correctable in under 30 seconds — don’t ask, do it. A typo in a variable name costs me five seconds to fix. A question about it costs a whole round trip.
4. Tag Discipline Is Honest Reporting — and Token Saving on the Side
Once you cleanly separate “read” from “changed,” you can no longer pad. A read or a RAG query on its own is [RECAP] — never [DONE]. A tool call is not the same as completing a task.
It sounds like bookkeeping, but it’s the most effective lever against the “look at everything I did” monologues. When pure reading isn’t allowed to sell itself as success, the incentive to write three paragraphs about your own thoroughness disappears. A tag can’t lie: either something changed, or it didn’t.
5. Reusable Workflows Instead of Long Prompts
Routines that always run the same way don’t belong in the prompt, they belong behind a keyword. Short triggers fire server-side workflows that bring their own steps and schemas. The steps come from the server, not from local context.
I throw a word, the rest comes on demand. Instead of copying a 40-line routine into every prompt — and paying the tokens for it every time — the routine sits centrally once and is loaded step by step. It’s the same logic as the pointer search from principle 1, just at the process level instead of the file level.
6. Docs as a Pointer System — Re-Entry Without Re-Discovery
What costs the next AI session the most is rediscovering what the last one already knew. Without a trail, every session starts by digging.
So every function I touch gets a doc block with search terms and code pointers right in the code. After it’s absorbed into the RAG, the block shrinks to a lean marker — the full text moves into the RAG, only the pointer stays in the code. Pointer always, content on demand. The next session reads the marker, pulls the full text when needed, and doesn’t have to rediscover what was documented long ago.
Conclusion
The common denominator is a single sentence: never load anything into context that you could load on demand — and never say anything nobody asked you for.
Pointer over full text in search. Tags over prose in output. Autonomy over round trips in the flow. Keywords over walls of prompt in the process. Four variants of the same idea.
The surprising part: I didn’t just save money, I also got faster, because less back-and-forth, and more honest, because a tag can’t lie. Sonnet now reaches Opus level on tasks that used to need the bigger model — not because the model got better, but because I stopped slowing it down with ballast of my own.
The same logic scales past a single config file: routing the right model to the right task, with the context kept lean, is exactly what the AI orchestration in the boostN app automates.
Entdecke mehr
Controllable Remote Coding Sessions: One Level Above the IDE
The session URL had suddenly vanished from the terminal. How we found it again via a server endpoint — and why it enables working above the IDE.
GlossarSpeech-to-Text (STT)
Speech-to-Text refers to the automatic conversion of spoken language into text by an AI model. In an AI workflow, STT replaces the keyboard as the input channel — what matters is model size and domain vocabulary.
LexikonAI Coding Tools Compared
Cursor, Windsurf, Claude Code, GitHub Copilot, Continue.dev, Aider compared. With table and decision guide for four typical developer workflows.