RTK reports token savings, but our cost benchmarks disagree
48 points by michalwarda 2 hours ago | 24 comments

aeneas_ory 2 hours ago
All 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. 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.

Why does it work you may ask? Well, LLMs basically brute force words/phrases and pipe that into find/grep/pgrep/whatever (or as recently discussed here write a python script for it - https://news.ycombinator.com/item?id=49654229). Semantic search looks for similarities so you have to do less brute forcing. Comes of course at the cost of indexing everything first.

You can find the project here: https://github.com/ory/lumen

reply
Whitespace 26 minutes ago
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
icantevenhold 14 minutes ago
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
esperent 12 minutes ago
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
Bridged7756 20 minutes ago
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
SJMG 5 minutes ago
[delayed]
reply
cassianoleal 14 minutes ago
> One of: Claude Code, Cursor, Codex, or OpenCode

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

reply
psadri 5 minutes ago
We 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.

reply
ProjectBarks 29 minutes ago
It seems like most of these tools are mostly vaporware. Benchmarks done on Headroom and RTK show that neither result in real savings. If it were possible to have such a simple pre-process step why wouldn’t the AI Labs upstream the optimizations themselves? My guess is they mostly don’t work or make the behavior much more confusing for the model. I really think there needs to be some kind of independent benchmark.

Here are other cases demonstrating the exact same issues with these kinds of tools:

https://blog.jetbrains.com/ai/2026/07/rtk-claude-code-token-... https://brandonbarker.me/writing/headroom-fewer-tokens-bigge...

reply
grim_io 3 minutes ago
Even JetBrains is now AI blog-slop, how disappointing.
reply
GodelNumbering 12 minutes ago
Some months ago I was evaluating command output compressors to integrate into Dirac[1] as that seemed like an easy win that would compliment and compound with Dirac's other mechanisms.

I tested rtk among these and it was actually a net negative in both CPU time and accuracy, the latter would throw LLMs way off and make it hard to recover. If you are building a coding agent, I'd hard pass on rtk.

   ~ $ time grep Return * 2> /dev/null | wc -l
   966
   grep Return * 2> /dev/null 0.36s user 0.02s system 98% cpu 0.382 total
   wc -l 0.00s user 0.00s system 1% cpu 0.380 total


   ~ $ time rtk grep Return * 2> /dev/null | wc -l
   260
   rtk grep Return * 2> /dev/null 4.10s user 17.10s system 92% cpu 23.008 total
   wc -l 0.00s user 0.00s system 0% cpu 23.007 total

Much worse CPU consumption, and more importantly, plain wrong result. These kind of results compromise the entire agent performance because the model trusts wrong output. Without the correct results, any hypothetical savings are penny wise pound foolish

So yeah I am still on the lookout for a credible CLI wrapper, do let me know if you have any in mind.

[1] https://github.com/dirac-run/dirac

reply
fwlr 2 hours ago
This makes sense. “Don’t try to penny-pinch your employees” is a lesson most managers learn eventually, and I guess agent-orchestrators will have to learn it too.
reply
simonwsimonw 2 hours ago
[dead]
reply
gillesjacobs 2 hours ago
Main takeaway:

  Average cost per attempt, without → with RTK:
  
  Claude/Fable: $1.72 → $1.64 (~5% cheaper)
  DeepSeek: $0.115 → $0.121 (~5% more expensive)

  Almost all Claude savings came from a single task.
  Excluding it, savings were under 1%.
It took me a few rereads to parse out the top-line. This article really buries the lede.
reply
fleetfox 57 minutes ago
I don't understand how this or all these magic skill bundles and methodologies get traction and why they are so popular. It's either plain worse or has serious trade offs.
reply
daliusd 30 minutes ago
It is just "putting a wet phone in rice" of AI
reply
hokkos 47 minutes ago
If 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.
reply
sreekanth850 2 hours ago
i don't know if such hacks works, but in C# if you use roslyn mcp, you save a lot.
reply
xnorswap 20 minutes ago
I haven't tried it since it was first released but it didn't seem to work at all for me back then.

It was so slow that the roslyn results would be lagged well behind any edits it was making, which would just leave it confused.

reply
VulgarExigency 2 hours ago
I don't think they're comparable. RTK just modifies the output of CLI tools to reduce the number of tokens, a Roslyn MCP gives the agent a fundamentally superior way of interacting with a C# codebase.
reply
antupis 56 minutes ago
My main issue with rtk is that rtk randomly messes modification and agent start polling same tool continuously.
reply
sreekanth850 2 hours ago
Yes. and i find model makes less errors and reasoning the codebase well, especially when you do a large refactor.
reply
semiquaver 51 minutes ago
Just another instance of the bitter lesson. The model itself knows how to be clever and conserve tokens in command output by using shell primitives and as the models get smarter they get better at anticipating large output and defensively adapting the input commands.
reply
vrighter 2 hours ago
well yeah.... now you're giving it output it wasn't trained on.
reply
nextaccountic 56 minutes ago
What if the next-gen models are trained on RTK output as well? Then you will actually have less tokens in the context window, and the model won't become confused (which would require more turns, wasting tokens)
reply
vrighter 18 minutes ago
doesn't change the fact that it doesn't do what it claims to now. I just don't care about vague promises and "trust us bro" vibes that tech is sold for nowadays. It claims x, it doesn't deliver x. Maybe it could in the future, or maybe not.
reply
yuzushi-dev 10 minutes ago
[dead]
reply
saltypixel 21 minutes ago
[flagged]
reply
elian_ilands 2 hours ago
[flagged]
reply