Ponytail Is Asking the Right Question
For a few weeks now my feeds have been full of Ponytail, an open-source skill that tells a coding agent to think like the laziest senior developer in the room and write as little code as it can get away with. The pitch is clean and it lands: the best code is the code you never wrote.
The argument that grew up around it has settled into a single line. Simpler code means fewer tokens, and fewer tokens mean a smaller bill.
So I went and
read the benchmarks.
On a real FastAPI and React codebase (full-stack-fastapi-template, run with
Claude Haiku 4.5), Ponytail cut the generated code by 54%. The bill fell 20%.
| What changed | Ponytail vs. baseline |
|---|---|
| Lines of code | −54% |
| Tokens | −22% |
| Cost | −20% |
| Time | −27% |
Twelve feature tasks on that codebase. Generation shrank by half; the bill moved a fifth.
That gap is the whole story. Both numbers are real, and the distance between them is the thing almost nobody is talking about.
Does writing less code lower your AI bill?
The case for Ponytail is the obvious one. If the agent writes less code, fewer output tokens are spent, there is less to review, and there is less to maintain later. Cut the code, cut the cost.
The case against is just as reasonable. A modern coding agent — Claude Code, Codex, Cursor, Gemini CLI — spends very little of its budget writing. The tokens go somewhere else: reading source files, searching the repository, working out dependencies, reading test output, re-reading its own earlier edits. If generation is a small slice of the total, then trimming it can only move the total a little.
Both sides are right. The same benchmark shows the code shrinking by half while the bill barely follows.
They are standing at different distances
The supporters are looking at the task in front of them. The critics are looking at this month’s invoice. Neither one is looking at next month, or the month after that.
The cost of code isn’t writing it
Every file you create today becomes context tomorrow. So does every abstraction, and every layer you add to be safe.
Picture two versions of the same feature. One is a single file. The other comes with factories, registries, interfaces, a strategy or two, and a few helper layers for good measure. The extra code costs the AI about a minute to produce. But every future session now has to find those files, read them, understand what they are for, and decide whether they matter to the change at hand.
The generation cost is paid once. The comprehension cost is paid on every session that follows, more or less forever.
Why this bites harder now
We used to worry about complexity because it slowed people down. It still does. What is new is that it now slows the machine down too, and the machine bills by the token.
Recent research on agentic coding puts the ratio of input tokens to output tokens near 154 to 1 — almost everything you pay for is the model reading, not the model writing. I went through that work in a separate piece on where AI coding tokens actually go, so I won’t repeat it here. The short version is that understanding code has become more expensive than producing it, and not only for the human reading the diff.
Which quietly changes the question. It is no longer “how many tokens did the AI spend writing this?” It is “how many tokens will every future session spend understanding this?” Those are not the same question, and only one of them shows up on today’s bill.
What Ponytail gets right
Its real contribution was never the 20%. It is the reminder that complexity now carries a token cost, sitting right alongside the maintenance cost and the cognitive one we already knew about. A needless abstraction used to buy you a slower afternoon for whoever onboarded next. Now it also buys you input tokens on every agent run that has to read past it to get to the point.
It is worth saying that Ponytail does not chase the smallest possible code. Its own rule is to keep validation, error handling, security, and accessibility intact, and to cut only what the task never needed. The code comes out small because it is necessary, not because it was golfed. Whether the exact percentages hold across other repositories and other models is almost beside the point.
The better question
Write less code, by all means. It helps. It just helps less, and later, and in a different account than the benchmark headline suggests.
The spend you are trying to manage moves with how much context each session has to read, and that is the number that creeps up quietly as a codebase grows. It is also the number that is hardest to see, because it never appears as a line you wrote. CostCompass exists to read that spend back from each provider and put it in one running total you can watch and forecast where it’s heading — so an input-heavy stretch shows up while you can still do something about it.
Keep your bearings.