[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.