161–170 of 334 posts
These simple harnesses perform the best in my day to day experience but I sitll can't figure out why that's the case.
Bigger harnesses need to balance upping your token usage and being helpful.
I had Claude Code build me one of these as well, though I added Dirac's line hashing for edits etc. Also used Rust, and I had this idea that I should use plugins so it can self-edit by implementing in hooks but in the end, I just have it create exhaust information about improvements into a separate file and just update the source code and recompile. The source code is in a fixed place so it can just rewrite and build…
IMO, the problem with Claude Code, OpenCode, Pi is the harness quality and convincing the agents to do the exact things you need, to define workflows and make the agents stick to it. I didn't experience performance issues. For example I have an agent in Claude Code that has strict rules to do something before implementing every phase in the plan. Sometimes it decides not to do it. "But, wait the feature is simple eno…
Given how an LLM works, you can never be sure it will always work. LLMs are not deterministic.
We don’t trust llm execution- so we add user approvals. But task decomposition calls for co-recursion between code and prompts. This means that the approvals should be evocable at any depth. I think we need some kind of protocol for that (à la the Cubes OS protocols for cut and paste between vms). Maybe a workaround could be to use bubblewrap of the scripts ther recursively call the llm (and run the agent in yolo ins…
Nothing is committed until the final top-level transaction is accepted.
Earlier quoted context omitted.
Well... for the most part, you use it like skills, but instead of "commands" you can think of "environments": so '/prompt debug', which is one of the integrated prompts, allows for a debug-focused agent, you can then talk to it as a normal agent, and then '/prompt code' to go back to the standard coding agent. About subagents: as of right now, the entire agent runs on one context buffer, so it doesn't support subagen…
It sounds like you're saying that /prompt changes the system message part of the session. Doesn't that cause a cache break and result in higher usage/cost?
So in that way it's not like skills at all, neither of those result in paying full read price on the entire session, just the skill prompt itself.
Something else I noticed... In the Anthropic implementation it doesn't seem to be using 'cache_control' in the body. Assuming my understanding is current, without that the Anthropic API won't do any caching at all (unlike most other APIs that do some level of automatic caching without it being requested). So that would result in paying full read price on every turn.
Of course I could be missing something, it was a quick look. Can you clarify?
I vibed a comparison/review of these two systems using my llm wiki: https://zby.github.io/commonplace/work/pi-agent-zerostack-co...
(the prompt is in https://zby.github.io/commonplace/work/pi-agent-zerostack-co...)
There is also https://github.com/Dicklesworthstone/pi_agent_rust I vibed a comparison/review of these two systems using my llm wiki: https://zby.github.io/commonplace/work/pi-agent-zerostack-co... (the prompt is in https://zby.github.io/commonplace/work/pi-agent-zerostack-co... )