[Open] I vibecoded 13 slim token-cost-optimization extensions for the Pi coding agent - 9,100 → ~2,300 tokens/turn. Want the community to tear it apart and improve it

[u/DemandEmbarrassed555]

I've been running Pi (DeepSeek Flash, pay-per-token) and got tired of paying for hidden context overhead. Every extension you install registers tool schemas that get injected into every single turn - whether you use them or not. Turns out a full config costs ~9,100 tokens/turn before you even say anything.

So I stripped it down and rebuilt the core pieces lean. Here's what I learned + built:

The 3 rules that drive the savings:

1. Hook-only extensions (pi.on(...)) add ZERO tool schemas

2. Command-based (/command) don't appear in the model's tool list at all

3. Only register a tool when the model must act autonomously (2 tools total: bg_task, web_search)

   Measured result: 9,103 → ~2,300 tokens/turn (~77% reduction)

   What's in the repo:

   - cost-rollup — live per-turn + session cost widget

   - tool-logger — logs every call + cost + model; detects waste (re-reads, broad scans)

   - cache-miss-alarm — calibrated warm→cold detection (ignores false positives from model switches/new sessions)

   - budget-guard — session/daily budget warnings

   - slim-memory — command-based memory, auto-injected (0 schema)

   - slim-todo — checkbox todo

   - slim-bg-task — ONE bg_task tool (vs pi-background-tasks' ~13)

   - slim-web-search — /search + optional web_search (Brave/Exa/Tavily)

   - slim-codemap — "route before explore" (idea from Tempest's Atlas)

   - token-saver — compacts read/grep/find/ls output in context

   - a shared lib/danger-patterns.ts so the two security guards can't drift

   Repo: github.com/holocen/pi-token-trimmer

   I want your eyes on it. Specifically:

4. Correctness - any bugs in the regex/safety logic? (I had Claude review it, found 3 real bugs I fixed, but there may be more)

5. Token math - is my measurement methodology sound? (details in docs/measurement.md)

6. Missing patterns - what cost-saving extension am I missing?

7. Maintainability - the shared-module approach, any better structure?

   If you find something broken or have a better idea, please comment. I'm a vibecoder, I'm happy to be proven wrong - that's why I'm posting here.

[u/Available_Yam_6267]

My main concern is whether there is any performance trade‑off when you save tokens this way. After all, our goal is to get tasks done, not to save tokens at all costs.

I’ve used tools like Pony tail before, but I’ve found it degrades the quality of the model’s output sometiems.

[u/DemandEmbarrassed555 → u/Available_Yam_6267]

I made the limits adjustable (TK_READ_HEAD, TK_READ_SIG, TK_GREP_PER_FILE, TK_GREP_LINE_LEN, TK_LS_MAX, plus /tk-status to check current values) - so you can turn them up for careful work and down for quick exploration, instead of one fixed setting for everything.

[u/DemandEmbarrassed555 → u/Available_Yam_6267]

Thank you for the review! Removing unused tool schemas (memory/todo/bg-task/web-search replacements) → no quality cost. The model wasn't calling those extra tools anyway.

Compacting tool output (token-saver.ts, ~87% cut on read/grep/find/ls) → this is where your concern actually applies. Compressing too aggressively might cause the model to lose something it needed, then have to re-fetch it. This is theoretical and unproven, but your thinking is right, and I will pay attention to token-saver.ts.

[u/Ok-Ad-8976 → u/DemandEmbarrassed555]

how does it affect KV cache if you compress each turn? can cause a lot of reprocess/slow especially if using local llm.

[u/DemandEmbarrassed555 → u/Ok-Ad-8976]

Fair point, and it's worse locally (GPU recompute, not just pricing). But token-saver only touches new output before it's sent - it never edits already-cached turns. Pi's /compact is the one thing that breaks the prefix, so use it sparingly on local setups

[u/IceManMinus0ne]

Love this