Show HN: Lowfat – pluggable CLI filter that saved 91.8% of my LLM tokens • Hacker News Board

Re: Show HN: Lowfat – pluggable CLI filter that saved 91.8% of my LLM tokens

#71

Post by jahala » Sat, Jun 06, 2026, 8:18 AM UTC

onlyrealcuzzo wrote: post #57

esafak wrote: post #53

Earlier quoted context omitted.

Did you benchmark the competition and can we see?

The problem even attempting to develop a tool for the frontier model space is that the cost to run a statistically significant benchmark is almost certainly going to be over $100 - for a single model. Unless something is like 25%+ more cost effective on Gemini for a task, I would not assume those savings are going to transfer to GPT. If you need to run a test this expensive and slow for every release, hobbiests aren'…

Yup, this is hitting it on the nose. But, despite the cost - the benchmark is the vital ingredient that cant be skipped. Otherwise, you don't know if what you're building is actually helping the agent rather than hindering it.

On the previous large benchmark run, i proved 40-50% cost reduction per correct answer.

I'm not sure why the vendors aren't using token filtering/compression more in their tooling, but perhaps they don't mind users feeding them more data and using more data.

Re: Show HN: Lowfat – pluggable CLI filter that saved 91.8% of my LLM tokens

#72

Post by KuhlMensch » Sat, Jun 06, 2026, 9:23 AM UTC

I'm glad this class of tool exists.

But it'll be a case of measuring first, then perhaps a staged integration of a tool like this.

Re: Show HN: Lowfat – pluggable CLI filter that saved 91.8% of my LLM tokens

#73

Post by songting591 » Sat, Jun 06, 2026, 9:31 AM UTC

[flagged]

Re: Show HN: Lowfat – pluggable CLI filter that saved 91.8% of my LLM tokens

#74

Post by winphoto » Sat, Jun 06, 2026, 9:51 AM UTC

[flagged]

Re: Show HN: Lowfat – pluggable CLI filter that saved 91.8% of my LLM tokens

#75

Post by smallerize » Sat, Jun 06, 2026, 10:13 AM UTC

onlyrealcuzzo wrote: post #58

hansvm wrote: post #55

Earlier quoted context omitted.

> otherwise, popular solutions would integrate the idea None of the major players are incentivized to care about this, especially not over other opportunities. Why would you expect them to integrate it? One of the biggest wins you can institute for your own codebase if you use agents is writing your own harness, by a huge margin. The defaults are fine, but you can do better.

> The defaults are fine, but you can do better. Why can I do better than Pi? I don't want to build my own harness and deal with the bugs... I want to build my project... My understanding is that Codex / Claude / Gemini subscriptions don't work with custom harnesses. It's pretty hard to beat 5x more usage if you have the $200/mo subscription by using the API instead.

If you're looking for an efficiency-focused harness, I had a pretty good time using the Dirac agent. The line-based anchors were slightly buggy though (this was a couple months ago) and would sometimes add the same line of code multiple times or leave an anchor in the output.

Re: Show HN: Lowfat – pluggable CLI filter that saved 91.8% of my LLM tokens

#76

Post by alex7o » Sat, Jun 06, 2026, 11:44 AM UTC

jahala wrote: post #70

esafak wrote: post #53

Earlier quoted context omitted.

Did you benchmark the competition and can we see?

No I don't have the funds to benchmark the competition, but would be happy to put the numbers up if any token whales feel like having a go. https://github.com/jahala/tilth/tree/main/benchmark

Oh that is a nice approach whish more benchmarks did cost per successful

Re: Show HN: Lowfat – pluggable CLI filter that saved 91.8% of my LLM tokens

#77

Post by poelzi » Sat, Jun 06, 2026, 12:51 PM UTC

onlyrealcuzzo wrote: post #34

alex7o wrote: post #5

I would like to have deeper comparison with alternatives like rtk, which are already fast and written in rust, also the previous comments mentioned something that has been a know problem with rtk that it sometimes strips the thing that the llm needs (or expects, causing more work to need to happan not less)

None of these tools measure how effective they are... It's a massive red flag to me when you could get decent data to see if your thing actually works, and they don't even attempt to... Have the LLM use your tool, run it on several of the coding benchmarks. If you're stingy, run it on the ones that don't cost much. Otherwise, I'm going to assume it doesn't actually work. If it did - Claude, Antigravity, Codex, Pi, or…

[dead]

Re: Show HN: Lowfat – pluggable CLI filter that saved 91.8% of my LLM tokens

#78

Post by zdkaster » Sat, Jun 06, 2026, 2:45 PM UTC

anoop4bhat wrote: post #66

Is this different from caveman?

Afaik, caveman does shorten sentences in coversation but lowfat is picking up what matter from cli ouput. That's a different output target.

Re: Show HN: Lowfat – pluggable CLI filter that saved 91.8% of my LLM tokens

#79

Post by pradeep1177 » Sat, Jun 06, 2026, 3:42 PM UTC

Wait, do the coding agents fire `kubectl get -o yaml`??? Most of the harness agents, like CC or codes, are very precise about command construction. For example, the harness add - o and look for the status, for example.

Re: Show HN: Lowfat – pluggable CLI filter that saved 91.8% of my LLM tokens

#80

Post by zdkaster » Sat, Jun 06, 2026, 4:54 PM UTC

alex7o wrote: post #5

I would like to have deeper comparison with alternatives like rtk, which are already fast and written in rust, also the previous comments mentioned something that has been a know problem with rtk that it sometimes strips the thing that the llm needs (or expects, causing more work to need to happan not less)

I have just put the comparison in the repo in case you want to checkout.