11–20 of 121 posts
I feel like what is needed is not compression, but aggressive context management with subagents.
I am the author the text. What do you mean by aggresive context management with subagents? Would you add a lopp that would trim the context? Both of those tasks seem even more difficult
Earlier quoted context omitted.
I am the author the text. What do you mean by aggresive context management with subagents? Would you add a lopp that would trim the context? Both of those tasks seem even more difficult
I believe they mean aggressive delegation to minimize context bloat in the coordinating agent.
I feel like what is needed is not compression, but aggressive context management with subagents.
If you need a piece of information that is buried somewhere, or a high-level summary/distillation of a larger body of info, then subagents may be the right tool for the job.
If you need all the gathered context for later use (i.e. distilled context is insufficient), then subagents probably are not the right tool for the job.
Am I the only one that thought RTK was Real-Time Kinematics used for precision with satellite navigation?
No. I clicked here for the same reason.
and it stands for Rust Token Killer
But if it's making a dent in token usage (which I have not personally measured), then that's great.
I had to add some system prompt instructions to Pi to help it work (GPT 5.5 initially got confused when `git status` looked different than expected). The Claude Code extension appears to do a proper job of informing the agent about the unexpected shape of the output without any extra work on my part.
https://github.com/toon-format/toon is another interesting one, and I feel like it takes on a much more achievable goal - reduce whitespace and verbosity of JSON, not overall context compression.
Tool use output represents a large amount of my output. I'll take 3.7M tokens saved on 3.9M tokens of input. Tokens saved are tokens saved.
> 3. Where Are the Accuracy Benchmarks?
As a user of RTK, it would be nice to see accuracy benchmarks. However, I've seen no evidence of the model missing anything critical as a result of the compression. As part of their design philosophy they are very strict about preserving correctness to the point that if a filter fails they fall back to raw output. For my most frequently used commands I've inspected the source, was happy with what I saw, they've earned my trust thus far.
> The day git, cargo, npm, or grep updates its terminal formatting by a few spaces or changes an error layout, RTK's regex and parsing filters will break. And returning to the silent failure trap, it won't throw an explicit error; it will fail quietly, feeding corrupted or partial text to your agent.
Again, any filter that fails simply falls back to the raw output. One of their core pillars is avoiding this exact scenario you described. RTK should never feed corrupted or partial text to an agent.
Your concerns are fair but I'd like to see your criticism backed up with evidence. Have you used RTK? Have you found evidence that they are failing to preserve correctness?
I feel like what is needed is not compression, but aggressive context management with subagents.
Use the right tool for the job. If you need a piece of information that is buried somewhere, or a high-level summary/distillation of a larger body of info, then subagents may be the right tool for the job. If you need all the gathered context for later use (i.e. distilled context is insufficient), then subagents probably are not the right tool for the job.
I've been trying out RTK and it seems kinda alright. I doubt it's saving much, but the quality of the work feels similar. But if it's making a dent in token usage (which I have not personally measured), then that's great. I had to add some system prompt instructions to Pi to help it work (GPT 5.5 initially got confused when `git status` looked different than expected). The Claude Code extension appears to do a proper…
My take is that handling so many versions and so many different tools shouldn't be the work of any single repo. The responsibility should be either on coding agent to compress or best case scenario people who are responsible for cli tool
I feel like the state of the art is baked into the compaction logic, and I've had a lot of problems with compaction (absent other prompting) losing key bits of state. https://github.com/toon-format/toon is another interesting one, and I feel like it takes on a much more achievable goal - reduce whitespace and verbosity of JSON, not overall context compression.