SAVE THIS

Three Leaks Are Draining Your Claude Code Bill

Claude Code spends your tokens in three places: reading your codebase, writing too much code, and clogging its own memory. Here is the fix for each. Two are free and one is already built in.

Claude Code spends your tokens in three places: reading your codebase, writing too much code, and clogging its own memory. Here is the fix for each one. Two of them are free and one is already built into the tool you are paying for.

Most people burn through their plan in a couple of days and blame the model. It is almost never the model. The tokens leak in three predictable spots, and once you can name them you can plug each one.

Here is the whole method before I explain any of it. Give Claude a map of your project so it stops re-reading every file. Make it write the smallest amount of code that solves the problem. Push the heavy reading into a side worker so it never touches your main chat. Do all three and the $20 plan starts doing what the $100 plan used to.

None of this is a trick. It is three specific changes, one per leak, that you can set up in an afternoon and keep for the life of the project.

Where the tokens actually go

Fix the cause, not the symptom. Every wasted token falls into one of three buckets, and each bucket has a different owner.

Token sinkWhat happensThe fix
ReadingIt re-reads your whole codebase on every new session.Graphify (a knowledge graph)
WritingIt over-builds. Fifty lines where one would do.Ponytail (a free skill)
RememberingHeavy reading and research floods the main chat.Subagents (built in)

One is a tool you install. One is a free open-source skill. One ships inside Claude Code already. You do not have to pick between them. They plug different holes, so running all three is the point.

Why should an operator care about tokens at all

A token is the unit Claude bills against. Roughly speaking it is a chunk of a word, and every file it reads and every line it writes spends them. When people say they hit their limit in two days, what happened is that the tool spent thousands of tokens on work they never saw: re-reading files, drafting code they threw away, holding search results in memory. You are not paying for answers there. You are paying for overhead. The three fixes below each cut a different slice of that overhead, which is why the same plan suddenly lasts.

A note before you start. Graphify and subagents are model-agnostic. If you run Codex, Cursor, or Gemini CLI instead of Claude Code, the reading and remembering fixes still apply. The commands below are written for Claude Code because that is where most operators live, but the idea travels.

Leak one: what Claude reads

Every time you open a new session, Claude reads through your files to understand the project again. On a large repo that is thousands of tokens gone before you have typed a single question. You are paying to re-teach it something it learned yesterday.

Graphify reads your codebase once and builds a knowledge graph of it: every file, every function, and how they connect. The next session, Claude walks the graph instead of re-reading the files. It looks up the map rather than reading the whole book again.

Install it

Two commands. The first installs the package. The second registers Graphify with Claude Code.

Copy this.

uv tool install graphifyy
graphify install

Build the graph once

Open Claude Code inside your project and run this. It maps the whole thing in one pass.

Copy this.

/graphify .

It writes three files into graphify-out/: an interactive graph.html you can click through, a GRAPH_REPORT.md with the key concepts and some suggested questions, and graph.json, the full graph Claude queries. Rebuild it when the codebase changes a lot. On a stable project you can leave it for weeks.

Your first real run

Stop grepping. Ask the graph instead.

Copy this.

/graphify query "how does auth work"
/graphify path "LoginForm" "Database"
/graphify explain "PaymentService"

query answers a question against the graph. path traces how two parts connect. explain unpacks a single node. Point it at the thing you would normally open six files to understand, and let it answer from the map.

A knowledge graph, in plain terms, is a searchable index of how your project fits together. Instead of the raw text of every file, it stores the pieces and the relationships between them: this function calls that one, this route hits that service. Claude can walk those links to answer a question without loading the source of every file it passes through. That is why the same question costs a fraction of what it did before.

The honest number

On large codebases, roughly 500 files or more, this can cut what a query costs by up to about 70 times. A graph traversal hands back a few thousand tokens of structured nodes instead of tens of thousands of tokens of raw source. On a small project the saving is real but much smaller. Bigger repo, bigger win. Do not expect the 70 times figure on a ten-file side project, and do not let anyone sell it to you as a flat per-query number. The repo is github.com/Graphify-Labs/graphify if you want to read the code before you install it.

The mistake that makes this fail is building the graph and then forgetting it exists. If you go back to opening files by hand out of habit, you paid the setup cost for nothing. Make the query commands your default move for "how does X work" and the savings show up on their own.

Leak two: what Claude writes

Left alone, Claude over-engineers. It reaches for speculative abstractions, scaffolding "for later," and fifty lines where one would do the job. Every one of those lines is an output token you paid for, and worse, it is code someone has to read and maintain later.

