I've had a lot of success running Pi on my server in headless mode and wrapping it in an XMPP client. This means I can talk to it wherever I can access XMPP (everywhere). It also mean agents can talk to each other when they need to. They've got a shared wiki they interact with and github issues as their todo list.
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.
Having tried all the coding harnesses, I find that using Pi is exactly like using Emacs. For anything you want to build you can ask your agent and it will build it. There's tons of existing code to help you configure it. At the same time half the code is buggy, UI elements will try to overlap one another, and you'll periodically get crashes.
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 often find it reductive when people say "just tell Pi to build you an extension". Having used it as my one and only harness for a few months now, it's easy to get an extension, but hard to get a good one, that actually works well and helps.
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.
I do like to keep up with what people are doing with their setups as a source of inspiration, but by looking at the root of what they're getting at, not necessarily their exact implementation.
For example, many talk about automated memory systems for agents, but I built a small extension that injects a little prompt, something like "is there anything worth remembering?" and offers to write memories into different global or scoped SKILL or AGENTS files depending on situation.
Out of all offers to remember something, I accepted less than 5%, because most were one off situations that aren't worth the context pollution. I can't imagine how much crap would accumulate if I let agent remember things automatically.
That said, as a dev for ~30years now, I generally kinda stopped buying a lot exciting-sounding narratives out there. I realize a lot of "batteries" that are "included" come from many speculative and half-baked ideas, from people less experienced, 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.
But hey, you wouldn't know all that without trying stuff, so keep experimenting. :)
We built our first version of our in-app agent with opencode, but we're probably going to switch to Pi. Fundamentally, Pi is the shape of the thing that should exist, and it's awesome to see that it works. Very satisfying to my engineering brain. Been having fun with ohmypi as my personal harness, but going to switch over to pi soon and just mess around with it until it works the way I want. The idea of completely personalized software is so cool and now that it's finally possible I am having so much fun.
Haven't heard of ohmypi, thanks! I feel like this is a good starting point for someone like me who is not ready to configure a harness from zero right now.
Pi has the best code out of all coding agents. The only problem is it’s not as fully featured and some of its modules should be factored out into their own code base.
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.
Literally every AI project ends up getting monetized even (read: especially) if it starts as open source. It's only a matter of time before π's enshittification kicks in.
Why is this relevant though? This project is so minimal that forking it at any point since it started “mainstreaming” and implementing any functionality that came after would have been utterly trivial.
I've had a lot of success running Pi on my server in headless mode and wrapping it in an XMPP client. This means I can talk to it wherever I can access XMPP (everywhere). It also mean agents can talk to each other when they need to. They've got a shared wiki they interact with and github issues as their todo list.
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.
Having tried all the coding harnesses, I find that using Pi is exactly like using Emacs. For anything you want to build you can ask your agent and it will build it. There's tons of existing code to help you configure it. At the same time half the code is buggy, UI elements will try to overlap one another, and you'll periodically get crashes.
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
Never learned Emacs but am a Neovim user. But similar to what I said to my colleagues as well. Codex, Claude Code are VS Code, Jetbrain. Pi is Neovim.
I often find it reductive when people say "just tell Pi to build you an extension". Having used it as my one and only harness for a few months now, it's easy to get an extension, but hard to get a good one, that actually works well and helps.
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.
I do like to keep up with what people are doing with their setups as a source of inspiration, but by looking at the root of what they're getting at, not necessarily their exact implementation.
For example, many talk about automated memory systems for agents, but I built a small extension that injects a little prompt, something like "is there anything worth remembering?" and offers to write memories into different global or scoped SKILL or AGENTS files depending on situation.
Out of all offers to remember something, I accepted less than 5%, because most were one off situations that aren't worth the context pollution. I can't imagine how much crap would accumulate if I let agent remember things automatically.
That said, as a dev for ~30years now, I generally kinda stopped buying a lot exciting-sounding narratives out there. I realize a lot of "batteries" that are "included" come from many speculative and half-baked ideas, from people less experienced, 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.
But hey, you wouldn't know all that without trying stuff, so keep experimenting. :)
We built our first version of our in-app agent with opencode, but we're probably going to switch to Pi. Fundamentally, Pi is the shape of the thing that should exist, and it's awesome to see that it works. Very satisfying to my engineering brain. Been having fun with ohmypi as my personal harness, but going to switch over to pi soon and just mess around with it until it works the way I want. The idea of completely personalized software is so cool and now that it's finally possible I am having so much fun.
Haven't heard of ohmypi, thanks! I feel like this is a good starting point for someone like me who is not ready to configure a harness from zero right now.
Pi has the best code out of all coding agents. The only problem is it’s not as fully featured and some of its modules should be factored out into their own code base.
I love hacking away at pi extensions.
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.
End up building Pi extensions instead of actual product.
Doesn't make sense to me, but to each their own.
Literally every AI project ends up getting monetized even (read: especially) if it starts as open source. It's only a matter of time before π's enshittification kicks in.
Why is this relevant though? This project is so minimal that forking it at any point since it started “mainstreaming” and implementing any functionality that came after would have been utterly trivial.