[deleted]
RTK reports token savings, but our cost benchmarks disagree
31–40 of 85 posts
Re: RTK reports token savings, but our cost benchmarks disagree
#32The technique looked dubious from the start, because LLMs were trained to expect certain outputs from common bash tools. If the output is not what it expects, an LLM may issue more tool calls than before, because it will assume the tool is broken, the arguments passed to it were wrong, or it's a newer/older version of the tool etc => more tokens. Sounds like just adding to the prompt to use `grep` and `tail` extensively will do the trick without any special tooling.
Re: RTK reports token savings, but our cost benchmarks disagree
#33All of these "hacks" are snakeoil and I think deep down we all know. Whether it's caveman, RTK, or whatever other vibe-coded productivity/token cost saving hacks/skills/claude.md. What I had success with (although benchmarks are older) is to index the codebase with a dedicated local code embedding model. It's a bit expensive on the CPU side but in my benchmarks it reduced token use and wall clock time significantly.…
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 snake…
[dead]
Re: RTK reports token savings, but our cost benchmarks disagree
#34We have been working in this space for the past year. Based on our experience, I no longer trust any claims unless they are backed by benchmark results (yes, benchmarks are painful to run reliably and expensive). It is possible to reduce token usage. It’s just much harder than the basic approach.
One quick win is to just avoid wasteful tokens, for example run all the QA tools like the unit tests in --quiet mode, which only prints warnings/failures.
Re: RTK reports token savings, but our cost benchmarks disagree
#35Glad to see that more and more people realize these are just snake oils. Without objective metrics like benchmarks, none of the claims mean anything.
That's also how I feel about skills/plugins. While some provide important context for specific projects/environments, I am very skeptical about (over)generalized skills like "writing JS tests" or "creating a spec". There are dozens of these skills internally at my company, but I haven't seen a single benchmark that shows any of those are better than just plain, single sentence prompts in a meaningful way (aka statistically significant).
Re: RTK reports token savings, but our cost benchmarks disagree
#36I wrote article about it couple months ago that I didn't believe it works. Nice to see numbers now
https://mroczek.dev/articles/the-token-compression-illusion-...
Re: RTK reports token savings, but our cost benchmarks disagree
#37Glad to see that more and more people realize these are just snake oils. Without objective metrics like benchmarks, none of the claims mean anything. That's also how I feel about skills/plugins. While some provide important context for specific projects/environments, I am very skeptical about (over)generalized skills like "writing JS tests" or "creating a spec". There are dozens of these skills internally at my compa…
I see the same thing and have effectively the same philosophy. If I'm using something like figma or glean or playwright/chrome dev tools, plugin/skill/mcp - likely very useful.
But so many of the weird collections of skills that people on YouTube get viral followings for - I just don't get it.
People excitedly ask me what skills I use and I feel bad just saying only things we've directly authored for some express purpose. None of the "hot" ones.
I've written a large handful of skills, but they aren't like vim plugins. I don't just leave them "on".
This has been my experience at least- curious if I'm just behind the times.
I also effectively didn't leave the IDE+ChatGPT copy/paste workflow until the first release of Claude code. So maybe I'm slow to adopt.
Re: RTK reports token savings, but our cost benchmarks disagree
#38i don't know if such hacks works, but in C# if you use roslyn mcp, you save a lot.
Much earlier, I tried to set up some static analysis tools so that the coding agent would have access to dataflow analysis etc. tools instead of just grep for typed python. If there were benefits, they weren't easily apparent :(
Re: RTK reports token savings, but our cost benchmarks disagree
#39If you are using maven you should tell your agent to use its quiet mode or rtk, because mvn love to write a lot of useless output.
I believe RTK would work well in that use case.
Sometimes creating less verbose variants yourself (a simple script, build.sh, with pointers to logs) can be a quick win.
Re: RTK reports token savings, but our cost benchmarks disagree
#40All of these "hacks" are snakeoil and I think deep down we all know. Whether it's caveman, RTK, or whatever other vibe-coded productivity/token cost saving hacks/skills/claude.md. What I had success with (although benchmarks are older) is to index the codebase with a dedicated local code embedding model. It's a bit expensive on the CPU side but in my benchmarks it reduced token use and wall clock time significantly.…
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 snake…
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.