Your AI agent is eating your tokens. Two tools that finally put it on a diet.

Last month I did something nobody should have to do: I added up my own token spend. Then I sat there for a while, staring at the number, thinking about the fact that a meaningful chunk of it went toward my agent reading the same eleven files for the fourth time this week.

Because that is the deal nobody mentions when you start vibe-coding. The agent does not remember your project between chats. So every session, you — or your startup script — re-feed it the same context: the schema, the conventions, the file that holds the auth logic, the two tables that must never drift apart. And the agent, being an eager intern with infinite stamina, reads all of it, writes all of it down, and then writes more code on top.

This post is about the two tools that changed the math for me: vexp.dev and ponytail.dev. One attacks the input side (what the agent reads), the other the output side (what the agent writes). Together they are the closest thing vibe-coding has to a diet plan.

Why agents write spaghetti in the first place

It is not because the model is bad. It is because the model is blind.

Your agent cannot see your codebase. It can only see what you hand it. So when it needs to know whether a function already exists, it does one of three things: it asks you (you are now a human context engine, congratulations), it greps the repo (more tokens, hit or miss), or it does the thing that feels productive and actually creates your future problems — it writes it again, slightly differently, in a different file, with a slightly different name.

That is how you get two schema sources. That is how you get a helper function that exists three times under three names. That is how spaghetti happens in the AI era — not because anyone decided to write spaghetti, but because every session starts from amnesia, and amnesia breeds duplication.

Tool one: vexp — feed the agent less

vexp calls itself a context engine, which sounds like marketing until you see what it actually does: it parses your project into a dependency graph (from the AST, not from guessing), and when your agent asks for context, it hands over exactly the code that matters for the task — not the folder, not the whole file tree, the slice.

The pitch that got me: one call instead of twenty. Instead of your agent burning twenty tool-calls exploring the repo, it gets one context capsule that already knows the blast radius. vexp's own claim is a 65–70% token reduction — and like every vendor number you should treat it as a ceiling, not a promise. But even at half that, the economics change.

Two things make it stand out for the indie crowd:

• It is local-first. The graph lives on your machine, zero network calls for the indexing. Your code never leaves your laptop. For anyone building on a machine they do not fully trust (hi), this matters.
• It has session memory. Their vibe-coder page says it plainly: stop re-explaining your app every chat. Memory anchored to the code graph survives restarts, breaks, and that three-day gap where you forgot which project you were even building.

It plugs into twelve agents — Claude Code, Cursor, Windsurf, Copilot and friends — via MCP, so you are not changing your editor, just adding a smarter context source underneath it.

Tool two: ponytail — the laziest senior dev in the room

Ponytail (open source, MIT) attacks the other side of the bill: it makes your agent write the least code that works. Before adding anything, it asks three questions a good senior dev asks and an eager agent never does: is this change actually needed? does it already exist? can the stdlib or a native API do it?

The famous example, which made the rounds on Hacker News: a vibe-coded project reached for a third-party date-picker library, a whole dependency, config, and bundle weight — for what a native <input type="date"> already does for free in every modern browser. Ponytail's rule is blunt: the best code is the code you never wrote. Every line you do not write is a line you never debug, never patch, never explain to your agent again next session.

But the real upgrade in v5 is /ponytail-review. It stopped being just a code-trimmer: now it reviews like the senior dev who gets paged when things break — it reads the code your change touches, not just the diff, and checks bugs, security, real load, missing tests, and what to cut.

What happened when I ran it on my own code

I write this blog on a Frankenstack codebase, and I had already shipped the feature I was proud of: a sync engine pushing my project data to a database. Then I ran a ponytail-style review on it — reading the code the change touches, not just the diff.

It found two things the tests missed, the build missed, and — most humbling — I missed:

1. The sync endpoint was writing SQL that referenced columns which did not exist in the database. The insert failed with a 500. And the client code caught that error and swallowed it silently — so my data was not syncing, and nothing anywhere told me. A silent failure wearing a green checkmark.
2. A metrics_cache table was used by four different endpoints — and had never been created anywhere. The code that reads it worked only as long as nothing wrote to it.

This is the part vendors will not tell you: your agent does not get dumber at 2 a.m., and it does not get dumber on Mondays. But you do. The review step is cheap insurance against the most expensive kind of bug — the kind that ships green.

The combined diet: feed less, write less

Here is the part I did not expect: the two tools are not redundant, they are complementary halves of one budget line.

That compounding effect is the actual point. Every line you do not write is a line that never enters your dependency graph, never gets re-read next session, never gets re-explained to a model that charges per token. The cheapest context is the one that does not exist.

The cheap habits, if you install nothing

Fine, no new tools. Then at least steal the habits — they cost zero:

1. Delete before adding. Before any new file, ask the agent: does something like this already exist? Half the time, it does — the agent just could not see it.
2. Prefer the platform. Native browser APIs, stdlib functions, built-ins before libraries. The date-picker rule applies to far more than date pickers.
3. Never paste whole files as context. Paste the function. Paste the interface. The agent does not need your 400-line component to add a button.
4. Let the agent ask before it acts. A prompt like: before writing, list the files you need. It will usually come back with three, not thirty.
5. Fail loudly, not silently. A caught error must surface somewhere — a toast, a log, anything. My swallowed 500 cost me weeks of thinking the feature worked.
6. Review like a senior dev, not like a user. Read what the change touches, not just what it adds. That is where the bugs live.

The punchline of the vibe-coding era is not that agents write bad code. It is that they write unattended code — and unattended code drifts toward duplication, over-abstraction, and silent failure, because nobody with context was watching. You do not need to stop using agents. You need to give them a smaller plate and a lazier conscience.

Feed less. Write less. And for everything above, keep a cockpit that shows you the truth.