Ponytail is a free, open-source skill that installs a different instinct: ship the least code that actually solves the problem. Before it writes anything it climbs a short ladder. Does this need to exist at all? Is it already in the codebase? Does a standard library or a native feature already cover it? Can it be one line? It stops at the first rung that works.

Install it

Ponytail is a Claude Code plugin. Send these as two separate messages, not one line. This is the part people get wrong.

Copy this.

/plugin marketplace add DietrichGebert/ponytail

Copy this.

/plugin install ponytail@ponytail

Once it is in, it turns on automatically in every session. There is nothing to configure.

Dial the intensity

You control how hard it trims.

Copy this.

/ponytail lite     # gentle
/ponytail full     # default
/ponytail ultra    # most aggressive
/ponytail off      # disable for one task

Start on full. If you notice it stripping out something you actually wanted, drop to lite. The license is MIT, described by its author as "the shortest license that works," which tells you what kind of project it is. The repo is github.com/DietrichGebert/ponytail.

The honest number

Measured on real Claude Code sessions editing a real open-source repo, a FastAPI and React project, Ponytail produced about 54 percent less code on average. Call it half. In the worst over-building cases it cut up to 94 percent. On tokens the saving is more modest, around 20 percent cheaper and about 27 percent faster.

So be clear about what you are buying here. The token saving on this one is smaller than Graphify's. The real prize is the code you never have to read, review, or maintain. Half the output means half the surface area for bugs and half the review time. That is a business cost most people forget to count.

Leak three: what Claude remembers

This one costs nothing and is already sitting inside Claude Code. When a side task would flood your main chat with search results, logs, or file contents you will never look at again, hand it to a subagent instead.

A subagent runs in its own separate context window. It does the reading over there, out of sight, and returns only the answer. The raw material never enters your main session. Your main chat stays lean no matter how much digging happens underneath it, which keeps every follow-up request fast and cheap instead of slow and bloated.

The easy way: just ask for one

You do not configure anything. You tell Claude to delegate the reading.

Copy this.

Use a subagent to read every file under src/payments and
tell me only how a refund flows through the system.
Don't paste the code back. Just the summary.

Claude spins up the subagent, it reads in its own window, and you get the summary in your main chat. Claude Code also ships two built-in ones already doing this quietly: Explore, which is read-only search, and Plan, which does its research inside plan mode. Both keep exploration out of your main context by default.

The reusable way: save one

If you keep spawning the same kind of worker, save it once. Custom subagents are Markdown files in .claude/agents/ for a single project or ~/.claude/agents/ for all of them. Ask Claude to write the file for you.

Copy this.

Create a read-only subagent in .claude/agents/ called
codebase-explorer that searches and reads files and returns
only a concise summary. Give it Read, Grep, and Glob tools
and run it on Haiku.

Now any heavy read routes to a cheap, disposable worker that hands back just what you need. Putting it on a faster, cheaper model like Haiku stacks a second saving on top of the context one: you are paying less per token for the work you already moved out of the main window.

The honest number

In Anthropic's own walkthrough, a subagent read 6,100 tokens of files and returned a 420-token result. The roughly 5,700 tokens of file content that would have crowded the main window never entered it. Do that a dozen times across a working session and the difference in how your main chat behaves is not subtle.

What this does not fix

None of this makes Claude smarter. It makes it cheaper to run. If your prompts are vague or your project is a mess, these fixes will help you waste less money being confused, but they will not do the thinking for you.

Graphify does the heavy lifting on big codebases and almost nothing on tiny ones, so do not bother building a graph for a fifty-line script. Ponytail occasionally trims something you did want, which is exactly why it has a lite setting and an off switch. Subagents add a small amount of orchestration, so for a two-file read it is not worth the ceremony. Reach for each one where its leak is actually costing you, not everywhere out of principle.

And a word on the numbers. The 70 times figure is an up-to number for genuinely large repos, not a promise for your side project. Half the code is an average, not a guarantee on any single request. Treat them as the shape of the win, not a quote.

If you only change one thing this week

Start with Graphify if you work on a large codebase. That is where the biggest, most obvious money leaks out, and the setup is two commands and one graph build. If your projects are small, start with subagents instead, because they cost nothing and you already own them. Ponytail is the one to add third, once the other two are habit, because its payoff is measured more in maintenance saved than in tokens.

Then run all three and stop thinking about it. Reading, writing, remembering. Plug the leak in each and the burn quietly stops. If it takes you an afternoon and you hate it, you have lost an afternoon. If it works, your cheaper plan starts feeling like the expensive one every day you keep using it.

This guide is one system.
The map tells you which comes first.

The guides show you the systems. The map shows you which one your business needs first.

Get your free map →
Take this with you Grab the file version → Watch the original video ↗ Download as PDF ↓

Prefer to browse with company? The free community has the full skill library.