5 ms·
Show HN: Lowfat – pluggable CLI filter that saved 91.8% of my LLM tokens
Hi HN, not sure if anyone would be interested, but just wanted to share that I've been maintaining my small tool called 'lowfat' that helps me filters some of my verbose CLI output. It's a single binary, works as an agent hook or a shell wrapper. It has a plugin system to customize filters per command.
The idea is pretty simple: agents don't need the full kubectl get -o yaml or any 10k-line dump to make decisions.
So that lowfat sits in between, strips the noise, and passes through what matters. Here's my real report after 2 months of personal use:
lowfat history --all
lowfat plugin candidates
─────────────────────────────────────────────────────────
# command runs avg raw cost savings source status
1 kubectl get 101x 14.4K 1.5M 93.9% plugin good
2 grep 103x 13.5K 1.4M 96.2% plugin good
3 git diff 81x 995 80.6K 57.9% built-in good
4 kubectl 90x 485 43.6K 33.6% plugin good
5 docker 127x 5.5K 693.6K 96.1% built-in good
6 ls 489x 117 57.3K 56.2% built-in good
7 find 30x 16.5K 495.0K 95.5% plugin good
8 git show 63x 490 30.9K 38.0% built-in good
9 git 177x 368 65.2K 76.1% built-in good
10 git log 86x 556 47.8K 78.5% built-in good
11 kubectl logs 5x 3.6K 17.8K 43.0% plugin good
12 git status 86x 152 13.1K 58.0% built-in good
13 docker ps 20x 467 9.3K 52.8% plugin good
14 kubectl describe 6x 656 3.9K 1.2% plugin weak
15 docker images 9x 940 8.5K 61.8% built-in good
16 k get 2x 2.1K 4.2K 35.9% plugin good
17 terraform 10x 395 3.9K 32.1% plugin good
18 git commit 32x 77 2.5K 0.0% built-in weak
19 docker build 8x 487 3.9K 37.6% built-in good
20 docker compose 22x 979 21.5K 89.4% built-in good
total: 4.4M raw → 4.1M saved (91.8%)
My toolset above is kind limited, but it works pretty well for my usecase without any interruption
Kinda help me not reaching the token limit for my company Bedrock limit usage and keep optimizing the saving on the go for later usage.
But, why not alternatives (https://github.com/zdk/lowfat#alternatives https://github.com/zdk/lowfat#alternatives) ?
The answers are:
- My goal is to make the core lightweight but extensible via plugins i.e. not trying to bundle every command in the installed binary so that people own their output filters.
- Customizable per usecase via plugin or filter pipelines as I am using my own toolset.
- Customizable for non-public CLI tools, for example, some enterprise might have their interal CLI tools that public won't have access.
- People should own their data. So the design is local-first, No telemetry forever.
- I kinda love UNIX-style composible pipes, so lowfat-filter has implemented this style.
- Be able to adjust aggressiveness of the filter, so we can control that we won't strip something the agent needed.
GitHub: https://github.com/zdk/lowfat https://github.com/zdk/lowfat
Anyway, if anyone is interested, feedbacks and questions are welcome!
Thanks!
- sikamikanikobg 4mo ago[flagged]
- Wenary 4mo ago[dead]
- devdoc83 4mo agoHow do you handle the risk of stripping out the exact stack trace the agent needed? That seems like the hard tradeoff here.
- itsthecourier 4mo agogonna ask the same... do far it's has been manually choosing what's useful in each command for the agents?
- zdkaster 4mo agoIt requires a bit effort in doing long-term adjustment and tuning for your agent common cli tools commands called. kinda need to evolve on day-to-day basis. But, agent itself can be useful to help tuning this.
- ramon156 4mo agoIn a perfect world the LLM needs to be very explicit on what it wants to read
- nixpulvis 4mo agoThe LLMs already do that themselves with `tail` all the time. There's a lot of room for improvement on top of that. Though they usually figure it out after a few tries. I often just paste manual runs errors myself anyway.
- zdkaster 4mo agoIt has the strip aggressiveness level suport. You can tune up 3 levels for each template output of your stacktrace using lowfat-filter dsl, shellscript or python.