The bill was the product
A Claude plugin company came to AuditHQ with a plugin people already used. Installs were fine. Reviews were fine. What was not fine was the meter: every skill run pulled more context than the job needed, so teams paid in tokens and waited on turns that should have been short.
That is a product problem, not a billing-page problem. If a skill is slow and expensive, people stop invoking it. The plugin looks installed and acts unused.
What the audit put on the list
AuditHQ scored the published plugin the way an installer does: which skills load, what they cost when selected, and which ranked fixes would shrink that cost without rewriting how the plugin works.
The list was concrete. Heavy skill bodies. Context that loaded on every run. Fixes ordered by impact, with the file to change and what to leave alone — login, hooks, and the working procedure stayed out of scope.
What they shipped
They treated the AuditHQ findings as the backlog. No redesign. No new features. They shipped the context-cost fixes: keep each SKILL.md to the procedure, and load supporting files only when that run actually needs them.
The plugin still did the same jobs. It just stopped paying twice for context the user had already given.
40% fewer tokens. About 50% faster.
After those changes landed, the company measured skill runs again. Token spend on those runs dropped by 40%. Time-to-answer dropped by about 50%.
That is the catch: the same plugin, the same users, a cheaper and snappier turn. Context you never needed was the tax. Removing it is the growth.
Run the same pass on your plugin
Create a Claude plugin project in AuditHQ, run the audit, and open the ranked fixes. Context cost is on the scorecard for a reason — it is what your customers feel as wait time and what you feel as token spend.
Pro unlocks the full inventory and the copyable AI fix prompt built from that audit, so the next edit is the smallest change that pays, not a rewrite.