Still learning myself, but I've seen MCP tools just lightly wrap upstream json-body REST APIs. Works. But not only is the json structure more tokens but often the model just needs a small subset of fields in the payload.
Show HN: Lowfat – pluggable CLI filter that saved 91.8% of my LLM tokens
21–30 of 97 posts
Re: Show HN: Lowfat – pluggable CLI filter that saved 91.8% of my LLM tokens
#22Re: Show HN: Lowfat – pluggable CLI filter that saved 91.8% of my LLM tokens
#23Still learning myself, but I've seen MCP tools just lightly wrap upstream json-body REST APIs. Works. But not only is the json structure more tokens but often the model just needs a small subset of fields in the payload.
To be safe if you need a full json, would make conditonal passthrough as the original raw output. Or, need to handle selective object using python via the filter plugin.
Re: Show HN: Lowfat – pluggable CLI filter that saved 91.8% of my LLM tokens
#24I've tried rtx and lean-ctx and these tools seem to end up confusing the agent more than helping. Any saving is irrelevant if the agent decides to work around the tool and makes even more calls than it would otherwise. I don't know about cost saving, but if it's keeping the context size down I've had a lot better results using subagents to keep a higher order conversation clean for longer.
I looked into lean-ctx and decided not to use it. It has a very specific use case, and it's good when your interaction with the repository is read-only. When you want to edit, then the model has to read the whole file anyway. It's a cool tool, but it has a very narrow use case where it delivers the performance it claims.
Re: Show HN: Lowfat – pluggable CLI filter that saved 91.8% of my LLM tokens
#25This is a nice little project but I’m weary of sensationally inaccurate titles for stuff like this and the infamous caveman mode. It doesn’t save 91% of tokens: it reduced in one user case 91% of output tokens on the raw CLI output. I am being pedantic about this because these sorts of claims go viral and are inaccurate.
A proper benchmark will compare a large sample of identical prompting with and without the tool, against a specific harness. Once you apply Amdahl’s law, there is no way this saves 91% of tokens holistically, which the title implies.
I work in a non-tech company and these sorts of things keep going viral, with no understanding and with no comprehension of what is actually going on. Engineering is gone and cargo cult magical incantations are in.
Re: Show HN: Lowfat – pluggable CLI filter that saved 91.8% of my LLM tokens
#26Re: Show HN: Lowfat – pluggable CLI filter that saved 91.8% of my LLM tokens
#27[deleted]
Re: Show HN: Lowfat – pluggable CLI filter that saved 91.8% of my LLM tokens
#28the bigger problem is agents defaulting to the broadest command possible. kubectl get -o yaml when a jsonpath query would give 1/50th the tokens. filtering after the fact works, but you're still paying for the round trip. better to teach the agent to ask narrow questions in the first place.
Re: Show HN: Lowfat – pluggable CLI filter that saved 91.8% of my LLM tokens
#29the bigger problem is agents defaulting to the broadest command possible. kubectl get -o yaml when a jsonpath query would give 1/50th the tokens. filtering after the fact works, but you're still paying for the round trip. better to teach the agent to ask narrow questions in the first place.
Hooks are great for this.
Re: Show HN: Lowfat – pluggable CLI filter that saved 91.8% of my LLM tokens
#30I 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)
Yeah I use rtk and would love to see a comparison.