Part 7 (finale) of Claude Code, Beyond the Prompt — patterns from running a live automated trading system on Claude Code. Part 6: GitHub as Claude's task queue.
Every token Claude reads costs you twice: once in money, once in time. A bloated context isn't just a bigger bill — it's a slower response, every single turn.
When people want to fix this, they reach for the wrong lever: switch to a cheaper model. But the model isn't where the waste is. The waste is in making Claude read things it doesn't need to and redo things it shouldn't have to. And it turns out the six pieces from this series — built for other reasons — are, almost by accident, a token-reduction system.
Here's how the savings actually work, and how to measure your own. This is the payoff article, so it's concrete.
The core insight: tokens are the currency of both cost and speed
This is the mental model that changes how you work: tokens are the shared currency of your bill and your latency. Anything that reduces what Claude has to read or regenerate wins on both axes at once. You're not trading cost against speed — you're buying both with the same coin.
So the optimization target isn't "cheaper model." It's information density: maximum relevant context, minimum noise, in every turn.
Where the tokens actually leak
Watch a naive session and the waste is obvious once you know where to look. Each leak maps to a piece we already built:
| The leak | The fix | From |
|---|---|---|
| Re-explaining your whole project every session | Claude reads a small memory file instead | Part 1 |
| Redoing work because it acted on stale state | Ground first; no wasted work on wrong assumptions | Part 2 |
| Re-typing long procedural prompts | One command invocation instead of a paragraph | Part 3 |
| Pasting giant logs and command dumps | MCP tools return small, structured results | Part 4 |
| Reading ten whole files to find one function | Semantic search returns the relevant chunk | Part 5 |
| Re-deriving history and "what changed" | GitHub holds the record; Claude reads only what it needs | Part 6 |
The biggest two are almost always the first and the fifth.
Re-explaining context (Part 1): without a memory file, you spend the opening of every session re-establishing your stack, conventions, and current state — hundreds of tokens of preamble before any work happens. With one, that context is a compact file Claude reads once. Multiply by every session, forever.
Reading whole files (Part 5): this is the giant. Grepping-and-reading to locate code routinely pulls ~6,000 tokens across five files to find the 30 lines that matter. A good semantic lookup returns ~300 tokens — the right chunk. That's roughly a 20× reduction on a single lookup, and lookups happen constantly. (Illustrative, not a lab measurement — but the order of magnitude is real, and you'll see it yourself the first time you compare.)
Three platform levers most people miss
Beyond the six pieces, Claude Code gives you three more levers that are pure token savings:
1. Prompt caching. The stable prefix of your context gets cached — so a stable, skimmable CLAUDE.md stays cached across turns and is cheap and fast to reuse. This is a concrete, dollars-and-milliseconds reason the Part 1 split pays off: the stable file caches cleanly; the dynamic file is kept small. Churn your always-loaded context and you keep busting the cache and paying full freight. Stability isn't just tidy — it's cached.
2. Lazy / deferred tool loading. Every tool you load carries a schema that sits in context. Load two hundred tools eagerly and you've spent thousands of tokens before saying a word. Claude Code can defer tool schemas and load them on demand, so a session only pays for the tools it actually uses. Skills work the same way (Part 3): only the short description is always loaded; the body loads when relevant. Progressive disclosure is a token strategy, not just an organizing one.
3. Subagents for heavy reading. When a task needs Claude to read a lot — search across dozens of files, sweep a big directory — spin up a subagent to do the bulk reading in its own context and return only the distilled conclusion. The 50,000 tokens of spelunking happen off to the side; your main thread receives the 500-token answer. For big fan-out work this is one of the largest single savings available, and it keeps your main context clean for the actual work.
The point is that they compound
Here's why this is a finale and not a footnote: these don't add, they multiply, because each attacks a different part of the session.
A naive session looks like: re-explain everything + grep-read ten files + paste a wall of logs + redo work that assumed stale state. Stack the fixes and that same session becomes: read a compact memory file + one semantic lookup + structured tool results + grounded, no-rework execution. Every phase got denser. The totals aren't close.
I won't hand you a tidy "I cut costs 80%" number, because it would be dishonest — your codebase, your tasks, and your model choice all move it. What I'll tell you plainly: the direction is large and consistent, and the two biggest wins are memory (stop re-explaining) and semantic search (stop reading whole files). Start there; they're most of the gain for least of the effort.
Measure your own
Don't take my word for any of it — instrument it:
- Claude Code can show your token and cost usage. Check it before and after adopting these patterns.
- Watch two things specifically: tokens-per-session, and how often Claude reads whole files versus targeted chunks. The second is the leading indicator — when it drops, the bill follows.
- Notice the latency, not just the invoice. Denser context means faster turns, and on a long working day that's the part you actually feel.
You're optimizing information density. Treat context as a budget and spend it on signal.
The mindset shift
If you take one thing from this article: stop asking "how do I prompt better" and start asking "what is Claude reading that it doesn't need to, and what is it redoing that it shouldn't have to?"
Every token you remove is money saved and latency cut. That reframe — context as a scarce budget spent on signal — is what turns a big monthly bill into a small one and a sluggish assistant into a fast one.
Where the series lands
Seven parts ago I made a claim: getting dramatically more out of Claude Code has almost nothing to do with writing better prompts. I hope the case is made now.
The leverage was never in the prompt. It was in the scaffolding around it:
- Memory so it never forgets your project (Part 1).
- Rituals so it's grounded in what's true before it acts (Part 2).
- Commands so your workflows and judgment are captured once (Part 3).
- MCP tools so it can act on your systems inside a fence you built (Part 4).
- Semantic search so it finds by meaning, not by guessing (Part 5).
- GitHub so there's a shared, persistent source of truth (Part 6).
- Token sense so all of it runs cheap and fast (Part 7).
None of it required a bigger model. Every piece is something you can build incrementally, starting with a ten-minute memory file this afternoon. Do them in order and each one pays for itself before you build the next. Together they turn Claude Code from a chat box into the operational layer for real work — which is exactly what it's been for me, running a live system on it every day.
Going deeper
The one piece I kept pointing away from — the retrieval machinery under semantic search and memory — has its own home: my open-source RE-call. It digs into giving an agent a memory that genuinely works — the architecture, the evaluation harness, and the honest findings, including the experiments that failed — with a full writeup in docs/WRITEUP.md. If the RAG parts of this series were your favorite, that's where to go next.
And if the evidence is what hooks you: I ran about a dozen fine-tuning and RAG experiments on a real prediction system — walk-forward splits, permutation tests, pre-registered kill-gates — and most of them died. The autopsies are worth more than any hot take: why a bigger model with a better loss made worse decisions, why RAG-in-the-prompt failed eight straight times, and the one rule that explains all of it. It's all here: Fine-Tuning and RAG: What a Dozen Failed Experiments Taught Me.
Thanks for reading the whole way. If you build even one of these, tell me how it goes — I read every reply.
The finale of Claude Code, Beyond the Prompt. Building something similar, or hiring people who do? The deeper agent-memory research is open source — RE-call, linked above. Follow for the next series.
Top comments (2)
Token reduction is most useful when it comes from better operating shape, not just shorter prompts.
The big wins usually come from narrowing context, reusing durable project facts, stopping repeated scans, and making verification targeted. Faster and cheaper is nice; less accidental reasoning is the real upgrade.
Yes, and your last line is a better framing of my own post: less accidental reasoning is the real upgrade. I pitched tokens as the shared currency of cost and speed. You're naming the third axis, correctness, and it's the one that actually matters.
The practical consequence: don't optimize for fewer tokens, optimize for density. Naive token cutting can make the model worse, you truncate the wrong thing and lose signal. Density makes it better, and the bill falls out as a side effect.
Concretely: a grep spelunk that pulls 6,000 tokens across five files doesn't just cost more, it hands the model five files' worth of plausible but irrelevant material to anchor on. The retrieved chunk is cheaper and less wrong. Same with memory, a stale fact sitting in context isn't wasted tokens, it's a wrong answer waiting to happen.
Cost was never the point, it was just the part that shows up on the invoice.