upvote
I should not trust their "vibe-coded productivity/token cost saving hacks" but I should trust yours?

    Save 30% token costs when using Claude Code, Codex, OpenCode for free - with open source, local semantic search. Works for small and large codebases and monorepos! Enterprise-ready and fully compliant via Ollama and SQLite-vec.
    Releases v0.0.42 Latest last month
Why should I trust that what you're peddling isn't snakeoil?
reply
I literally say you should take benchmarks with a grain of salt :)

> Of course, it's always dependent on statistical noise + host system load, and running sufficiently large benchmarks is simply too expensive, so take em with a grain of salt.

And the savings listed are coming from a benchmark harness that implements different OSS bugs one time with and one without lumen - in those cases the % saved are reproducible (caveat: it was on older models, Opus 4.6 I believe).

Also I explain WHY it saves tokens - because the model doesn’t have to brute force different terms until it finds the match it needs, but uses semantic „distance“ so the embedding does it for the model.

reply
[flagged]
reply
Only way to find out is to do some testing yourself i think.

I’m using less tokens with Lumen but I also use a bunch of other tokens hacks/skills; it’s hard to measure the impact exactly but it feels significant

reply
Half of what we see or consume is hype, so we should view everything with nuance. Sometimes truth lies in the middle.
reply
I just went through a lot of benchmarking and the only thing that seemed better than rg was chunkhound, which sounds similar to this project. Actually a small Jina embedding model actually did better than voyage AI, but took a long time to index. Also chunkhound doesn’t work well with worktrees. In the end, I decided to stick with rg.
reply
deleted
reply
A bit different but in the same domain GitNexus has been really good for me. Symbol based search and impact analysis. Once I added git hooks to auto index and added some explicit instructions it saved quite a bit for me. I have no affiliation just wanted to add that as some thing to try out.
reply
I'm in the process of evals for these tools after my org adopted them. My RTK findings are the same. It worsens task performance and overall you don't save money. I wanted to give the same treatment to other tools like ponytail and caveman (especially caveman, I mean there's no way that telling a computer to talk like a caveman is a valid engineering technique right?). To my horror, caveman is looking to be the only tool that actually doesn't regress on reasoning while taking costs down. But I still have a lot more evals to write, so this isn't conclusive or anything. (Also I haven't tried Lumen yet)
reply
I am actually rather fond of caveman. I haven't evaluated it for token cost, in part because frankly I think that part of the pitch is a load of malarkey. Output that's shown to the user is such a small percentage of overall tokens these days.

But anecdotally I do think it saves me quite a lot of time on reading LLM outputs. And that, if nothing else, is good for my sanity.

The caveman gimmick makes sense to me as a clever hack. Caveman talk is a longstanding meme that's presumably well-represented in the models' training data. So just asking it to do that is just an ultra-concise way to tell the LLM to be ultra-concise. Which, in turn, is theoretically good for accuracy because putting too many instructions in the prompt is bad for task performance.

reply
Similar for ponytail, I don’t know if it saves tokens, but there is less output to read (and usually less over engineering). Occasionally I have to push for more complex code, but that is much nicer than constantly asking for simpler code.
reply
That's also a good point. When I'm using caveman (and especially cavekit), I don't have to spend quite so much energy on dealing with it building features I didn't ask for and don't want.
reply
This sounds quite similar to dirac which made a stir a few months ago:

https://github.com/dirac-run/dirac

I spent way too long trying to reproduce the results in Pi and failing before I decided that I shouldn't trust author benchmarks for any of these tools. Then I found that I couldn't even close to reproduce their benchmark results using the exact model and their harness.

If any person other than the author has time to verify these Lumen benchmark results I'd be curious to hear it. I don't have the time to do it myself at the moment.

reply
I did the same with another project that does the same thing, called ck, and wasn't able to wring out any improved performance over just plain grep.
reply
Yes rg + python seems to beat far fancier tools.
reply
You use caveman to save on tokens, I use it to make the agent shut up. We are not the same =)

When caveman was released, token efficiency was a lot more relevant. But in the time I've actually come to like its matter-of-fact and short way of responding. There are other similar ones, but caveman is familiar.

reply
Isn't that what everyone was doing in the beginning of harnesses(cursor) and learned not to do for various reasons? https://news.ycombinator.com/item?id=43164253
reply
That’s a good example, I believe it could be similar case like with RAG. I didn’t hear for a while about any recommendations to use RAG.
reply
skills have a pretty straightforward token win - you remove the decision making from the agent so it does specific things in a row. at some point youre better off inverting control to a script that only occasionally calls the agent for a small decision
reply
How does lumen compare to semble?

https://github.com/MinishLab/semble

reply
Jetbrains IDEs are a perfect solution for this. They expose IDE actions (e.g, search, see occurrences, go to implementation) in their MCP server, which the harnesses can then call directly instead of figuring out the code themselves.
reply
You would think, except in their own testing they found no benefit. Some measures it was even worse on.

https://blog.jetbrains.com/ai/2026/05/what-happens-when-you-...

reply
I also found LSP like skills to usually have no advantage over rg. The agent needs to read the code to understand it; navigation is a small portion of that.
reply
> One of: Claude Code, Cursor, Codex, or OpenCode

What makes it incompatible with Pi, Zed or any other harness?

reply
Only the amount of free time I have to work on it - nothing fundamentally prevents it. PRs welcomed!
reply
TBF, what difference does it make when the very harnesses you're using these "hacks" in are themselves vibe-coded?
reply
Lumen is pretty cool, it's just local RAG, but it's a realistic approach at RAG. I would still keep tool-calling in some places though.
reply
How does this compare to ripgrep and fzf?
reply
> Whether it's caveman

the kinda guy who honestly thinks caveman.md reduces costs, actually adds it to his system prompt and is painstakingly reading the terse output

reply
So we replace all those "hacks" and snake-oil with even more pseudoscientific hacks and snake-oil?
reply
See my other comment on the person that commented the same thing you did!
reply
[flagged]
reply