Yesterday a small, clever build shipped on r/PromptEngineering. It’s called Token Sift, and it lints your prompts for wasted tokens before you send a single call. Free, MIT licensed, and it runs fully offline. That means no API key, no account, and no prompt text leaving your machine, which matters if your prompts contain customer data or internal rules you’d rather not paste into a random web tool.
The twist: the author’s own test on a support-ticket prompt flagged 379 of 485 tokens as waste. That’s roughly 78% of the prompt doing nothing. Most of us never look at this because the prompt works, so we assume it’s fine. It works. It’s also expensive. Think about how a typical production prompt grows. Someone adds a rule after a bad output. Someone else pastes in a longer example. A third person restates the tone guidelines “just to be safe.” Nobody ever removes anything, so the prompt only gets heavier, and every single call carries that weight.
What it checks: 20 lint rules covering the usual suspects. Repeated instructions, over-verbose JSON, random UUIDs pasted inline, and dynamic content sitting in a spot that kills prompt caching. Here’s what each of those looks like in practice:
- Repeated instructions: “Always answer in JSON” in the system prompt, again in the examples, and again at the bottom. Say it once, clearly.
- Over-verbose JSON: pretty-printed objects with deep indentation, long key names, and null fields the model never needs. Whitespace and empty fields still get tokenized.
- Random UUIDs inline: a 36-character ID is a surprising number of tokens, and the model rarely needs the whole thing to do its job.
- Cache killers: this is the sneaky one. Put a timestamp or user name near the top of a prompt and the cached prefix breaks on every call. You pay full price each time and never notice, because nothing errors out. The bill just quietly runs higher than it should.
It also gives you a cost estimate per 1K calls. That number is what makes this useful. A wasted token on one call is nothing. Across a thousand calls a day, it’s a line item. If you run a support bot, a classifier, or any batch job that hits the same prompt over and over, multiply the savings by your real daily volume and the case for fixing it makes itself. It also gives you something concrete to show a teammate or a boss when you ask for an hour to clean up prompts.
Here’s the mini-workflow:
- 📦 Install it: npm i @yuhond/token-sift (CLI and JS library both ship in the same package, so you can try it from the terminal first and script it later)
- 🔍 Run it on your heaviest production prompt, not a toy example. The prompt that gets called the most, or the one with the most layered edits, will show the most waste.
- Read the per-1K-call cost estimate to see what the waste actually costs you, and write the number down before you change anything.
- ✂️ Fix the flagged lines, starting with caching-killers and repeated instructions, since those usually give the biggest savings for the least risk.
- 🔁 Re-run and compare the before and after token counts, then spot-check a handful of real outputs to confirm quality held up.
Pro tips
- Move anything dynamic (dates, user data, IDs) to the end of the prompt. Keep the static instructions up front so the cache prefix stays stable. A good rule: if the text changes between calls, it belongs below everything that doesn’t.
- Wire it into CI. Because it runs offline, it can fail a build when someone adds a bloated prompt, the same way a code linter catches sloppy code. Pair it with a token budget per prompt file and the waste stops creeping back in.
- Don’t blindly delete everything it flags. Some repetition is deliberate emphasis that keeps a model on track. Test the output quality after trimming, ideally against a small set of saved inputs you can replay before and after.
- Fix one category at a time. If you change caching placement, JSON format, and wording all at once, you won’t know which change moved the cost or broke the output.
- Keep the old version of the prompt in git. If a trimmed version behaves worse, you can diff the two and bring back only the line that mattered.
One honest caveat: the post has only a couple of upvotes so far, and a 78% waste figure comes from a single prompt the author chose. Your numbers will differ. A tightly written prompt might show 10% waste, while a prompt that has been patched for a year might show more than the author’s example. That’s the point of trying it on your own stuff.
The commenters had the right reaction. One said their prompts waste more tokens than their actual conversations. Probably true for a lot of us.
Grab it, run it on your worst prompt, and see what turns up. The author is asking people to report what it misses, so if you find a gap, tell them. A rule you wish existed is exactly the kind of feedback a young open-source project needs. Repo: github.com/yhdhappy/TokenSift. ⚓
I made a free linter that catches wasted tokens in prompts before you pay for them
by u/joyofish618 in PromptEngineering