Our timeline was full of new plugins. We evaluated first and installed none.

Last week our timeline had one name on it: Ponytail, the plugin that makes your agent write code as short as a lazy senior dev. People shared the pretty numbers everywhere. Trending right alongside it: Headroom, a context compressor that gained tens of thousands of stars in a few weeks. We almost hit /plugin install on both. But we stopped and asked one question: is "it is popular" the same thing as "it fits us"?

By the end of the week we had installed neither on our main setup. Not because they are bad. Both are genuinely good. They just did not pass the test we run on every tool. This post is that test, plus the tools we already had that made adding more unnecessary.

Part 1Popular is not a buy signal

Whatever is trending was built for the median user, not for your workflow or your values. The more hype, the higher the pressure to install fast, and that is exactly the moment to slow down, not speed up. Hype is a signal to evaluate, not a signal to install. The difference is small but expensive, because every tool you add is not free. It takes room in your head, eats your context budget, and costs you debugging time when something breaks.

Part 2The test: blast radius times measurable pain

We do not judge a tool by how cool the feature is. We judge it on two axes: one, blast radius, how far it spreads if it breaks; two, measurable pain, is there a problem this tool actually solves right now that we can put a number on. Drop a tool onto those axes and the answer usually shows up on its own:

• Zero radius (free, does not touch the existing system): try it, nothing to lose.
• Narrow radius (a library wired into one spot you own the code for): make it an experiment, turn it on only when there is real pain.
• Whole-system radius (sits in the path everything flows through): send it back, the risk is not worth it.

There is a third axis: does it fight how you like to work. We build ahead. A tool that keeps pushing us to cut everything to the bone every single turn will keep braking that habit, no matter how short the code it writes.

Part 3Check the killer condition before you spend effort measuring

The Headroom test taught us the most. Headroom compresses tokens before they reach the model, to save on the API bill. We meant to measure real before/after on a job with a big context blob. But before measuring, we asked the one question that ends the whole plan:

The job we would put Headroom on, does it pay for the model per token, or as a flat subscription?

The answer was subscription, every job. The agent we run calls the model through a flat-quota path, not a per-token bill. Which means there is no per-token bill to compress in the first place. So we cut the entire measurement plan on one question that took under a minute to check.

The lesson: find the killer condition first and check it first. Do not spend effort measuring something that might get thrown out before you even start.

Part 4Two real examples, and what we already had

Ponytail fell on the redundancy-and-values axis. The tools for trimming code bloat, we already had in the kit, and we want you to see them in case you have them too:

• /simplify in Claude Code: reviews a diff and does the cutting for you, not just pointing at it.
• /code-review: covers both bloat and bugs in one command, a superset of /simplify.
• caveman: compresses the agent's words, a different axis from compressing code, stacks without overlap.

What Ponytail adds, a list of things for you to go cut yourself, overlaps with the /simplify we already have, and ours does the cutting for us on top of that. Add that it fights our build-ahead habit, and that it injects rules every turn, eating context budget the whole time. As for the "80-94% less code" number, that is Ponytail's own benchmark, not ours, and even if it holds, it does not answer a pain we do not have yet. Verdict: skip. But skip is not never. The day Ponytail does the cutting itself instead of handing us a list to go cut, and drops the every-turn rule injection, it earns a fresh look. Until then, what we already have covers the axis.

Headroom fell on the killer condition above, as a whole-system install. But it is not a bad tool. The day we have a job that genuinely pays per token, we will come back and try it as a scoped library, measuring before/after in that one spot, not putting a proxy in the path of the whole system. Verdict: not now, but the wake-up condition is written down.

Both verdicts came from the same criteria, not from the hype.

Where this lands

A test you can use right away when a new tool trends:

1. Ask first: "popular" or "fits us."
2. Put it on two axes: blast radius times measurable pain.
3. Find the killer condition and check it before spending effort.
4. Check whether the kit you already have covers that axis before adding a new one.
5. Write down what would flip the no: a condition or a date. A no with no trip-wire quietly hardens into a veto while the tools keep getting better.

Passes all five, then install. Does not pass, you still have what already works. The hype will keep coming. It is your criteria that should stay put.

Where to start: next time your finger moves to install, stop and ask question 1. That one is enough.