# Claude Code, Beyond the Prompt — Part 7: How I Cut Claude Code's Token Bill (and Made It Faster)

> Source: <https://dev.to/gde03/claude-code-beyond-the-prompt-part-7-how-i-cut-claude-codes-token-bill-and-made-it-faster-3hoj>
> Published: 2026-07-14 12:21:42+00:00

*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.

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.

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.)

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.

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.

Don't take my word for any of it — instrument it:

You're optimizing information density. Treat context as a budget and spend it on signal.

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.

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:

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.

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](https://github.com/GiulioDER/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.

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.*