Most conversations about AI cost management start with model selection. Which model do I use? When do I switch to something cheaper? That is a valid question, but it is not where the real money goes.
As AI coding agents became a daily driver, I started noticing a different problem entirely. The sheer volume of tokens flying around was making sessions slower, context windows fill up faster, and overall output noisier rather than sharper. The agent would write 400 lines when 40 would do. It would spend three paragraphs explaining a fix you could read from the diff. It would install a third-party date picker library when <input type="date"> exists in every browser.
Token cost and token consumption are two different problems. Most people optimize cost (which model?) but the bigger lever is consumption: how much the agent generates in the first place.
I found two plugins that tackle both sides of this.
The Problem Is Not the Model. It Is the Output.
In my previous post on Claude Code best practices, I talked about model selection: Opus for thinking, Sonnet for doing, Haiku for subagent grunt work. That guidance still holds. But model selection is table stakes.
The next level is shaping what the model generates. There are two distinct categories of token waste I run into all the time:
- Verbose explanations and filler in agent responses. The agent explains every step, summarises what it just did, adds caveats, writes paragraph-length commit messages, and generally communicates like it is being graded on word count.
- Over-engineered code. The agent installs libraries for things the platform already provides, writes wrapper components nobody asked for, adds "flexibility" for use cases that do not exist, and generates 300 lines where a senior dev would write 30.
These two problems have different root causes and need different fixes. Caveman fixes the first. Ponytail fixes the second.
Caveman: Teach Your Agent to Talk Less
Caveman is a Claude Code skill (and plugin for 30+ other agents) built around a single observation: the model's verbosity is a behaviour you can change with the right prompt, and that change survives across a session without losing technical accuracy.
The name says it all: "why use many token when few token do trick."
What It Actually Does
Once installed, Caveman instructs the agent to drop filler text, articles, pleasantries, and padding while keeping code, commands, errors, and technical content byte-for-byte exact. The agent shifts to a compressed communication mode that still makes complete sense, just without all the ceremony.
Normal agent (69 tokens):
The reason your React component is re-rendering is likely because you're creating a new object reference on each render cycle. When you pass an inline object as a prop, React's shallow comparison sees it as a different object every time, which triggers a re-render. I'd recommend using useMemo to memoize the object.Caveman agent (19 tokens):
New object ref each render. Inline object prop = new ref = re-render. Wrap in useMemo.Same fix. Same accuracy. 72% fewer tokens.
Benchmark Numbers
These are from the Caveman repository's own benchmark across 10 representative tasks:
Task Normal Caveman Saved
| Explain React re-render bug | 1,180 | 159 | 87% |
| Fix auth middleware token expiry | 704 | 121 | 83% |
| Set up PostgreSQL connection pool | 2,347 | 380 | 84% |
| Explain git rebase vs merge | 702 | 292 | 58% |
| Refactor callback to async/await | 387 | 301 | 22% |
| Architecture: microservices vs monolith | 446 | 310 | 30% |
| Review PR for security issues | 678 | 398 | 41% |
| Docker multi-stage build | 1,042 | 290 | 72% |
| Debug PostgreSQL race condition | 1,200 | 232 | 81% |
| Implement React error boundary | 3,454 | 456 | 87% |
| Average | 1,214 | 294 | 65% |
Honest caveat from the Caveman repo itself: Caveman only shrinks output tokens. Input tokens and reasoning tokens are untouched, and the skill itself adds roughly 1 to 1.5k input tokens per turn. So whole-session savings run smaller than the output number, and on already-terse workloads they can go net-negative. The real win is readability and speed. Cost savings are the bonus.
Intensity Levels
Caveman ships in four modes so you can dial in the right level for the task at hand:
/caveman lite— mild compression, still conversational/caveman full— the default, drops most filler/caveman ultra— maximum compression, pure signal/caveman off— back to normal
I use full for implementation sessions and lite when I am actively designing something and want the agent to walk me through its reasoning. One slash command switches modes instantly, no restart required.
Beyond Output: Caveman Proxy
The skill (free, MIT) handles output tokens. Caveman also ships a local proxy that tackles the input side. It compresses tool catalogs, log output, file contents, and search results before they reach the model. In a 54-run Claude Code benchmark this delivered 33.2% fewer provider-reported input tokens. That is a separate install and a bigger commitment, but worth knowing about if you are running heavy agentic workloads.
Installing Caveman for Claude Code
# Option 1: via the plugin marketplace
claude plugin marketplace add JuliusBrussee/caveman
claude plugin install caveman@caveman
# Option 2: one-liner script (MIT skill only)
curl -fsSL https://raw.githubusercontent.com/JuliusBrussee/caveman/v1.10.0/install.sh | bashAfter that, type /caveman to activate. The agent confirms the mode and switches immediately. No config file, no restart.
Ponytail: Make the Code Itself Smaller
Ponytail solves a different problem. Caveman makes the agent's words shorter. Ponytail makes the agent's code smaller.
The README description is perfect: "You know him. Long ponytail. Oval glasses. Has been at the company longer than the version control. You show him fifty lines; he looks at them, says nothing, and replaces them with one."
Ponytail puts that person inside your agent.
The Decision Ladder
Before writing any code, the agent stops and works through a decision ladder:
1. Does this need to exist? -> no: skip it (YAGNI)
2. Already in this codebase? -> reuse it, don't rewrite
3. Stdlib does it? -> use it
4. Native platform feature? -> use it
5. Installed dependency? -> use it
6. One line? -> one line
7. Only then: the minimum that worksThe first rung that holds wins. The agent stops there and does not keep going.
The Classic Example
You ask for a date picker. Without Ponytail, your agent installs flatpickr, writes a wrapper component, adds a stylesheet, and starts a discussion about timezones. The result: roughly 400 lines of new code, one more dependency, and a long context thread about UTC handling.
With Ponytail:
<!-- ponytail: browser has one -->
<input type="date">That is it. One line. Zero dependencies. The browser's native date picker has been available everywhere since 2015. Ponytail checked rung 4 (native platform feature) and stopped right there.
What the Numbers Say
The Ponytail team ran a proper agentic benchmark: headless Claude Code sessions editing a real FastAPI + React open-source repo, 12 feature tasks, the same agent with and without the skill (n=4, Haiku 4.5). Here is what they found:
Condition LOC Tokens Cost Time Safe
| ponytail | -54% | -22% | -20% | -27% | 100% |
| caveman (terse-prose control) | -20% | +7% | +3% | +2% | 100% |
| "YAGNI + one-liners" prompt | -33% | -14% | -21% | -30% | 95% |
Two things stand out. First: Ponytail is the only condition that cuts every single metric at once. Code volume, tokens, cost, and time all go down. Second: Caveman alone actually increased tokens slightly in this benchmark. That makes sense when you think about it. Caveman makes the agent's prose shorter but does not change how much code it generates. That is Ponytail's job. They solve different problems and work well together.
Lazy, Not Negligent
The thing I appreciate most about Ponytail is what it does not cut. The ladder never touches validation, error handling, security, or accessibility. A raw "write the minimum" prompt tends to drop safety guards along with everything else. The benchmark shows the bare "YAGNI + one-liners" prompt scored 95% on safety, not 100%. Ponytail kept 100% because the rules are explicit: be lazy about the solution, never about correctness.
Modes and Commands
/ponytail— activates full mode/ponytail lite— a gentle YAGNI nudge/ponytail ultra— for when the codebase has genuinely wronged you/ponytail-review— scans existing code for over-engineering candidates/ponytail-audit— whole-repo scan for bloat/ponytail-debt— lists every deferred shortcut the skill tagged withponytail:
Installing Ponytail for Claude Code
/plugin marketplace add DietrichGebert/ponytail
/plugin install ponytail@ponytail(Send as two separate prompts. The marketplace add needs to complete before the install runs.)
Using Them Together: My Personal Setup
Both plugins are always on in my Claude Code sessions. Ponytail runs as a lifecycle hook that fires on every prompt. Caveman I keep in full mode by default. A typical session looks like this now:
- Planning phase. I switch to
/caveman liteso the agent still explains its reasoning but skips the paragraphs of preamble. Ponytail does not change planning behaviour, it only kicks in when code gets written. - Implementation. Both plugins are fully active. The agent writes minimal code thanks to Ponytail and confirms briefly rather than narrating every step thanks to Caveman. The context window stays clean dramatically longer.
- Review and refactor. I run
/ponytail-reviewon newly written code. It surfaces over-engineering candidates in one-line findings. No noise, just: file, what to cut, what replaces it.
Practical note for SAP developers: SAP is introducing token limits, so consumption discipline is no longer just a cost concern, it is becoming a hard constraint. On top of that, bloated context windows mean slower responses and the model starts dropping earlier context as the window fills up. Running both plugins keeps the context lean and the agent sharp throughout a long session. That matters a lot when you are doing multi-step agentic work across a large codebase.
Why This Matters More Than Model Selection
My earlier blog post focused heavily on picking the right model. That guidance is still valid. But here is the uncomfortable truth I have arrived at after months of daily agent use: model selection is a 2x to 3x lever. Output discipline is a 5x to 10x lever.
A Haiku session with both plugins active will often produce better results than a Sonnet session without them. The context is cleaner, the code is leaner, and the agent is not fighting its own verbosity. You are not paying for filler. You are paying for work.
What you already know What this post adds
| Use Opus for planning, Sonnet for execution, Haiku for subagents | Install Caveman to cut output token verbosity (avg. 65% on explanations) |
| Plan before coding, verify before claiming done | Install Ponytail to reduce generated code volume (avg. 54% fewer LOC, 22% fewer tokens) |
| Keep sessions focused, do not let context bloat | Both plugins together keep the context window clean and extend effective session length |
Quick Reference
Plugin Problem it solves Primary saving Install
| Caveman | Agent responses too verbose | ~65% output tokens (explanations) | claude plugin marketplace add JuliusBrussee/caveman |
| Ponytail | Agent generates too much code | ~54% LOC, ~22% total tokens, ~20% cost | /plugin marketplace add DietrichGebert/ponytail |
Both are MIT-licensed, open-source, and install in under a minute. Neither requires an account, a backend, or changes to your project files. They are skills that ride in the context window and change the agent's behaviour through prompt engineering.
If you are spending serious time with AI coding agents and you are not running both of these, you are paying for words and lines that are not helping you. Fix that.
Install the plugins, run a few sessions, and see for yourself.
Bluesky
