Aside from the minimal system prompt, how does it handle context better than other agents? It still has to send the system prompt (which includes AGENTS.md and skill definitions) along with the full conversation every request, no?
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.
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.
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.
I have the same opinion as your first paragraph, but I don't want to spend weeks or months vibe-coding basic features which come built into almost every other agent.
Yeah maybe Claude/OpenCode/KiloCode/Hermes/whatever are not as minimal as Pi but they also work right now.
We probably differ a lot in what we consider "basic". Are subagents basic? I found them only useful in very few situations. Is LSP support basic? There are mixed results on whether it helps or hurts. Are multiple choice asking tools basic? I found that they add extra unnecessary ceremony, eat extra context, and I almost never answer with one of the choices exactly.
And if you try vanilla Pi, you will also find out that it works right now.
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
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.
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.
Honestly I think the thing I love most about Pi is that I'm not dealing with a tool with a thousand undiscovered features. I either pick and install what I want from the package ecosystem or I bottle up my own workflows into extensions as I find what works best for me.
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...
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.
The biggest issue with Pi is that they don't have proper sandboxing with auto approval. Most solutions are third party and half baked. You have to either choose between just auto approval (no sandboxing), or a Claude/Codex style sandbox but manual approval.
I started treating my developer workstations like cattle. With a press of a button I can turn a vanilla Ubuntu 22.04.04 server install into my happy-place developer environment. Tools, code, browser -- everything set up exactly the way I want it. I have it synced to a couple of different laptops, and a separate boot drive from my desktop machine. It has a restricted set of SSH keys, and I push code to a separate upstream.
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.
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.
This is also by design. Pi assumes you’re a power user and you know what you you’re doing and what you want. If sandboxing and the security that Claude and codex offer is something you truly need, pi might not be for you and that’s okay.
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.
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.
Eh, it's open source. If its closed, fork it, move on. It's entire raison d'etre is to have a very minimal core so it's nature is that the base product isn't actually where the magic exists, but in the extensibility and the ecosystem. It'd be very tough to close that back down now that it's open.
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 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.
[1]: https://pi.dev/packages/pi-xmpp
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.
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 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.
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...
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.
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.
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.