Open-source coding agents had a weird start to 2026.
In January, Anthropic suddenly blocked third-party tools from using Claude subscriptions. Ove...
For further actions, you may consider blocking this person and/or reporting abuse
I’ve been thinking about the same trade-off while building Velloc Code. One thing that helped was not treating the entire workflow as a single always-on context.
I try to keep the initial context small, load only the skills and tools needed for the current step, and use a lighter execution path for simple edits. Larger or riskier tasks can opt into additional planning, review, and verification.
That doesn’t eliminate compaction, but it reduces how often irrelevant instructions and tool definitions compete for context. It also makes the token and latency cost more proportional to the actual complexity of the task.
I’m still experimenting with the boundaries, but progressive context loading has felt more useful than simply increasing the context window.
Hey Max, Interesting approach. How are you deciding when a task should pull in more context or switch to the heavier planning/review path?
I’m mostly using a risk/complexity threshold rather than a fixed task taxonomy. Simple, local, reversible edits stay on the light path. I pull in more context when the task spans multiple files or systems, the requirements are ambiguous, the change has external side effects, or verification is hard. Planning/review becomes the default once the blast radius or uncertainty is high; otherwise I start light and escalate when the task reveals it needs more. In practice, scope, reversibility, and testability have been the best signals so far.
Really enjoyed this comparison. The performance and architecture differences are interesting, but the security model was probably the part I found most valuable.
The distinction between OpenCode's tool-level allow/ask/deny controls and Pi's approach of relying on external isolation is particularly important. They are different security boundaries, rather than simply different feature sets. Permissions can constrain tool invocation, while sandboxing determines what the process can actually do if the agent is compromised or misled.
I also found the in-process extension model in Pi interesting from a security perspective. It gives you an impressive amount of runtime control, but it also means extensions become part of the trusted computing base rather than isolated plugins.
One thing I'd love to see in a future comparison is a dedicated security evaluation alongside the functional benchmark: prompt injection through repositories, malicious tool arguments, permission bypass attempts, credential access, MCP/tool abuse, and the resulting side effects. The same model and tasks are excellent for measuring agent capability, but those scenarios would reveal how the two harnesses behave when the model itself cannot be trusted.
Thanks for putting the comparison together. There is a lot of useful technical detail here, and I especially appreciate that you don't reduce the conclusion to “one agent is better” — the different security and architectural philosophies are probably more interesting than the 6–6 scorecard. 🔐
Thanks Marco. Really appreciate this perspective. The prompt injection side of it especially would be really interesting to see.
I think PI has also been shown to accomplish tasks the cheapest.
Yeah, almost always
You’d definitely benefit, just as OpenClaw did.
a lot you covered, Shrijal. Thanks for sharing. 💯
Pi’s rock-solid <1k token prefix gets almost 100% cache discounts across turns. OpenCode’s dynamic context compaction keeps breaking that cache. Minimalist architecture literally saved real cash here.😄