Midway through researching this article, I was asked what the frontend-design plugin on my machine was for. I had no answer. Not a vague one, none. It had been installed since 3 April, it was one of exactly two plugins I had, and I could not name a single task it had ever helped with.
claude plugin uninstall frontend-design@claude-plugins-officialThirty seconds, including reading the confirmation. One plugin left. The manifest and the enabledPlugins block in my settings are clean. A stale cached copy remains on disk, but Claude Code no longer loads it.
Nothing broke. If I need it later, I can reinstall it. That is the whole point of the rule I want to describe. I try a lot of tools, and I have to: by my own count of the official MCP registry, about 384 new servers appeared every day over the first twenty days of September. The only way to sample a supply like that is to make leaving cheap.
TLDR
- I delete a tool if it hasn’t explained itself or produced one useful result within 25 minutes of install. A cheap exit is what lets me try a lot of tools.
- 25 is throughput arithmetic, not a focus interval. The clock starts at install, so setup competes for the same 25 minutes. An hour buys me two tools.
- The 25 minutes is a first gate, not a lifetime verdict. Understanding the tool or getting one useful result earns an explicit trial. No result, or no clear verdict, means delete.
The trial that never ends
Here is the failure the rule prevents, stated as system behaviour rather than as a character flaw. A trial with no defined end is an open-ended commitment. Open-ended commitments get priced high. Things priced high get started less often. So the rational response to “I should try that sometime” is to never try it, because sometime has no end and you already know it.
That was fine when the supply was small. It isn’t small. My own census on 20 September, using full pagination of the registry API and deduplicating by server name, came back with 33,660 servers. Over the first twenty days of September, new servers appeared at about 384 a day, or one every four minutes. The registry publishes no total, so those are my counts, not published statistics.
Against a curve like that, sampling less is not prudence. It is the expensive mistake.
Where 25 came from
It isn’t Pomodoro and I didn’t borrow it. I thought about how long it takes to learn what a thing does and whether it helps on my own projects, and landed here: half an hour already feels like a lot, an hour is far too much and not worth it, and at 25 minutes an hour buys me two tools.
That last line is the rule. The number is a throughput figure, not a focus interval, and it has nothing to do with attention span. The thesis sits inside the arithmetic before I make any argument for it.
Pomodoro is the near neighbour and not the same thing: a pomodoro is an interval you return from; this is an exit you don’t. In both cases the number is convention rather than science. Cirillo’s own site says the 25-minute timer sessions “aren’t the technique.”
What changed in my workflow
| Before the rule | After | |
|---|---|---|
| Deciding to try something new | Open-ended: “when I have time,” which never arrives | A booked 25 minutes, one sitting |
| What a trial costs | Unknown, so priced as large | Fixed and known before it starts |
| When the clock starts | At the first real task; setup “didn’t count” | At install; setup competes for the same 25 minutes |
| A complicated install | A hurdle to push through | A data point, and a big minus |
| Verdict at the end | Park it; might be useful later | Delete it, or keep it explicitly on trial |
| What “keep” means | Permanent and silent | A trial, not a marriage; commitment is a separate, later decision |
| Where trials live | In my head | tools-under-test.md: a status and one open question per tool |
| Cost of keeping a tool | Invisible | Printable: claude plugin details |
| Research before the trial | Me, reading docs and pricing pages | An agent verifies the facts; I still judge the real output |
| Throughput | A few tools, whenever | An hour buys two |
The recurring cost is now printable
The question the rule needs answered fast is “what is this costing me to keep?” Until recently that question had no answer. It does now:
claude plugin details superpowers@claude-plugins-officialReal output from this machine on 20 September, trimmed to the rows that matter:
$ claude plugin details superpowers@claude-plugins-official
superpowers 6.3.0
Component inventory
Skills (14)
Hooks (1) SessionStart (harness-only; no model context cost)
Projected token cost
Always-on: ~465 tok added to every session
On-invoke cost is paid each time a skill or agent fires.
Token counts are estimates and may differ from actual usage.Superpowers costs me ~465 tokens on every session I start, whether or not one of its 14 skills fires. frontend-design reported ~54 always-on and ~2k on invoke before I uninstalled it. The command refuses a plugin that is no longer installed, so capture the figure before you delete if you want it for your notes.
The mechanism is simple. For every installed skill, Claude Code loads its name and description into the system prompt at startup. The body loads only when the skill fires. plugin details estimates those two costs separately as always-on and on-invoke.
Let me be precise about what the number does and doesn’t say. ~465 tokens is small. It is not a budget crisis, and the command itself says the estimates may differ from actual usage. It also prices plugins and skills, not every part of the system. The change is in what is knowable: the recurring price of “might be useful” can now be checked instead of assumed.
The clock starts at install
This is the strongest opinion I hold about the rule, and the one people push back on. Setup gets no grace period. If a tool spends fifteen of its 25 minutes on credentials, config files and a dashboard signup, that is not lost evaluation time. That is the evaluation, and it is a big minus.
A complicated install is not a hurdle before you get to judge the tool. It is the tool telling you what working with it will be like.
It is also why the rule works as a fast filter rather than a careful one. Most tools that fail, fail on setup, early and visibly. You rarely need the full 25 minutes. The rule isn’t measuring usefulness. It is measuring usefulness per unit of friction, and five minutes usually answers that.
A trial, not a marriage
At minute 25 there are two outcomes, not three. If the tool has explained itself or produced one useful result, it passes the first gate and enters an explicit trial. If it has not, I delete it. “Park it and see” is not an outcome, and anything undecided defaults to out.
Keeping means on trial, and that distinction is what makes the 25 minutes cheap to spend. RTK is the clearest case I have: configured 1 June, written into my permanent global instructions on 7 August, two months later. My ~/.claude/CLAUDE.md is eight bytes long and contains nothing but @RTK.md, which is a fairly exact picture of what “earned its place” looks like here.
The register is newer than the rule. tools-under-test.md was created on 12 September, eight days before I wrote this, with a status field and one open question per tool that passed the first gate. Before that the rule lived only in my head. I won’t claim results for a file that is eight days old, but writing trials down is what lets intake stay high without turning every pass into a permanent commitment.
What a tool that passed looks like
In July I published a piece about a background hook that cut my token bill 65%. Three and a half months later, rtk gain reports 58,177 commands and 345.8M tokens removed from command output.
One correction while I’m here: 85.7% is bash output reduction, not bill reduction. RTK’s own README is explicit that those are not the same thing, and I repeated the stronger reading without checking. The reason it belongs here is that RTK was once just another repo with 25 minutes to prove itself. A high intake occasionally finds something that compounds.
Letting an agent spend part of the 25 minutes
An agent can make the research part cheaper, but it cannot make the verdict for me. Here is a real verification prompt I used while producing the research for this article:
Today's date is 2026-09-20. Get accurate, verifiable, current facts about five
tools. For EACH, I need (a) the canonical official URL, (b) ONE accurate sentence
describing what it actually does, (c) the pricing facts named below, verified on
the official pricing page, (d) the date you observed the page.
RULES: only report what you actually read on a page; give exact URLs; quote
pricing exactly, do not round; if something cannot be verified say "not verified"
rather than guessing.That last clause is the load-bearing one. In about a hundred seconds it corrected three beliefs I was carrying. Tailscale’s free plan caps users, not devices; I had the shape of the limit wrong. My worry about Firecrawl credit costs was not supported by the published numbers as I had stated it. The savings figure in my own published article describes output reduction, not bill reduction, as RTK’s README says plainly.
That saves time inside the 25 minutes. The actual pass still requires the tool to explain itself or produce one useful result on a real task. Research can be delegated; the criterion cannot.
What this costs
False negatives, deliberately. A tool with a genuine learning curve that only pays off in hour three fails at minute 25 and gets deleted. The rule trades recall for throughput on purpose, and I’d rather say that plainly than pretend the filter is accurate.
It rewards onboarding, which correlates with quality but isn’t the same thing. A strong tool with a bad README loses to a weaker one with a good quickstart. That is a real bias, not a hidden one.
Paid trials distort it. Anysite.io has no permanently free tier. “Start for free” is a 7-day trial. When starting the clock also starts a billing clock, 25 minutes is no longer the dominant cost, and the rule needs adjusting rather than applying.
Don’t use this when the tool isn’t optional: a client’s stack, a compliance requirement, infrastructure you already committed to. And don’t let the printed token number decide. It is support for the argument, not the argument.
FAQ
Why 25 minutes and not 30, or an hour?
It isn’t Pomodoro and it isn’t borrowed. Half an hour already feels like a lot, an hour is far too much, and at 25 minutes an hour buys two tools. It’s a throughput number.
One sitting, or cumulative across attempts?
One sitting. A tool gets one clean 25-minute run and then a verdict. Three ten-minute attempts is not a trial, it’s indecision.
What if I delete something that would have been good?
That happens, and the rule accepts it. It trades accuracy for throughput deliberately. Deleting is not banning. Nothing stops you reinstalling it the day a real task needs it.
Is a few hundred tokens per session really worth deleting over?
No, and I won’t pretend otherwise. ~465 tokens is not a budget problem. What changed is that the price of keeping something recurs and is now printable, so “might be useful someday” can be checked instead of assumed.
What happens if I’m still undecided at minute 25?
I delete it. The register is for tools that produced enough value to pass the first gate but have not yet earned a permanent place. The default for anything undecided is out.
Can an agent run the trial for me?
It can verify documentation, pricing and claims, which leaves more of the 25 minutes for the real test. I still want one useful result from my own task before the tool passes.
My rule
25 minutes, one sitting, clock starts at install. If a tool hasn’t explained itself or produced one useful result by then, I delete it so the next one can be tried without hesitation.
If it passes, it earns a trial, not a permanent place. The rule looks like a way to say no. In practice, it is how I keep saying yes.