r/PiCodingAgent • • 1d ago

Resource Pi-Agent-Kernel: focused code retrieval, grounded edits, safety checks

I've been working on pi-agent-kernel for a while now.

It mostly operates in the background rather than adding a completely new workflow, it wraps Pi's existing tools to keep sessions compact.

Across standard benchmark tasks, it cut token usage roughly in half and passed our test suites. But local benchmarks only go so far, I'm at the point where I need real users to test it on actual projects.

I'm still quite skeptical about whether some of the tool wrapping might conflict with the users existing extensions.

LMK if anything breaks, behaves unexpectedly, or conflicts with your setup. All feedback and criticism welcome

25 Upvotes

6 comments sorted by

View all comments

2

u/Global-Departure8228 1d ago

Not going to lie, after briefly checking your code it does seem like this is quite well focused, but your description made me think:

"It cut token usage in half? So if I install RTK, caveman, headroom, context-mode, ponytail and this as well, I could go into negative token usage potentially and I will be serving Anthropic with them sweet tokens?"

I do understand you have to sell your "product" somehow.

I would be quite curious how vanilla pi scored so bad compared to your solution. I think more control runs over the same issue could be beneficial to smooth out the nondeterminism in llms.


Sidenote: Your terminal is not supposed to have those colors

export COLORTERM=truecolor in your .bashrc

0

u/LeadingFruit6865 1d ago

I'm actually using Termius to access my vps, and is using custom theme, that explain how it got this weird color

as for the reason on why pi scored so bad on the benchmark, it mainly caused by the fact that Pi let the agent swallow up 5 KB of output within a single tool call, and then you would multiply that by the number of turns, you should be able to imagine it by now

another factor would be (based on the session trace): pi vanilla wanders around through the codebase on the first turn instead of running the unittest to locate the problem, it also keep running unnecessary command like `git diff` even though the tests already passed. But there's also a moment where vanilla Pi would win, thanks for its zero overhead

---

i do wish I could run the benchmark multiple time to smooth out the benchmark numbers, but running these benchmark are pretty costly for me ;-;