Lots of praise for Pi in this thread, so I'll offer up a diverging opinion. Given all the hype, I was a bit underwhelmed by Pi. It definitely has some good ideas around customization, but it annoyed me in many little ways.
For a program that's minimal it sure takes a long time to start up, the standard C-p and C-n bindings don't work, it doesn't follow the XDG Base Directory Specification and just pollutes my $HOME directory.
I think there's still space for another harness that's 1/ open-source, 2/ written in a fast compiled language (Rust, Go, etc.) and scriptable in a simple (aka non-JS) scripting language (Lua, etc.), 3/ less opinionated and more sensible so things like XDG isn't a WONTFIX.
> For a program that's minimal it sure takes a long time to start up, the standard C-p and C-n bindings don't work, it doesn't follow the XDG Base Directory Specification and just pollutes my $HOME directory.
This drives me mad, I believe Ollama and Claude Code also do this. Seems to be rife in the LLM world. IMO there's no excuse for new software sticking dotfiles in my homedir in 2026.
> IMO there's no excuse for new software sticking dotfiles in my homedir in 2026.
Agreed, and also, tinfoil hat time:
I believe they opt for this so that state and config files don’t need to be distinguished (it all goes into ~/.appname the same). It’s still not an excuse, but maybe laziness is the reason?
But I agree with you, it's biggest weakness is that for a real long time the tagline of it was "there are many harnesses, this one is MINE" (That being Mario's)
I have a lot of respect for Mario and his team, but there's things like you've pointed out that deviate from standards, and other issues that I've seen get posted, only to get knocked down by the team as WON'T FIX because, even though the new owners changed the tagline from MINE to YOURS... It's still very much Mario's.
I do like opinionated things. Truly. But I'm also of the opinion that standards exist for a reason.
That said. I like Pi so much that it's my daily driver, and I've created an ecosystem of plugins to do everything I want, having them all tie together and communicate through the shared bus. Pi is really a good harness.
It's just, well. I don't agree with some of the opinions.
If I'm going to add another thing here... Whilst you cannot get everything you need from the openAI API spec, you can get a surprising amount to get a model config. That said. Versions of Pi are still shipping with model configs for certain inference providers. I do hope that gets decoupled at some stage. I see the groundwork being laid.
So the work is being done in the right direction. I applaud the team but I do get the feeling that a lot of this is because people want to contribute, but the team really wants to hand craft this. And that's great
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've thought about using email and pi, as then the responses can be email patches I can inspect and it's easier to keep multiple threads going. But I've also thought that XMPP makes sense too, and is slightly easier to connect to a VPN rather than setting up mail.
Initially I was using that extension but I ran into its limitations pretty quickly. Sometimes the agent wouldn't reply over XMPP, it didn't have any support for typing indicators or status messages, and it had no way to support inter-agent communication, the agent could only ever speak to the configured owner account. I also had no way of running system commands like /new over XMPP.
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.
Same here, though I use Matrix and only have two agents. One for me, one for the family. They are mostly for household management tasks, but mine has an ssh key that lets it remote in to some of my servers and deal with stuff.
That said, I really don’t like “developing” over chat. I’d much rather wait until I’m really available to inspect diffs properly and watch all the thinking and tool use, real time.
> NixOS is the key to all of this, since agents can interact see the whole server config
We added native support for nixos for the same reason - malleability and debugging becomes easier (also because one of our customers asked us to). I think we might be the only sandbox provider to add this in warm pools.
Interesting setup. Would you still have chosen a Wiki vs a folder of md files if all agents were using a shared filesystem / compute environment (eg personal computer)? I see Wikis often mentioned as shared state stores and I’m trying to figure out what makes people reach for them.
When I say wiki I mean a folder of md files in a git repo. I only say wiki because it uses [[wikilink]] style links. Proper wiki software would be massively overkill for a project like this.
Yes they fit well together. The XMPP clients I've used have great protocol interaction but the UIs have been surprisingly janky. There are so many messaging apps to steal design cues from, yet the "popular" open source clients haven't really done this. I've started my own forks for converse.js and conversations.im to add some UI polish.
Funny that the XMPP clients has taken more of my time than the pi XMPP wrapper itself.
I plan to do a writeup once I've got a few more of the kinks out with consistent cross agent comms. Message routing happens in-band right now, not too big a problem since 95% of the messages are DMs to me but once I'm running more in parallel I'm sure they'll have some more cross agent communication issues.
Want I've been doing for transit is using termux on android with magisk for root access, allowing me to install Nix home manager and harnesses on my phone, and then drive everything from my phone, including eternal terminal sessions to my homes erver, where it spins up agents there as well.
Incidentally it's also great for debugging issues with my phone.
I’m going to go against the grain and say that Pi is a little too minimal by default. The emacs comparison is interesting, but default Pi is like emacs that can load files but you’ve got to extend it manually to save or search within a file.
I’d argue that there’s a minimal set of functions that a coding harness needs to just enable a model to get stuff done, and they shouldn’t be an extra effort to set up.
(Oh-my-pi exists for those of a similar persuasion.)
Philosophically, pi.dev is exactly what I'm looking for. Minimalist and explicit (YOLO by default, we know it can be trouble but we tell you so).
Anyone here using the Rust rewrite of pi.dev as their daily driver? It's endorsed by the author of pi.dev and looks pretty attractive to me being both minimalist and not having npm attached. Any info "from the trenches" are appreciated (setup with sandboxing, extra niceties etc).
I’ve been using both families of models inside pi/piclaw (https://rcarmo.github.io/projects/piclaw/) and I assure you they work _better_ in that environment than in the originals. The models are not trained to the harnesses, the harnesses provide cues that the models follow.
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?
The /tree feature is incredible for context management. It's really surprising the other harnesses haven't slurped it up yet. It lets you rewind back to any previous message and fork the conversation from there, removing your 'side quest' (e.g. where you dig into something the agent said) from the context. Some other harnesses have a 'rewind' feature, but this lets you maintain the previous conversation history in a separate thread, and even jump between them.
You can do that in Copilot in VSCode. There’s a fork icon before every message that creates a new session from that point. The relationships are not maintained in a tree though (not sure if Pi does that).
Claude code in the cli also has /fork to clone the current session state. But if you use it more than once or twice that quickly becomes hard to manage. Actual tracking in a tree sounds like an awesome feature (and one that I love in conversational UIs like openwebui as well)
A lot of harnesses compress the context when it becomes massive, Pi doesn't do that out of the box (EDIT: that's wrong, as pointed out below). It can be both good and bad. Also since it doesn't have a lot of tools out of the box, the context is not polluted with external tool call descriptions that the agent has to be aware of.
Basically, it doesn't handle the context "better", it barely does anything special to it, which can actually be better for cost efficiency.
Ok my bad. I remember hearing that it was a criticism of common harnesses and that the creator of Pi wanted more control over that feature, so I assumed it wasn't enabled by default. Thank for pointing it out !
Pi does one thing that I love, developing a tool that has minimalism where it's easily configurable with good documentation. The leads to new use cases that the the author(s) would have never dreamed of. The organic growth process of the Pi ecosystem has been fascinating to observe. It's one of the reasons why Pi has become one of my favorite coding agents to this day, flexible beyond personal uses and extensible to larger environments.
IMO, I view it more than a coding agent, it's a coding agent platform with powerful extensibility.
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 don't really get this philosophy, at least with coding harnesses.
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.
I'm the opposite. I started out promising myself I'd install all those handy looking plugins (I had like 20 I wanted to try out). But I've been slippery sloped into building my own Pi extensions and reinventing the wheel many, many times. It's been months and I love it. I just keep discovering and learning, and forgetting, and doing it all over again. I've been building my own harnesses since before that word was so common though, even before Aider was released.
There are decent plugins for the essentials you’d find in other harnesses. Pi shines in opinionated things you won’t find elsewhere.
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
If you want something that's like every other harness then what's the point of considering pi? It's specifically for people who are dissatisfied with other harnesses.
Also, you can version control your tweaks and easily sync with other machines, just like any code.
It's funny you say this, because as someone that rejected emacs (default editor was XEmacs on the Sun machines in my 90s CS computer lab) in favor of vim early. I think a big part of the appeal of vim for me is that it's a great editor just based on the defaults. Sure you can configure it but you don't need to. Emacs strength is customization, and that's what Pi feels like compared to batteries-included harnesses.
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 agree. Pi is more like NeoVim if we have to map to Vim/Emacs. Emacs is full (at least compared to Vim) of the hidden features you didn't know it had installed. Pi doesn't bundle any hidden features. A bog standard GNU Emacs install contains, what, like ~10 games, a mail reader, a web browser, RSS feed reader, a nd a Morse code decipher?
Even more so, Pi even has opinionated forks and "distributions" like oh-my-pi that are like LazyVim/AstroVim.
OMP is great to get started with, there's a whole bunch of stuff in there but it's mostly optional and turned off by default (like the memory backend). You can always try it and create a custom Pi config with only the stuff that you find useful if it's too much.
I'm really enjoying the advisor mode (you can have a second model monitor the output of the primary model and have it "steer" the primary when it makes a mistake or goes off the rails) and the automatic fallback to a second provider if the primary one has issues (Deepseek had some issues yesterday).
I need to dive a bit into the system prompt to see how much context OMP actually adds. I think the system prompt is still 2-3k tokens but that probably depends on bells and whistles.
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.
Subagents are good when the harness (And agent?) understand how smart they are.
My root level CLAUDE.md has pretty much just "use a lower tier agent when relevant".
Then I daily-drive Opus, it automatically offloads simpler stuff to Sonnet or even Haiku based its own reasoning because it "knows" their capabilities.
It's so much more cost/token efficient to do it like this. Opus writes the exact implementation plan for Sonnet and then waits for it to complete. After that it checks the work and fixes any issues itself.
In Codex, for example, this doesn't work because the whole system doesn't know about agent tiers and barely can use subagents. So I'm just running Sol all the time.
> Are subagents basic? I found them only useful in very few situations.
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?
I started out using OpenCode with subagents. Then, after switching to Pi, went completely subagentless, usually on the current frontier GPT model.
I didn't notice any significant change in context usage, and tasks were completed faster. That surprised me, I'm still not sure (not an expert on this), but maybe the handoff boundary was the problem. When the main model gives an isolated task to the subagent, the latter goes wild producing a comprehensive report, trying to satisfy every possibility. Without the handoff, the main model does the job much more precisely and conservatively, checks only specific/narrow things, and stops sooner.
Recently I decided to reintroduce 2 subagents to see how it goes. First was to have a cheaper model drive my real Safari browser instead of using agent-browser and the like. Second, to see if having a cheaper model navigate/search my file system helps in any way.
I think there's some benefit to having a cheap model drive Safari, because there's so much unavoidable garbage produced in that interaction. The filesystem one I don't think I see any benefit, just a lot of unnecessary work that (albeit cheap) wastes more time.
Of course I'm eyeballing this, not benchmarking formally, but I see so many people just onboard these mindlessly. Are you sure that you saw a real improvement in the produced outcomes/timing, or was it based on seeing subagents do a lot of stuff and assuming that the main model would've been doing the same at higher cost?
I admit that subagents may have great benefits, but I wouldn't treat it as just out-of-the-box basic feature that always improves your outcomes.
You don't actually need those features. Initially I began using Pi thinking I would customize the hell out of it. I've installed one extension for guardrails and that's about it. I've been able to do everything I did before just with vanilla pi.
What extension do you use ? With all the supply chain attacks I am warry of adding extensions, so I wonder if there's like a go-to one that everyone uses
I think for indie hackers and people that build their own stack is great, but real scenario and people with money Enterprise likes the idea of batteries included.
I found this one a little bit better and they do support Extensions like Pi. But comes with all features like codex, claude code and it's open-source.
I built https://rcarmo.github.io/projects/piclaw/ on top of pi largely leveraging its extension philosophy (I extended the contract to UI extensions, basically) and am very happy with the results. Even though I added a few more tools, the core agent is wonderful.
Are all of you pi users paying Anthropic and OpenAI for API usage? Or can you combine pi with a subscription?
So far API usage is a lot more expensive than subscription and if you need better models than Deepseek and Kimi, and you are not wealthy, I don’t see a way around this.
You can also use PI with local models like Qwen3.5-35B-A3B [1] and they can be surprisingly good if you development in minimalistic/simple ways.
One game changer when it comes to tweaking configs that are optimized for your use case is that you can easily use a "more powerful" cloud model to identify a good enough config for your local server/pi settings combination [2] in a pattern that applies pretty much anywhere.
Not if you run your own system prompt that does not explicitly contain the term "pi coding agent". Perhaps they string-match against some other stuff, too, but as long as you paraphrase the system prompt a bit, you should be fine.
I use my Anthropic subscription with Pi. I thought they would start charging me API usage at some point, but it never happened. (If it did happen, I would switch to open weights models.)
If using outside of subscriptions, It is almost a no brainer to use this simple because of the efficiency. With subscriptions, not so good. Even the officially endorsed OpenAI integration lacks support for server-side context compaction (without a separate plugin which still triggers the pi native compaction).
I added that in https://rcarmo.github.io/projects/piclaw a few weeks back. The reason it’s not in pi-ai is that server-side OpenAI compaction is encrypted/opaque and (at least in my experience) can cause issues when switching models.
I think for indie hackers and people that build their own stack is great, but real scenario and people with money Enterprise likes the idea of batteries included.
I found this one a little bit better and they do support Extensions like Pi. But comes with all features like codex, claude code and it's open-source.
What it hints at is the direction of model agnostic and custom agents. I could see companies using Pi to create a product for orgs, for example. Low cost and closer to the customer needs than a general harness.
This seems like a more natural use of agents than asking them to one shot and push to prod. Give them a measurable objective, let them experiment, and judge the outcome instead of the implementation. Similar to how you would deal with a junior or intern basically
Pi’s minimalism reveals a simple truth: the LLM is the core of any agent harness. Consequently, much of current harness tuning will become redundant(or even a hindrance) with next-gen models.
I always thought that the frontier coding models were specifically trained to perform well in the harness from their providers. I imagine this will always be the case to some extent.
From what I understand pre-training is totally irrelevant to this and as far as post training goes there will be multiple steps, for claude and codex and the like that ship with a harness, the harness is definitely included in evaluation. However, they will definitely include evaluation from a variety or even none, and settle on something that works the "best" for a release.
I like Pi, but I didn't end up using it. I tried OpenCode, Pi, Zed Editor and some NVIM packages. I wanted open source, featureful and easy to use. Specifically I wanted to easily edit the agent prompt.
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.
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.
If someone has never used Pi, what's a good starting point where someone took Pi and started adding some extensions etc to get to that minimal-but-useful-and-productive-for-coding state? Is there such recipe/writeup?
You can just fire it up and ask it to suggest some, or look on the site at the most downloaded and see which sound useful to you. That's basically what I did. I also put in some work to containerize it and do some manual/automatic checks to lock down extensions a bit, but that's just me.
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.
It's already in that minimal but useful state so you can just start and ask it to write code.
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.
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.
Yeah, but the future will essentially be building extensions for agents. Agents will become the new web browser and extensions will be the new apps. We are already seeing the early stages of this.
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.
Do you use smol? How do you find it compares to other harnesses for things like MCP connections? I’m tempted to use it since I’m a fan of the philosophy.
I didn't realize you were the author. Super cool! I'll be trying it out.
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'm glad there are quite a few good open source ones by now.
Also happy with how much love codex gets from OpenAI.
That said: I was looking at existing agents to find one to build upon and to me they were all too complex and were leaning too heavily into 3rd party dependencies.
Nothing I could understand comfortably in an afternoon (that's also on me I guess). Pi was closest to what I was looking for but still too big and too modular.
(It's hard to come up with good abstractions that work well across all major models + keep up with new concepts that come and go all the time with new releases.)
The more complex agents err on the side of supporting many models 'ok' instead of focusing on taking advantage of a specific model.
With a tiny implementation it is easier to adapt it.
Adding new stuff, removing stuff again, changing it from working well specifically with GPT 5.6 Sol to working with the exact model I want.
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...
I found the nice part of Pi was the plugin system and the ability to hook into any part of the agentic loop. But minimalism is a net negative in my experience. What you really want is a harness that meets the expectations of the model and steers it in the right direction.
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.
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.
My very first request, after reading this thread and deciding to try pi out--it went out of the app directory it started in, and made code edits to a sibling directory in a different git project repo.
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.
Yeah, I think Pi is good to use now because the AI has became so good that they almost can run on their own. Previously, AI agents do so many dumb and expected things that I really didn’t want to let them run on a loose leash and manual+automatic approval helped me steer them better. Even now, sometimes agents in Pi do things that startled me when I realized I didn’t explicitly approve that!
Correct. pi.dev is not a minimal coding agent. It already comes with crazy amounts of preconceptions baked in.
For example, it comes with a bash tool built that you cannot disable. This is not minimal, it's the full kitchen sink. If I want to build a custom agent I have to literally stop using pi.dev and switch to something else.
So yeah, I fully disagree with the title. "Pi’s Minimalism Is Its Advantage" No. full stop. It's too bloated for me already. It's not minimal enough. If it's minimalism was its strength. it might not even need a sandbox, because it can't run bash commands or update files to begin with.
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.
i really hope OpenCode v2 with the Effect internals can ascertain and realize and lock on to being the best extensibility platform, on to having a core that serves not just itself, it's conceits of/as product, but a wider world. a street that wants to "find it's own uses for things".
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:
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!
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.
Lots of praise for Pi in this thread, so I'll offer up a diverging opinion. Given all the hype, I was a bit underwhelmed by Pi. It definitely has some good ideas around customization, but it annoyed me in many little ways.
For a program that's minimal it sure takes a long time to start up, the standard C-p and C-n bindings don't work, it doesn't follow the XDG Base Directory Specification and just pollutes my $HOME directory.
I think there's still space for another harness that's 1/ open-source, 2/ written in a fast compiled language (Rust, Go, etc.) and scriptable in a simple (aka non-JS) scripting language (Lua, etc.), 3/ less opinionated and more sensible so things like XDG isn't a WONTFIX.
> For a program that's minimal it sure takes a long time to start up, the standard C-p and C-n bindings don't work, it doesn't follow the XDG Base Directory Specification and just pollutes my $HOME directory.
This drives me mad, I believe Ollama and Claude Code also do this. Seems to be rife in the LLM world. IMO there's no excuse for new software sticking dotfiles in my homedir in 2026.
My impression is that it's the NodeJS, Go and Rust communities that don't care about XDG.
This 11 year old, open issue is very symptomatic of this IMHO: https://github.com/rust-lang/cargo/issues/1734
> IMO there's no excuse for new software sticking dotfiles in my homedir in 2026.
Agreed, and also, tinfoil hat time:
I believe they opt for this so that state and config files don’t need to be distinguished (it all goes into ~/.appname the same). It’s still not an excuse, but maybe laziness is the reason?
I really really like pi.
But I agree with you, it's biggest weakness is that for a real long time the tagline of it was "there are many harnesses, this one is MINE" (That being Mario's)
I have a lot of respect for Mario and his team, but there's things like you've pointed out that deviate from standards, and other issues that I've seen get posted, only to get knocked down by the team as WON'T FIX because, even though the new owners changed the tagline from MINE to YOURS... It's still very much Mario's.
I do like opinionated things. Truly. But I'm also of the opinion that standards exist for a reason.
That said. I like Pi so much that it's my daily driver, and I've created an ecosystem of plugins to do everything I want, having them all tie together and communicate through the shared bus. Pi is really a good harness.
It's just, well. I don't agree with some of the opinions.
If I'm going to add another thing here... Whilst you cannot get everything you need from the openAI API spec, you can get a surprising amount to get a model config. That said. Versions of Pi are still shipping with model configs for certain inference providers. I do hope that gets decoupled at some stage. I see the groundwork being laid.
So the work is being done in the right direction. I applaud the team but I do get the feeling that a lot of this is because people want to contribute, but the team really wants to hand craft this. And that's great
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've thought about using email and pi, as then the responses can be email patches I can inspect and it's easier to keep multiple threads going. But I've also thought that XMPP makes sense too, and is slightly easier to connect to a VPN rather than setting up mail.
Out of curiosity, do you use the pi-xmpp[1] extension or do you have your own?
[1]: https://pi.dev/packages/pi-xmpp
Initially I was using that extension but I ran into its limitations pretty quickly. Sometimes the agent wouldn't reply over XMPP, it didn't have any support for typing indicators or status messages, and it had no way to support inter-agent communication, the agent could only ever speak to the configured owner account. I also had no way of running system commands like /new over XMPP.
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
Thank you, that is very useful for my use case. Pi has transformed so much of my daily task, this will boost it a bit more. Much appreciated.
Thanks!
Same here, though I use Matrix and only have two agents. One for me, one for the family. They are mostly for household management tasks, but mine has an ssh key that lets it remote in to some of my servers and deal with stuff.
That said, I really don’t like “developing” over chat. I’d much rather wait until I’m really available to inspect diffs properly and watch all the thinking and tool use, real time.
https://github.com/pkulak/nix/tree/main/modules/features/ope...
If I wanted to be inspecting diffs I would tell it to put up a PR and then i'd review it in the GitHub app.
> NixOS is the key to all of this, since agents can interact see the whole server config
We added native support for nixos for the same reason - malleability and debugging becomes easier (also because one of our customers asked us to). I think we might be the only sandbox provider to add this in warm pools.
Interesting setup. Would you still have chosen a Wiki vs a folder of md files if all agents were using a shared filesystem / compute environment (eg personal computer)? I see Wikis often mentioned as shared state stores and I’m trying to figure out what makes people reach for them.
When I say wiki I mean a folder of md files in a git repo. I only say wiki because it uses [[wikilink]] style links. Proper wiki software would be massively overkill for a project like this.
Would that have any real advantage over some "basic" setup (eg tmux running codex, and accessing it through SSH on the phone with Termius)?
I've been able to do 80% of what I needed to do remotely with that setup, so wondering if a more complex setup would really add much...
Pi and XMPP is excellent
Yes they fit well together. The XMPP clients I've used have great protocol interaction but the UIs have been surprisingly janky. There are so many messaging apps to steal design cues from, yet the "popular" open source clients haven't really done this. I've started my own forks for converse.js and conversations.im to add some UI polish.
Funny that the XMPP clients has taken more of my time than the pi XMPP wrapper itself.
Interesting, I would be interested to read more about your setup and workflow
I plan to do a writeup once I've got a few more of the kinks out with consistent cross agent comms. Message routing happens in-band right now, not too big a problem since 95% of the messages are DMs to me but once I'm running more in parallel I'm sure they'll have some more cross agent communication issues.
This is cool, I'll have to try this.
Want I've been doing for transit is using termux on android with magisk for root access, allowing me to install Nix home manager and harnesses on my phone, and then drive everything from my phone, including eternal terminal sessions to my homes erver, where it spins up agents there as well.
Incidentally it's also great for debugging issues with my phone.
I’m going to go against the grain and say that Pi is a little too minimal by default. The emacs comparison is interesting, but default Pi is like emacs that can load files but you’ve got to extend it manually to save or search within a file.
I’d argue that there’s a minimal set of functions that a coding harness needs to just enable a model to get stuff done, and they shouldn’t be an extra effort to set up.
(Oh-my-pi exists for those of a similar persuasion.)
Philosophically, pi.dev is exactly what I'm looking for. Minimalist and explicit (YOLO by default, we know it can be trouble but we tell you so).
Anyone here using the Rust rewrite of pi.dev as their daily driver? It's endorsed by the author of pi.dev and looks pretty attractive to me being both minimalist and not having npm attached. Any info "from the trenches" are appreciated (setup with sandboxing, extra niceties etc).
Both Codex and Claude have trained their models to their harnesses.
There are some experimentations by Igor Warzocha to extract Codex shapes and put it in Pi: https://github.com/IgorWarzocha/howaboua-pi-stuff/tree/main/...
I'm expecting every model will have a fine tuned Pi extension at some point.
I’ve been using both families of models inside pi/piclaw (https://rcarmo.github.io/projects/piclaw/) and I assure you they work _better_ in that environment than in the originals. The models are not trained to the harnesses, the harnesses provide cues that the models follow.
You can see the approach in his post: https://howaboua.dev/writing/how-i-gave-pi-17-tools-without-...
The result: 38% fewer startup tokens, 17 tools exposed through just three schemas, and 19 skills loaded only when needed.
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?
The /tree feature is incredible for context management. It's really surprising the other harnesses haven't slurped it up yet. It lets you rewind back to any previous message and fork the conversation from there, removing your 'side quest' (e.g. where you dig into something the agent said) from the context. Some other harnesses have a 'rewind' feature, but this lets you maintain the previous conversation history in a separate thread, and even jump between them.
You can do that in Copilot in VSCode. There’s a fork icon before every message that creates a new session from that point. The relationships are not maintained in a tree though (not sure if Pi does that).
Claude code in the cli also has /fork to clone the current session state. But if you use it more than once or twice that quickly becomes hard to manage. Actual tracking in a tree sounds like an awesome feature (and one that I love in conversational UIs like openwebui as well)
You can fork a conversation in Claude as well.
I think cursor has this where you can fork a thread from a previous message
a few examples:
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)
A lot of harnesses compress the context when it becomes massive, Pi doesn't do that out of the box (EDIT: that's wrong, as pointed out below). It can be both good and bad. Also since it doesn't have a lot of tools out of the box, the context is not polluted with external tool call descriptions that the agent has to be aware of.
Basically, it doesn't handle the context "better", it barely does anything special to it, which can actually be better for cost efficiency.
Pi has auto compaction enabled by default:
https://pi.dev/docs/latest/compaction
Ok my bad. I remember hearing that it was a criticism of common harnesses and that the creator of Pi wanted more control over that feature, so I assumed it wasn't enabled by default. Thank for pointing it out !
It was introduced in late 2025:
https://github.com/earendil-works/pi/issues/92
That's not true, pi auto-compacts when getting close to the context window limit?
It's really just the minimal prompt and the minimal built-in skills. And ~full control I guess if you wire up something custom (I haven't).
They removed ~80% of Claude Code’s system prompt for Claude 5 models so the harness cost-per-task benchmark could be stale.
Pi does one thing that I love, developing a tool that has minimalism where it's easily configurable with good documentation. The leads to new use cases that the the author(s) would have never dreamed of. The organic growth process of the Pi ecosystem has been fascinating to observe. It's one of the reasons why Pi has become one of my favorite coding agents to this day, flexible beyond personal uses and extensible to larger environments.
IMO, I view it more than a coding agent, it's a coding agent platform with powerful extensibility.
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 don't really get this philosophy, at least with coding harnesses.
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.
I'm the opposite. I started out promising myself I'd install all those handy looking plugins (I had like 20 I wanted to try out). But I've been slippery sloped into building my own Pi extensions and reinventing the wheel many, many times. It's been months and I love it. I just keep discovering and learning, and forgetting, and doing it all over again. I've been building my own harnesses since before that word was so common though, even before Aider was released.
There are decent plugins for the essentials you’d find in other harnesses. Pi shines in opinionated things you won’t find elsewhere.
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
Other harnesses tend to have 20k tokens in their system prompt and too many tools, and that drags them down.
If you want something that's like every other harness then what's the point of considering pi? It's specifically for people who are dissatisfied with other harnesses.
Also, you can version control your tweaks and easily sync with other machines, just like any code.
If you like Emacs, why not make Emacs your harness?
https://github.com/karthink/gptel
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.
It's funny you say this, because as someone that rejected emacs (default editor was XEmacs on the Sun machines in my 90s CS computer lab) in favor of vim early. I think a big part of the appeal of vim for me is that it's a great editor just based on the defaults. Sure you can configure it but you don't need to. Emacs strength is customization, and that's what Pi feels like compared to batteries-included harnesses.
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 agree. Pi is more like NeoVim if we have to map to Vim/Emacs. Emacs is full (at least compared to Vim) of the hidden features you didn't know it had installed. Pi doesn't bundle any hidden features. A bog standard GNU Emacs install contains, what, like ~10 games, a mail reader, a web browser, RSS feed reader, a nd a Morse code decipher?
Even more so, Pi even has opinionated forks and "distributions" like oh-my-pi that are like LazyVim/AstroVim.
Pi is really good. For people who want to build their own agent with even more minimal and extensible, the underlying agent harness is also worth looking: https://github.com/earendil-works/pi/tree/main/packages/agen...
I'm enjoying the maximal version: https://omp.sh
OMP is great. I pair it with https://nono.sh/ and sleep alot easier at night.
OMP is great to get started with, there's a whole bunch of stuff in there but it's mostly optional and turned off by default (like the memory backend). You can always try it and create a custom Pi config with only the stuff that you find useful if it's too much.
I'm really enjoying the advisor mode (you can have a second model monitor the output of the primary model and have it "steer" the primary when it makes a mistake or goes off the rails) and the automatic fallback to a second provider if the primary one has issues (Deepseek had some issues yesterday).
I need to dive a bit into the system prompt to see how much context OMP actually adds. I think the system prompt is still 2-3k tokens but that probably depends on bells and whistles.
I find omp funny because it's the opposite of why Iike Pi.
It’s more like a curated config. Like using Astro or Lunar instead of starting with a plain Neovim and crafting your own configuration.
It goes further than that. I mean, it has a bash interpreter natively linked into it.
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.
Subagents are good when the harness (And agent?) understand how smart they are.
My root level CLAUDE.md has pretty much just "use a lower tier agent when relevant".
Then I daily-drive Opus, it automatically offloads simpler stuff to Sonnet or even Haiku based its own reasoning because it "knows" their capabilities.
It's so much more cost/token efficient to do it like this. Opus writes the exact implementation plan for Sonnet and then waits for it to complete. After that it checks the work and fixes any issues itself.
In Codex, for example, this doesn't work because the whole system doesn't know about agent tiers and barely can use subagents. So I'm just running Sol all the time.
> Are subagents basic? I found them only useful in very few situations.
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?
I started out using OpenCode with subagents. Then, after switching to Pi, went completely subagentless, usually on the current frontier GPT model.
I didn't notice any significant change in context usage, and tasks were completed faster. That surprised me, I'm still not sure (not an expert on this), but maybe the handoff boundary was the problem. When the main model gives an isolated task to the subagent, the latter goes wild producing a comprehensive report, trying to satisfy every possibility. Without the handoff, the main model does the job much more precisely and conservatively, checks only specific/narrow things, and stops sooner.
Recently I decided to reintroduce 2 subagents to see how it goes. First was to have a cheaper model drive my real Safari browser instead of using agent-browser and the like. Second, to see if having a cheaper model navigate/search my file system helps in any way.
I think there's some benefit to having a cheap model drive Safari, because there's so much unavoidable garbage produced in that interaction. The filesystem one I don't think I see any benefit, just a lot of unnecessary work that (albeit cheap) wastes more time.
Of course I'm eyeballing this, not benchmarking formally, but I see so many people just onboard these mindlessly. Are you sure that you saw a real improvement in the produced outcomes/timing, or was it based on seeing subagents do a lot of stuff and assuming that the main model would've been doing the same at higher cost?
I admit that subagents may have great benefits, but I wouldn't treat it as just out-of-the-box basic feature that always improves your outcomes.
You don't actually need those features. Initially I began using Pi thinking I would customize the hell out of it. I've installed one extension for guardrails and that's about it. I've been able to do everything I did before just with vanilla pi.
What extension do you use ? With all the supply chain attacks I am warry of adding extensions, so I wonder if there's like a go-to one that everyone uses
you can copy extensions rather than install them to avoid that problem
I couldn't agree more.
I think for indie hackers and people that build their own stack is great, but real scenario and people with money Enterprise likes the idea of batteries included.
I found this one a little bit better and they do support Extensions like Pi. But comes with all features like codex, claude code and it's open-source.
https://github.com/autohandai/code-cli
I've read this before. Marketing?
skills as memory is a great idea
I built https://rcarmo.github.io/projects/piclaw/ on top of pi largely leveraging its extension philosophy (I extended the contract to UI extensions, basically) and am very happy with the results. Even though I added a few more tools, the core agent is wonderful.
Are all of you pi users paying Anthropic and OpenAI for API usage? Or can you combine pi with a subscription?
So far API usage is a lot more expensive than subscription and if you need better models than Deepseek and Kimi, and you are not wealthy, I don’t see a way around this.
You can also use PI with local models like Qwen3.5-35B-A3B [1] and they can be surprisingly good if you development in minimalistic/simple ways.
One game changer when it comes to tweaking configs that are optimized for your use case is that you can easily use a "more powerful" cloud model to identify a good enough config for your local server/pi settings combination [2] in a pattern that applies pretty much anywhere.
- [1] https://huggingface.co/Qwen/Qwen3.5-35B-A3B
- [2] https://alexhans.github.io/posts/find-the-loop-story-first.h...
You can use both providers in Pi using subscriptions. Be careful with Anthropic though, it’s against their TOS.
Doesn’t using the Anthropic subscription this way get charged as extra usage, and thus effectively billed at API rates?
They had plans to do that for CLaude SDK and claude -p usage, but paused them indefinitely.
Not if you run your own system prompt that does not explicitly contain the term "pi coding agent". Perhaps they string-match against some other stuff, too, but as long as you paraphrase the system prompt a bit, you should be fine.
I use my Anthropic subscription with Pi. I thought they would start charging me API usage at some point, but it never happened. (If it did happen, I would switch to open weights models.)
Oh, I stand corrected. It's been a while since I've used their models.
Glad we can still use OpenAI subscription through Pi.
If using outside of subscriptions, It is almost a no brainer to use this simple because of the efficiency. With subscriptions, not so good. Even the officially endorsed OpenAI integration lacks support for server-side context compaction (without a separate plugin which still triggers the pi native compaction).
I added that in https://rcarmo.github.io/projects/piclaw a few weeks back. The reason it’s not in pi-ai is that server-side OpenAI compaction is encrypted/opaque and (at least in my experience) can cause issues when switching models.
I think for indie hackers and people that build their own stack is great, but real scenario and people with money Enterprise likes the idea of batteries included.
I found this one a little bit better and they do support Extensions like Pi. But comes with all features like codex, claude code and it's open-source.
https://github.com/autohandai/code-cli
What it hints at is the direction of model agnostic and custom agents. I could see companies using Pi to create a product for orgs, for example. Low cost and closer to the customer needs than a general harness.
This seems like a more natural use of agents than asking them to one shot and push to prod. Give them a measurable objective, let them experiment, and judge the outcome instead of the implementation. Similar to how you would deal with a junior or intern basically
I love Pi . I have been building an agent using its agent harness https://github.com/earendil-works/pi/tree/main/packages/agen... . I love the simplicity .
Pi’s minimalism reveals a simple truth: the LLM is the core of any agent harness. Consequently, much of current harness tuning will become redundant(or even a hindrance) with next-gen models.
I always thought that the frontier coding models were specifically trained to perform well in the harness from their providers. I imagine this will always be the case to some extent.
From what I understand pre-training is totally irrelevant to this and as far as post training goes there will be multiple steps, for claude and codex and the like that ship with a harness, the harness is definitely included in evaluation. However, they will definitely include evaluation from a variety or even none, and settle on something that works the "best" for a release.
Disclaimer: No first hand knowledge
Yes, and the article makes the point that this might be changing.
I like Pi, but I didn't end up using it. I tried OpenCode, Pi, Zed Editor and some NVIM packages. I wanted open source, featureful and easy to use. Specifically I wanted to easily edit the agent prompt.
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.
And I thought that this was going to be about the number PI
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.
Only thing that runs easily on termux now that gemini-cli has been discontinued..
Pi Agent has been one of my favorite harness when it comes to using with local models
I had a lot of success running it on my Mac with Qwen3.6-35B-A3B model
If someone has never used Pi, what's a good starting point where someone took Pi and started adding some extensions etc to get to that minimal-but-useful-and-productive-for-coding state? Is there such recipe/writeup?
Just install Pi and start using it directly, no extensions needed for Pi to get the job done.
Only when you genuinely find a feature is missing should you write one yourself or have Pi write an extension or skill for you.
Don't use extensions written by others, after all, those extensions were also vibe-coded.
You can just fire it up and ask it to suggest some, or look on the site at the most downloaded and see which sound useful to you. That's basically what I did. I also put in some work to containerize it and do some manual/automatic checks to lock down extensions a bit, but that's just me.
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.
It's already in that minimal but useful state so you can just start and ask it to write code.
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.
Mario recommends you don't do that.
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?
I love using Pi and its design philosophy. The minimalism is what resonates with me. It just works, update after update.
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.
Yeah, but the future will essentially be building extensions for agents. Agents will become the new web browser and extensions will be the new apps. We are already seeing the early stages of this.
how many extensions do you need for browsing the web? Adblocker. Not much else because the browser already does the important work.
Same with any of the off the shelf harnesses.
Go build something useful instead of tweaking the minutiae of the harness.
Pi is awesome. I built whole agentic ide on top of pi and obsidian. The fact that I can modify it easily makes a difference
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 also found re context window: less is more
at least with GPT 5.6 Sol fwiw
https://smolenv.com/t/nested-template-includes-60636/
sh is all you need
Can file edits be erroneous?
Do you use smol? How do you find it compares to other harnesses for things like MCP connections? I’m tempted to use it since I’m a fan of the philosophy.
I use it for smaller changes (no compaction yet)
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 didn't realize you were the author. Super cool! I'll be trying it out.
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'm glad there are quite a few good open source ones by now.
Also happy with how much love codex gets from OpenAI.
That said: I was looking at existing agents to find one to build upon and to me they were all too complex and were leaning too heavily into 3rd party dependencies.
Nothing I could understand comfortably in an afternoon (that's also on me I guess). Pi was closest to what I was looking for but still too big and too modular.
(It's hard to come up with good abstractions that work well across all major models + keep up with new concepts that come and go all the time with new releases.)
The more complex agents err on the side of supporting many models 'ok' instead of focusing on taking advantage of a specific model.
With a tiny implementation it is easier to adapt it.
Adding new stuff, removing stuff again, changing it from working well specifically with GPT 5.6 Sol to working with the exact model I want.
https://swival.dev remains my favorite agent for local models.
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...
But wouldn’t Tau be twice as good as Pi?
It already is, to the point I’ve forked it https://rcarmo.github.io/projects/tau-prime and am playing with bolting on my “standard” web UI onto it.
I built Fusion (software factory) on top of Pi and have been thrilled with it https://github.com/Runfusion/Fusion
+1
#teampi
I found the nice part of Pi was the plugin system and the ability to hook into any part of the agentic loop. But minimalism is a net negative in my experience. What you really want is a harness that meets the expectations of the model and steers it in the right direction.
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.
https://yogthos.net/posts/2026-06-08-dirge-code.html
that website is horrendous to look at on an eink display btw
I use pi for agentic CI; reviews, etc.
It's so easy- npm install, a little markdown boot camp, and you get great results.
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 just run it as a separate Unix user. Good enough for me.
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.
You might appreciate https://nono.sh/
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.
My very first request, after reading this thread and deciding to try pi out--it went out of the app directory it started in, and made code edits to a sibling directory in a different git project repo.
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.
Yeah, I think Pi is good to use now because the AI has became so good that they almost can run on their own. Previously, AI agents do so many dumb and expected things that I really didn’t want to let them run on a loose leash and manual+automatic approval helped me steer them better. Even now, sometimes agents in Pi do things that startled me when I realized I didn’t explicitly approve that!
I don't really want to do approvals though. Either I put stuff into a real sandbox, or #yolo
Correct. pi.dev is not a minimal coding agent. It already comes with crazy amounts of preconceptions baked in.
For example, it comes with a bash tool built that you cannot disable. This is not minimal, it's the full kitchen sink. If I want to build a custom agent I have to literally stop using pi.dev and switch to something else.
So yeah, I fully disagree with the title. "Pi’s Minimalism Is Its Advantage" No. full stop. It's too bloated for me already. It's not minimal enough. If it's minimalism was its strength. it might not even need a sandbox, because it can't run bash commands or update files to begin with.
The secret here is giving pi its own user account on your machine, using Unix permissions.
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.
i really hope OpenCode v2 with the Effect internals can ascertain and realize and lock on to being the best extensibility platform, on to having a core that serves not just itself, it's conceits of/as product, but a wider world. a street that wants to "find it's own uses for things".
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!
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.
Mario talked about the Earendil transition in his blog post here: https://mariozechner.at/posts/2026-04-08-ive-sold-out/
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.