I am running several named pi instances in parallel in their own user account on NixOS, so they can install whatever they want in ephemeral shells and I never need to worry about their env. The agents can spin up new enabled XMPP agents if I request it, though for now I've only needed a few since I'm not doing too much in parallel.
My Pi is very vanilla, only my own XMPP wrapper and pi-subagents extension for anonymous subagents.
Using it primarily with Deepseek v4 Flash for chipping away at coding tasks or server maintainence while I'm AFK or in transit.
NixOS is the key to all of this, since agents can interact see the whole server config, make changes and run compile-time checks before actually deploying. It also means that even if they do mess up I can always revert.
The headless pi + xmpp wrapper ended up working much better because the XMPP bridge is the only interface and I get full control over its capabilities.
This is my wrapper: https://github.com/zachpmanson/pi-msg
1) system prompt in pi is quite small (way smaller than the one from OpenCode)
2) when your agents.md file changes pi does not re-spam it (preserves cache, good trade-off!)
3) only 4 tools, every tool comes with a description for how to use it and causes reasoning overhead (fewer tools is good)
all of these things add up
here are pi, opencode and smol working on the same tasks in 9 fresh runs
https://smolenv.com/t/nested-template-includes-60636/
you can step through the traces and see how the system prompt + tools steer the agent in a certain way
with GPT 5.6 Sol you can even get away without a system prompt (see smol) and only 1 tool (sh)
Basically, it doesn't handle the context "better", it barely does anything special to it, which can actually be better for cost efficiency.
I ended up on VS Code. I'm very critical of Microsoft generally, but VS Code is a very good editor and my favorite agent harness.
For headless, Pi might be the way.
IMO, I view it more than a coding agent, it's a coding agent platform with powerful extensibility.
My advice: focus on getting work done and slowly adapt Pi with small augmentations as you go. You can start getting work done on vanilla setup. When the right idea comes along, try it. Be ready to refine it, and most importantly, rollback the addition. I've rolled back a bunch.
Many "batteries" that are "included" come from speculative and half-baked ideas, from people who were excited about something at some point in their journey. In practice, those ideas may not bring the desired results, and their creator may've moved on already. So it's better to either learn very well established tools, or mold your own slowly.
For example, many automatic memory systems are not helpful. I built a small extension that asked me whether it should remember something (and write it down to a properly scoped SKILL or AGENTS file). Turned out I accepted less than 5% of suggestions. Most were useless one-offs that would pollute the context. Can't imagine how much crap would accumulate if I wasn't in the loop.
Yeah maybe Claude/OpenCode/KiloCode/Hermes/whatever are not as minimal as Pi but they also work right now.
And if you try vanilla Pi, you will also find out that it works right now.
I've found them to be extraordinarily helpful, because they allow me to much more carefully control context and reduce token spend by using a smart model for the parent agent and cheap models for the subagents. Do you just have a big token budget?
If you're willing to put in the work to master the learning curve and push through the issues, it can be a great tool: https://i.sstatic.net/7Cu9Z.jpg
I understand both world views and both are legitimate. But I do feel like LLMs are advancing so quickly that it's not a good use of my time to optimize harnesses at this point. I have actual work to do, so sharpening my tools needs to be selective and time-boxed. Personally I'm staying agnostic on harness, not locking into Codex or Claude Code, but also not prematurely optimizing things that tens of thousands of other tools-focused developers are going deep on across the ecosystem. My goal is not to be an early adopter but to reap the benefits of all that experimentation.
I don't want to spend 2 hours prompting, configuring and fixing features that I need which are standard in every other harness. I don't really want to be wasting my tokens to make an application function like every other harness. I don't really want to have to repeat the cycle on every machine I want to work with. Every VM, every server, every laptop.
For instance the XMPP integration someone mentioned allowing agents to talk to each other and to you remotely; or custom extensions to enable workers to be tmux aware; or adding whatever memory system you’d like; and so on
Also, you can version control your tweaks and easily sync with other machines, just like any code.
It really doesn't take much for it to be useful, maybe something to search the web?
If you want you can just tell it to write you extensions too, like one to wrap curl so it can get to the web easier for instance. Or just tell it to use curl, really up to you. Just an example to point out: like, do whatever, it's very flexible.
If you want a more tricked out "starter pack" there's oh-my-pi or lazypi and maybe a few others. But worth being careful what you install because 1. A full pack of extensions can destroy the minimalism of pi 2. Random extentions are a security nightmare.
You could try ohmypi but it sort of misses the point.
Why not just install nicopreme's pi-subagents and pi-web-access and then install whatever else you need when you find it's missing?
The result is that the tool gradually morphs into the thing I need rather than me having to adapt myself to whatever new thing Anthropic or OpenAI comes up with.
I can also feel confident that the thing it becomes is what I actually need and not what maximizes token usage...
at least with GPT 5.6 Sol fwiw
https://smolenv.com/t/nested-template-includes-60636/
sh is all you need
If I have agents.md or other context I want it to read I mention it at the beginning of the session
re MCP: I am not using an MCP with smol
but there are ways to convert MCPs into CLI tools or typed js
I imagine that would work well/more token efficient with smol (or most harnesses actually)
The best thing I found so far re smol is that it fits into the context window with plenty of room to spare
So it is easy to adapt (and add stuff to it, even stuff you only need specifically for just 1 project)
Whereas adapting a more complex harness is more error prone
I do like the grug-brain approach of keeping things extremely simple and easy to reason about.
One thing that I don't like about Pi is that it's almost too extensible, in the sense that I can add a lot of shit into it without really understanding what a given extension is doing. And both from a security and token efficiency standpoint, I like the premise of converting things like MCPs into CLIs. It might be worth investing in tooling that works nicely with the agent harness, but that is not directly integrated with it. I'd be glad to work on that for smol if I can get a workflow going.
I realised how use case dependent harness behaviour is when I tried to use my customised-for-a-side-project pi config at work and realised I needed to tweak it significantly to be useful - I would not be surprised if tools like Claude Code needing to be all things for all people is hurting their peak usefulness.
Doesn't make sense to me, but to each their own.
Same with any of the off the shelf harnesses.
Go build something useful instead of tweaking the minutiae of the harness.
Its very easy to use and has a pre-made profile for pi. Just do something like `alias pi="nono run -v --profile pi --allow-cwd -- /opt/homebrew/bin/pi"` in your shell.
If YOLO MODE causes pi to destroy my workstation (it hasn't yet) I'll just nuke the thing from orbit and spin up a new one.
opencode has never done that.
I'm allured by the minimalism, so I didn't quit there, but I'm not keen on letting it loose with vague instructions, that's for sure.
There are also a ton of small mechanical things a harness can handle that make the whole process much smoother. A really simple example is auto balancing parens. Even frontier models like Claude still struggle with this. Often the model will end up writing a python script to figure out where the mismatch is, and then generate a new version of the code. All of that simply wastes tokens and eats up context on a task that could've been accomplished completely mechanically.
The approach I took with dirge, is to put the model in a loop where it has clearly defined tasks, and the harness handles any repairs that can be done automatically. And I used Janet to provide a plugin system based on what Pi is doing. You get a batteries included experience out of the box, and you can customize it to fit a specific project using plugins if needed.
it feels like there's still a strong layer of "for us" vs "for you" within opencode, that i hope, over time can get chewed away at. plugins to rebuild history, to re-title are just impossible, for example. none of these changes, these freedoms are hard to release. the patches i juggle are easy. but whether or not my agentic software serves as a substrate for my desire, or whether it allows me to augment agency: tis the question.
Dax (opencode lead) has such humble takes, is so forthwith about trying failing trying again on and on. about iterative improvement. and it feels like the guts are so in line to deliver, to allow such freedom now in OpenCode. but i don't see the product (anti-product) alignment, where opencode understands that it's competition isn't cc or codex, which can't and won't ever really compete, but pi, that the competition is to be the putty, to deliver the agency, to be a substrate. really hoping, because i love opencode, and these internals in v2 are sick.
the "devtools must be open sourced" debate comes screaming into the fore on this. it certainly argues similar to the post here: that it is minimalism, it is adaptability, programmability, it is directability that unlocks and unleashes us:
> Imagine the convoluted misery it would be trying to plug that into the VS Code extensions API! Or trying to get it into vimdiff. It would certainly be possible, but the machinery to start pre-processing the commits as soon as they appear would be nigh-on impossible. - https://blog.exe.dev/devtools-must-be-open-source https://news.ycombinator.com/item?id=49156111
i don't even fully agree! today more than ever, why not cut a VS Code extension? why not cut some wild coop.nvim async extension that runs whatever subprocesses, talks to whatever system daemon? dream it up and do it; the llm's will cut through the mechanicals. but the core point, about finding software that doesn't obstruct, that accelerates the human agency: it's so Douglas Engelbart. to Augment Agency is so close akin to Augment Intellect, the grand passion for human interest engagement envolvement constructivism fucking-around-and-finding-out. and my how unhindered we can be now. if only our tools/systems/softwares let us be. here's to you, soft software!
Him and Armin especially, have been involved in OSS for years and have worked hard to build communities around projects they’ve built and maintained. We’ve all seen enough projects become what you’re afraid of, Mario included. I’m optimistic that they’ll keep true to their goal of keeping pi open while building their other products around it. I think they understand the community dynamics necessary to keep a project like pi going. And they want it to succeed that way.
