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.
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
Ignoring the military stuff, I feel like it is saying that this harness, although stamped from a mass produced part, is mine once I take possession of it. An extension of me?
My read sees pi as a starter kit. It's job is to build personal workflows and not to dictate a workflow. Copy on the site calls it minimal and tells us to 'adapt pi to your workflow, not the other way around.' In other words a fleshed out pi is unique to you.
> 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.
In my experience, the Rust community very much cares - it is a struggle to find a modern Rust application of any popularity that does not abide by XDG.
.cargo's placement is a historical mistake that can't be undone now, but ecosystem participants are generally good participants.
Not sure about use in the Go community at large but Go introduced os.UserConfigDir[1] which is portable across Windows, macOS, Plan 9 and Linux/BSD as per XDG back in 2019. Also CacheDir.
Ghostty has chosen to use that as the default and I feel like it's going to be the tipping point where people will assume $HOME/Library/Application Support is normal for CLI programs.
fwiw, it absolutely drives me nuts that cli programs are putting configs in that hard to reach folder (long path name and _spaces_ in the folder name ugh)
> 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'd also add that convenient recursive folder creation was only added relatively recent for many languages (eg: "std::filesystem::create_directories" was only added in C++17). And since "~/" is pretty much guaranteed to exist, the fewer folders you needed to create, the less code you had to write.
I think underuse/under-marketing of XDG_STATE_HOME is a contributing factor. Developers see XDG_DATA_HOME and XDG_CONFIG_HOME and, following the spec, don't feel like their app's files conform to either definition. It's easier to just not bother. Neovim now uses all 3 and it's very nice IMO.
The problem with the XDG spec is that it now forces you to have different paths on different platforms. It just increases the complexity and at the end of the day unless all software adheres to it, you still end up with a “polluted HOME”.
I’m not a fan of config directories being in different locations on different platforms because it’s now one extra thing everyone needs to handle.
(Disclaimer: I work on Pi but I dislike XDG in all settings)
Platform standards already require things to be in different locations compared to *NIX dotfiles and dotdirectories - for example Windows %APPDATA%.
I find it a bit shocking that someone working on an agent harness can't be bothered to spend 5 minutes to research this with the help of an LLM and holds such rigid and uninformed views.
And if you don't want to respect platform standards, just respect XDG on all platforms. The .app solution is the laziest one possible.
Just follow XDG everywhere and create .config/app & co everywhere, at least that way there's a chance more apps end up in subfolders instead of ending up with a million folders in the user directory on BOTH Linux and non-Linux.
I suspect some people are out there who actually like the single directory style. Obviously it's easier for the software developer, but I suspect some users like it too because everything's all in one place. It's very likely that Mario is one of those people.
I will say that even though I really don't like having a cluttered home folder, I do appreciate things being more or less in one place and so can be easily uninstalled and cleaned up. Flatsweep even being a thing is a testament to the tedium created by dispersing everything across the file system. It reminds me of macOS and not in a good way: I had an equivalent to Flatsweep on my old macbook but I couldn't remember its name so I searched "macos app cleanup tool", and the first page is just a bunch of comparison articles for the 10 (or whatever) best cleanup tools. This shouldn't be a thing. Alas, it is because applications can't or wont clean up after themselves.
Totally valid, and the Unix-style filesystem sprawl is definitely a pain sometimes. On the other hand, when an application does follow standards, you always know where something is, and just by looking at the name of the directory you know what's in there.
The other thing that's nice about the XDG standard is that it generally encourages developers to split binary state data, configuration, etc. even if you do it all within one folder, that's better (for the user) than jumbling it altogether in one big SQLite database or whatever.
It is a note that a lot of applications and even package managers are kind of moving back to the model you describe. For example Homebrew installs each package into its own prefix and symlinks into /opt/homebrew/bin,lib,etc...
I still don't like hard coding the MYAPP_HOME dir in ~/.myapp and prefer an environment variable to configure it. Personally I put all such folders into ~/.local/opt/$MYAPP if possible.
Written in C, tiny footprint, minimalist approach to system prompt and tools (yet essential batteries are included, for example - it has subagents with presets, and background bash tasks out of the box), high quality polished presentation, inspectable (usable transcript view), does not mess with terminal scrollback, respects XDG directory spec, etc.
Open source, MIT-licensed, no commercial agenda. A tool that I myself wanted, so I built it.
> 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.
Written in Go, compiled binary, respects XDG (e.g. uses ~/.config/crush to store config), etc. No Lua scripting, but it includes a skill to manage its own configuration.
It starts up for me in under a second on my M4 mac. (Obviously could be faster, but doesn't bother me personally on my hardware)
My one main "issue" is with using the pi-sandbox extension. It's based on a forked claude code sandbox runtime. Not exactly sure why a fork was needed, and the fork is a bit behind now. I also wish the sandbox feature worked a bit more like how Cursor's sandboxing worked. Not familiar with Claude Code sandboxing, so can't compare that. I describe the issue and a (slightly hacky, but productive enough) workaround here: https://github.com/carderne/pi-sandbox/issues/50
Obviously the fact that I can fork a plugin for pi and customize it as needed is quite a plus too. Really all the other features work quite well for me!
I don't get the XDG appeal of having all the data of an app scattered all over the home dir when I can just have a .dir of an app with everything inside.
Backups. If a program properly follows the spec I can just `rsync ~/.config/foo` or store it in a repo and not have to worry about it. If a program doesn't follow the spec I now have to write program specific filters for rsync/custom .gitignore entries to avoid backing up state and cache. Now multiply that across dozens of programs written by lazy devs who don't want to write 12 lines of code to determine the correct location for their files.
This exactly. My rsync patterns file is littered with dozens of edge cases to capture the configs and ignore state/caches of stuff that doesn't follow XDG. Really dislike the chore of double checking everything and adding new stuff to the list every time I take a backup.
Even worse are those that seemingly follow XDG but not really, like a lot of Electron apps, that just shove config, state and cache in ~/.config.... sigh
The minimal harness is the one you build yourself. Use pi to do it if you want. Getting something barebones takes less than an hour. Then you can extend it exactly how you want.
I personally also don't like this, so use cargo to install it, it's in the readme. Takes a reasonable time to build on my X220, but on a modern computer it is plenty fast.
Is there a meaningful security difference between curl-pipe-bash and cargo install --git? Couldn't the cargo install include a buildscript that jumps right into a shell?
Sure, but you can review the git repo's content/commits in plain text, while curl-pipe-bash would require you to reverse engineer the binary that's downloaded.
If somebody hacks the project's home page and switches the download location to a hacked binary, you'd be none the wiser. Of course, somebody could hack the repo and add a deliberate vulnerability as well, but at least you would have a trail of it.
Me too, maki in --yolo mode within an incus NixOS container, giving maki rootless (nested) podman and nix flakes powers (so it can install and run whatever tools it needs), with 100% ds4-flash it's extremely powerful and super cheap.
The fact that you can easily change the key bindings and $HOME and tons of other stuff by telling pi itself to go write an extension in 20 seconds(or just go customize one after forking it) is awesome, not because you can do it YOLO but because I could on-board faster with these and get to work ASAP.
I've been able to get near exactly the workflow I want: Navigate and search sessions, Delegated extensions that allow you to run deterministic code for sensitive operations like read, write and search-result inference, I have an extension to prune tool calls in batch mode: saves tons of context space on GPT-5.x trading off prompt prefix performance. And another one very similar to auto search mentioned in the blog. And the Tmux integration allows you to spin work trees in separate windows/panes.
I've never had a perf issue simply because harness interaction being a human in the loop process you(thinking and writing) are the bottleneck.
I'm building roughly this in Rust: single binary, XDG-native, with Landlock/seccomp, scoped filesystem access, default-deny egress, and policy-based approvals. https://github.com/vinhnx/VTCode
Here's some annoyances of my own that honestly baffle me:
- The command to exit the program is /quit, not /exit like literally everything else. If you type /exit, it'll get sent as a message to the AI. Apparently, /exit was an alias of /quit at some point, but was removed because it was simply too intuitive.
- It has terminal subcommands, such as `pi install` to install an extension. Any reasonable person would expect that `pi help` would give you a list of such commands. Nope! That actually starts it up and sends the message "help" to the AI. Amazing.
It's a common theme that most AI-generated or AI-adjacent software is full of nonsensical little decisions like this, that almost make it feel like it's not intended to be used by sane humans.
I'll take any scripting language over Lua any day. Every time I had to extend a tool that used Lua as a scripting language, I abandoned that tool because Lua was such a pain. I genuinely don't understand the praise it gets
I'd agree with you based on the language itself; Lua has some annoying idiosyncrasies like e.g. (my main pet peeve) 1-based indexing.
But I suspect the positive opinion on Lua stem more from the standardized environment the language is built around (i.e. how it is embedded into applications): If you don't explicitly pass capabilities like file handling etc. into the script, it CANNOT use them. Sooo many scripting languages get this wrong, it's actually embarassing.
1-based indexing is really a lame duck argument - if you can't get past that, you're simply being stubborn.
You absolutely can have tables indexed at 0 - what you cannot do, is fail to take responsibility for the use-patterns you apply to those tables, if you do so - and more specifically you have to take responsibility for the requirement that you use 0-based tables, instead of more optimal methods.
The table is an extraordinarily flexible type. You will gain immensely from using it properly - whether its the newbie dilemma over pairs()/ipairs(), or whether its the professional metatable manipulations - the power of this type is undeniable.
However, if you cannot get past the fact that you must learn it, and that it is applicable to your requirements in every single case, then you are for sure going to have a hard time.
Too much power + too little attention to important details = burnt fingers = endless whining. This is my personal stance having used Lua for decades now, professionally and personally, to do amazing things.
I have used Lua for years and love it, I don't have any issues with its features, and I've shipped many products with it, across a variety of use cases.
I genuinely understand however, that some people just don't get Lua, and have little energy for it.
However, I think it is awesome and every good software developer should have some experience with it. Whether it is a positive or negative one, you will learn a lot that will help you stay relevant in today's crazy software world.
I have similar sentiment but still haven't spent time to give it due process to come to good conclusion.
I tried the bare pi and now I am using oh my pi. At this point I feel that unless I am really concerned with maximizing token usage the Claude, Codex and Cursor cli are good enough. I think if you're looking for a reason to use pi versus you have a problem and pi is the solution than it's probably not a good fit.
I do think using it with open weight models may be worthwhile. I can see value with using it with a open router subscription. I have used opencode but I would rather standardize on it pi.
I've absolutely had the same experience. Pi has been praised a lot, people speaking so highly of it's code quality.
And then I installed it and found all the problems you mention. Not only that but I read Github Issues about the XDG problem and was a bit taken aback by the reaction of the developer.
It's one of the best agents I have used so far but I'm still looking for a very lightweight, token efficient agent NOT written in a JS framework and which respects XDG
C-p and C-n (aka Ctrl-P and Ctrl-N) are the Emacs-style keybindings for previous (line) and next (line), very commonly encountered on the command line and in terminal applications. For example, most shells can use this in addition to up-arrow and down-arrow to cycle thru command history. Many, many more examples exist of applications (not just terminal-based, there are plenty of GUI apps too) that use this convention, as well as other Emacs-style keybindings (e.g. C-a for beginning of line, C-e for end of line).
but also highly opinionated (no mcps, no agents.md, no system prompt, …)
so not sure it checks all of your boxes
that said: because smol is so smol you can adapt it easily and agents (including smol) can work well with it because the whole implementation fits comfortabliy into the context window
It's not 20 lines of Go because you decided to merge multiple lines of code into one. Why not advertise it as one line of code if you don't care about readability?
Edit: after reading my fork of smol, I realized it literally just feeds everything into bash, making it completely pointless.
Edit 2: I decided to read the readme instead and it raised a question
"Compare smol with Pi, OpenCode, Codex, Hermes, Claude Code and highlight key pros and cons. Audit the code of all of them and tell me how confident you are that you found all potential issues of smol vs the other agent implementations?"
After thinking about the difference between the original and my fork, I'm confident that smol has more problems than all of the agent harnesses combined and my fork has made an important step towards fixing one of those issues.
Edit 3: I hope the community can fork my version and add sensible variable names.
Edit 4: I can't decide whether this is the best satire of coding agents I've ever seen and I just ruined it or it is horrifying that someone even entertains the idea of publishing it.
I mean, you can't be serious, right? Think about the unintentional commentary you're making here.
You're saying it can be understood in an afternoon but it is intentionally obfuscated.
It might as well be proprietary code, but if it is proprietary code, you're actually making fun of all the coding agents for being a walking security nightmare, because in the end all they do is run bash and no amount of sandboxing or regexes will make bash secure.
So why not drop the pretenses and just expose the coding harnesses for what they are? Inscrutable bash executors that have the potential to go out of control.
your favorite agent will help you de-golf and analyze the implementation
I'm confident you can understand what it does (and does not do) and why in an afternoon
(probably in 20-30 minutes actually, even if you are not familiar with Go)
the same is way more difficult with larger agent implementations even if you only want to understand the direct implementation ignoring all the 3rd party dependencies that come with them
i guess what i'm saying is: it's not so hard to start with a minimal, well working agent and then only add exactly what you need instead of taking a more complex agent and then trimming it down or configuring it (and staying compatible with its continued development and deps)
pi is in YOLO mode by default. What the heck do you care if it's respecting XDG or not: this thing is not meant to be run in your main user directory with access to your secrets, bank accounts, emails, etc.
I couldn't care less about something that's meant to be run/discarded/re-created in a VM (or microVM or container) at will respecting XDG or not.
> For a program that's minimal it sure takes a long time to start up
It took the same amount of time (3 seconds) as cursor-agent and codex on my machine, which isn't particularly high-spec.
> the standard C-p and C-n bindings don't work
It has programmable keybindings and you can ask the agent to remap them in five minutes, if not 30 seconds.
> it doesn't follow the XDG Base Directory Specification and just pollutes my $HOME directory
You can make it put .pi/agent anywhere with $PI_CODING_AGENT_DIR in 10 seconds.
> scriptable in a simple (aka non-JS) scripting language
This doesn't make any sense. The very point of Pi is that instead of implementing all of your features directly in the harness, you make the harness minimal and then implement the functionality you want as extensions, which necessarily means that you have some powerful and expressive extension language, ideally the one the harness was written in.
I suspect that if the harness was written in Lua (which I love and is probably the least bad choice of "scripting" language), you would have far more issues with it.
If these are your complaints, then this is one of the strongest endorsements of Pi that I've ever seen. I think I'm bookmarking this comment.
A contrarian is "A person who likes or tends to express a contradicting viewpoint, especially from one held by a majority of people, usually because of nonconformity or spite."
The post I replied to is literally being contrarian:
> Lots of praise for Pi in this thread, so I'll offer up a diverging opinion.
Meanwhile, my post was not being contrarian in the slightest. I didn't offer a contradictory viewpoint - I provided factual information and context to dispel false claims/misinformation in the post I was responding to (e.g. the claim "the standard C-p and C-n bindings don't work" is highly misleading/false because you can trivially rebind them), and the opinions I provided were completely orthogonal to the opinion expressed ("I suspect that if the harness was written in Lua [...] you would have far more issues with it."
I expressed no opinion either for or against "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."
It always surprises me when someone so confidently makes an objectively incorrect statement when they could have spent 30 seconds looking up the definition of a word and realized that they were in the wrong.
> Being contrarian for the sake of it is not good form.
Why would you say that? Is it good form to post that someone is being contrarian for the sake of it? OP’s comment looks like constructive criticism with plenty of good points.
> It took the same amount of time (3.5 seconds) as cursor-agent and codex on my machine.
So what? Nobody is pretending that these are minimalist. Codex is 1.2M of Rust LOC.
> which necessarily means that you have some powerful and expressive extension language, ideally the one the harness was written in.
Don’t be silly, JS is a joke. I was going to check Pi out, but now that I know it’s based on a shitty stack, I’m staying the fuck away from it. I don’t have the RAM to spare.
> If these are your complaints, then this is one of the strongest endorsements of Pi that I've ever seen. I think I'm bookmarking this comment.
>> Being contrarian for the sake of it is not good form.
> Why would you say that?
Because it's true.
> Is it good form to post that someone is being contrarian for the sake of it?
It's orthogonal to good form - it's preserving the value of HN, which is meant for intellectual curiosity and not knee-jerk emotional reactions, like your comment.
> OP’s comment looks like constructive criticism with plenty of good points.
You must have missed the very first line in their comment where they said:
> Lots of praise for Pi in this thread, so I'll offer up a diverging opinion.
...which is literally admitting to being reflexively contrarian.
Additionally, their criticisms were extremely shallow and/or misleading, and I addressed every one.
> So what?
Nobody is inconvenienced by a 3.5s startup time of an application meant to run for hours or days. That's a trivial complaint akin to arguing about the color of paint on a bikeshed.
> Don’t be silly, JS is a joke. I was going to check Pi out, but now that I know it’s based on a shitty stack, I’m staying the fuck away from it. I don’t have the RAM to spare.
You're just operating based on emotion and not a state of reason or intellectual curiosity. And I highly doubt that you "were going to check Pi out" - this wording follows the pattern of fabricating falsehoods out rage due to an opinion expressed that you didn't like.
>> If these are your complaints, then this is one of the strongest endorsements of Pi that I've ever seen. I think I'm bookmarking this comment.
> For the record, I measure acceptable latency in milliseconds. I think it has something to do with my brain.
That's a personal preference thing. You're not really being inconvenienced.
> They’re very clearly stating that they’re expressing their opinion because it is underrepresented.
That's literally the dictionary definition of being contrarian:
"A person who likes or tends to express a contradicting viewpoint, especially from one held by a majority of people, usually because of nonconformity or spite."
I suggest consulting the dictionary before using terms you're not familiar with.
> No.
If you're going to copy-paste random pieces of text without making a point, you probably shouldn't be on HN. HN is for intellectual curiosity and debate, not Reddit-esque expressions of randomness conflated wuth humor.
- I regularly have 10+ instances of my harness running or idling on my laptop.
- My laptop is often at near-100% CPU and memory usage due to the (irreducible) cost of the development tools and environment.
- I often (50% of the time) downclock my laptop’s CPU to 1-2 GHz to save battery and/or reduce noise and thermals while charging.
- I sometimes run my harness on machines that are low-power, low-RAM single-board computers.
If my harness was written in JS, this would be both annoying in terms of responsiveness and limiting in terms of how much work I can do in parallel. This is why using JS for serious software is a... subpar decision.
> but then it also means you can't use Claude Code because it also runs on top of JS.
That's fair. I think with a lot of these harnesses they didn't really think people would be running so many instances of them at once
I think for claude code it really would be best if they made it native, but for plugins I think JS wins, because it's just a lot more easier for most to write plugins in that.
from my POV the performance used to be bad but it's pretty good now, every now and then though it'll start just growing in memory usage and needs to be restarted every now and then. so if you'd 10x that then I could see it really limiting workflows, especially with SBCs
The claims being made here are fallacious in three extremely basic ways.
First, "I regularly have 10+ instances of my harness running or idling on my laptop" implicitly asserts that you need that many instances running at once.
You don't. You can have a single instance running that handles your sessions in parallel.
Second, "I sometimes run my harness on machines that are low-power, low-RAM single-board computers." presumes the whole agent has to run on the SBC itself. It doesn't. There are agents (including Pi, which makes this even sillier) that can run their tool calls in a separate process/host, meaning that the agent can live on your development machine while the tiny tool-call daemon runs on the SBC.
Finally, "If my harness was written in JS, this would be both annoying in terms of responsiveness and limiting in terms of how much work I can do in parallel." could only be written out of a complete lack of understanding about how harnesses are actually implemented.
Agent harnesses don't do very much. The limiting factor is not the harness itself, but in the filesystem (reads, writes, file searches, greps), the computational tool calls (compilers, linters, evaluating the program), and the LLM API itself.
Your arguments against Javascript appear to be based on fallacies, lack of understanding of technology, and strong emotions against JS rather than actual fact.
This is getting silly, I can’t tell whether you are kidding, never launched a Node-based app, or never checked htop.
> that can run their tool calls in a separate process/host
That indeed seems like a simple and elegant setup. I can’t recall a single instance of using a harness when I didn’t want the tool calls to be local, though. Why would I be SSHing into a SBC just to run the agent back on my laptop?
> You can have a single instance running that handles your sessions in parallel.
Sounds even more elegant! Presumably, they communicate via HTTP?
> implicitly asserts that you need that many instances running at once.
I don’t need to, but I can. That’s the entire point, in case you’re still missing it.
> Your arguments against Javascript appear to be based on fallacies, lack of understanding of technology, and strong emotions against JS rather than actual fact.
> This is getting silly, I can’t tell whether you are kidding, never launched a Node-based app, or never checked htop.
You're very much operating based on emotion rather than reason. That's fine in general, but it's not OK for HN, which is not a place to blast out your emotions and try to assert that your opinion is factually true by getting maximally angry about it.
> That indeed seems like a simple and elegant setup. I can’t recall a single instance of using a harness when I didn’t want the tool calls to be local, though. Why would I be SSHing into a SBC just to run the agent back on my laptop?
You don't understand how harnesses work. Let me explain: in a harness, the tools that the harness provides are the only way for the agent to interact with its environment, and as such, if the harness is run on one host, and the tools on another, the agent's perspective is that it is running on the second host. This is effectively true modulo some small set of scenarios that are mostly irrelevant in the case of "I'm SSHing into an SBC" (e.g. the harness logic and LLM API calls would both be happening on the SBC, which you definitely don't want when you're resource-constrained).
> Sounds even more elegant! Presumably, they communicate via HTTP?
No. Why would you think that? Again, I don't think you understand how harnesses work.
> I don’t need to, but I can. That’s the entire point, in case you’re still missing it.
That's a useless point, if so, akin to saying "I want to have Vim running at address 0x00000001beef0000 in physical memory" - you're conflating use-case (needing a large number of agents running in parallel so you can work on things in parallel) with implementation detail (having a large number of separate processes running on your computer).
> How beautifully ironic.
I'm meeting every single one of your technical arguments and factual inaccuracies (e.g. your misunderstanding of the word "contrarian"), and you're continuing to get very angry at Javascript. I don't think there's any irony here.
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.
> 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.)
I disagree on plan and todo-list, which seem relatively not needed to me. No comment on goals/looping, which I don't have much experience with.
To me it's great how minimal the system prompt and tool set is, and I doubt those features are worth the tokens for every model. (Who knows if they improve performance for SOTA models, and they probably harm performance for small local models.)
I would add "better sandbox" support, which I think should be included out of the box. Not having a very simple way to get out of "yolo" mode is kinda crazy. Sure, there are plugins, but they do have some issues.
pi-bash-approval is good, but manual approval plus allowlist is a "bad" way to run coding agents.
The "best" way in my current opinion, is where commands run by default in a sandbox, but commands can be ran unsandboxed as needed, requiring approval or allow-list in that case. Cursor was pretty good at this (when I used it). For example I don't want to configure my sandbox with access to docker, which would present easy jailbreaks, but I do want to allowlist certain docker commands or approve them to run on my host as needed. pi-sandbox is good at allowing me to configure sandbox access, but this feature where somethings can run unsandboxed is missing. I write more about this and about (hacky, but productive enough) workaround here: https://github.com/carderne/pi-sandbox/issues/50
the thing is about some of these things, like sub-agents, is that any implementation of sub-agents is going to be extremely opinionated, so it would never make sense to be in pi out of the box.
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.
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)
Yes, pi's works a bit better since it exposes the whole tree to you, but in the simple case of forking to a new conversation it is about the same as Cursor and probably other coding agents.
One thing you can do in pi that you can't in Cursor: Have a 5-prompt conversation, jump back to prompt 3 and have a new conversation [call this convo2], then jump back to the original point 5, then jump back to convo2.
So fork is really only needed for when you need to interact with the conversation tree in two separate processes.
the compaction does not compact whole context, but keeps last ~20k tokens as is, I believe this helps a lot to model to not get confused what it is doing right now.
it also have soft/soft compaction limit, it tries to compact on turn boundary when possible. with combining with above this can get you about 35% more context (at least it looks like this with the sol)
codex when shell command is executed, will pull output with hard cap at max 30s, so for running compilation it will burn tokens without any benefit.
I have some tasks where agent will have to run some suite that can take over an hour, and codex burns about $20/h just waiting and reasoning every 30s "yep, that's still running". And what is going to happen after compaction, when whole context was just waiting? it will loose the plot and when I'm back it just does completely different thing that I asked it to do.
codex also have a bug, that opening refuses to resolve that adds your last steer after compaction, so imagine that you asked it to cleanup some tmp files or refactor/simplify something. it will do that again and again after each compaction, best case it just burns tokens and figures out, this is already done, or worse do it again and mess up everything and forget about it's task
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.
It’s failed every single time I’ve tried, and yes I’ve tried all the auto-compaction extensions :(
So unless it’s been fixed or someone knows a work around, Pi is DOA - I’ve found that on a MULTI tool call (ie one prompt firing off multiple tool calls until it prompts you again) that’s close to hitting the auto-compaction limit (default compactor or extension) it will either keep going until your context spills over and you OOM, or it interrupts itself to compact but then loses the context.
From reading issue after issue on GitHub, I think it’s because Pi doesn’t let extension writers (nor the built-in compactor) hook in between each tool call and so the only place to check if it can compact is when it finishes a request and is about to wait for the next prompt - too late by then
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 !
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.
in my experience pi does much better than codex for compaction and token use. And this is the main reason I switched to it.
migrating to the same compaction and exact tools as codex uses will make it at the same level as codex so what benefit will it have over codex? sure you can customize tui to your liking and add something on top, but the efficiency gains will be gone
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.
it depends on how you see things. By default OMP with all its options turned off is very much like Pi, just with a better UX/UI - and - a faster start, somehow. And you can turn things on when needed. I see people like Pi because it's super skinny and they can tweak it with extensions A, B or C. I like OMP because I don't have to spend time figuring out the next best thing while there is a guy out there who knows (more than me) what he is doing and packaging all the good stuff into his app. Yes it's opinionated, but I use regularly half of the installed extensions - and occasionally play with other features too.
But I can agree on a thing: the best for OMP would be to have a clear "list of extensions" that can be activated or deactivated (to unclutter the menus)
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.
> 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.
I found the new deepseek flash is so good I rarely have to pull out gpt sol anymore. if anything for coding tasks, gpt sol ends to go out of scope and I have to reign it in. Trying to keep my tasks managably small for human review is a endless battle with the frontier models.
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.
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.
Love pi. It's good to have a minimal agent, always welcome. Even if only to bootstrap install other agents. E.g. recently Hermes stopped installing under Termux (v0.19 - no, v0.18 - yes). Agent pi to the rescue: installed it under Termux (Android), started it, pointed pi to the Hermes github, asked for v0.18 specifically - and it did it. Cherry on the top - asked it to install a plugin from github I use (unmerged PR), did that too. Even if nowadays for coding I mostly use OMP (the pi with wheels and bells and whistles). For general computer use mostly use Hermes. Model-tied harnesses have their place e.g. Codex for me. I never know if it's allowed or banned using the sub from non-Codex harness - so stick with it. Even if only to have the 'canonical reference setup' to compare with and measure against.
I am starting to share the opinion in the article. I used to use Claude Code with strong open models, and sometimes pay for Opus.
Now one of my main drivers is out of the box pi’s 4 built in tools, and I add just two extra tools: pi-sandbox and a paid for search service tool. This setup works great with the latest deepseek v4 flash, switching to more powerful open models occasionally.
I wrote my own coding harness in Common Lisp that is almost free or 3rd party libraries and I basically copied pi + the 6 tools I use for pi (except I have two search tools using different vendors in my Common Lisp code).
Everyone (and every company?) should run their own tests and experiments. I find it sad when I talk with people who default to the most complex and the most expensive tools without even trying to evaluate alternatives.
A fundamental limitation of third-party harnesses is that they can't see all the data. As earendil pointed out, providers are now moving to encrypted thinking blocks.
As an example, this could affect compaction. If pi calls another agent to do the compacting, that agent can't read the encrypted thinking blocks. In contrast, if codex calls another openai-codex agent to do the compaction, they can feed that agent the thinking blocks. In theory, this additional information could be useful to the compacting agent. In practice, I don't think it helps too much right now. But I could see ways for providers to exploit this to drive a bigger wedge between their harnesses and pi.
This is interesting because of just how old-school SaaS it is. They're using old modes to build a wider moat around their product, hoping that it will keep their customers within it.
The AI boom feels different from the SaaS boom though because of all the different flavors of open that are available to people right now, from self-hosting your own stuff if you're a rich tinkerer to hooking up to OpenRouter or another service and getting your pick of models. I feel like some of the biggest providers are going to find themselves on the wrong side of the moat because, despite being massive innovators in their field they're monetizing it like they did in 2014.
I recently moved entirely to Pi, and I am really enjoying the journey so far.
I am slowly shaping it to the way I like to work. It's a bit of a bumpy start, but there are two benefits I see from it:
First is that you get to understand better what goes on behind the scenes. Since it is minimalistic, you have to think about your workflow, about what you want your agents to do, how you want them to do it, etc. It's a completely different way to work since tools like ClaudeCode do a lot of heavy lifting behind the scenes and just force on you their established way of doing things. By adding the building blocks yourself, you end up with a better understanding (and in many ways, control) of what is happening there.
Second, I adore how I can juggle sessions in Pi. /tree, /clone and /name quickly became second nature for me to manage agents. I am totally abusing prompt templates in my development workflows.
Also, it is an awesome harness for the models I use. DS and MiMo feel very snappy now, especially after I started to adapt Pi to my way of working. Lastly, even though those models are already cheap even on Claude Code, it feels like it is even cheaper now.
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 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.
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.
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.)
We are having a problem with namespace collisions. I really thought this was related to the Raspberry Pi (which is a very minimalist computer). Earlier today, I saw something about a Rio terminal and thought about Plan9.
We’ve been building atop the .agents standard and have written some tools around this under the ai-outfitter org few interesting repos.
- outfitter compose different agent profile w, eg skills, mcp, context and wrap pi,Claude,codex
- agent-operator run these agents into kubernetes
- actions run pi during investigations on failed ci or weekly updates
- channels give pi agents an inbox for slack/email/websocket access, calendar wake ups
- deepwork build long running workflows with verification gates
The best example of different profiles is having a prod/nonprod bot that has grafana mcp for incident investigation
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.
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.
Is there any good benchmarks for coding harness? In terms of tokens consumption, Pi is awesome..local model etc.
But regarding coding quality, task completion, over engineering, all related to the final result that the LLM is delivering trough the harness, is there any benchmark that shows the ups and downs of each one?
I'm struggling rotating harness because of a lack os a way to truly compared what is good or not.
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.
Sorry for negativity, but it wouldn't hurt to put some qualifier in the title, like, "Pi agent". So people, not interested in that theme can avoid your article. Thank you.
I was expecting an article about Pi constant or maybe raspberry Pi computer. "My Disappointment Is Immeasurable And My Day Is Ruined!"
When I first heard about pi.dev I was also initially confused.
Raspberry Pi is already very big in the hacker community... they really should not have named this harness "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 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 this seems pretty strange to me, I feel like I don't really care about messing around with all the tooling surrounding AI. I just want to get my actual work done. When I first moved to VS Code from Sublime Text I think I spent maybe 15 minutes setting up a few extensions like Emmet and then never really thought about it again - because I had actual work to do. I've just been waiting for all the constant change around AI coding to die down, assuming whatever is best will emerge and then I'll just use that.
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.
I do think that the value of these harnesses is inverse to the abilities of the frontier models - meaning - that as the models get smarter (by whatever benchmark you want to use) the harness matters less - it becomes more around context i.e. data.
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
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 is genuinely useful on its own. I have enjoyed discovering the things I want and adding them bit by bit.
I'm doing quite well with just a "todos" extension, and a "plan" prompt template (doesn't enforce read only tool usage, but prompts to build todos and discuss before doing anything).
I will probably try out some subagent systems soon, but I'm doing surprisingly well without them.
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 really like Pi and have recommended it to many people. It has been my daily driver for months and really changed my perspective on how to design tools. The `bash` tool is magic.
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.
Same experience, sometimes using Little Coder helps make things faster because it is built on pi and strips out some functionality. Probably best to stick with pi however, adding pi-sandbox for some security. I will only run Little Coder in an Apple Container.
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.
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.
I think banging on the "pi minimalism" thing is already old. Pi needs to have another dagger in its cachet. And frankly, I'm already tired of fighting Claude's lack of proper memory. So I guess I'm not-minimalism, but does that make me a maximalist?
I'm getting more development done with opencode, orca, and hermes. I do care about the harness though, as it extracts more juice from the rock model.
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.
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.
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.
I've been satisfied with using Pi inside of srt [0].
I launch with `srt pi` and get file system and network isolation. There is a seemingly infinite risk surface area to protect, but I think does a reasonable job of balancing security and convenience.
I've also heard good things about nono [1] from colleagues, but I haven't personally tried it out yet.
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!
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.
This is backwards. If you're a power user you want full control over all the tools granted to the agent and not let the agent bypass them by using bash. It's the people who don't want to customize anything that don't care about letting the agent go haywire and just run whatever bash commands it needs in a sandbox.
Think about why a sandbox is needed: Your permissions have been too loose. You now need to deal with the fallout of your decision externally. If all the agent was allowed to do is read your files and run cargo test, you wouldn't need a sandbox at all, the agent is the sandbox.
Now you might say, but what if it needs to modify files? If you wanted to build a sandbox or approval workflow here, you'd put it right into your custom write tool. It could be an extension you just download so you can pick your favorite write tool. Instead, the authors of pi.dev chose the worst possible defaults.
Unrelated to Pi (which is great) can we please stop using LoTR names for companies. The Peter Thiel glazing/cargo culting is pretty cringe at this point
Example of how easily humans are biased by the bubble they live in and start projecting assumptions everywhere (seemingly against their own interest).
Please provide evidence of relationship of pi/earendil to peter thiel.
I also suggest that if you believe peter thiel relationship with anything is a nuisance then - maybe - try avoiding gut-assigning links of anything in the world to him. you maybe see things in more positive light and it would be fairer to those things.
Peter thiel doesnt own tolkien work. The world is bigger than one mans bias
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.
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 might be misreading this, but I thought it was a reference to "Full Metal Jacket" => https://www.youtube.com/watch?v=YoU2hlDJmFE ?
Ignoring the military stuff, I feel like it is saying that this harness, although stamped from a mass produced part, is mine once I take possession of it. An extension of me?
My read sees pi as a starter kit. It's job is to build personal workflows and not to dictate a workflow. Copy on the site calls it minimal and tells us to 'adapt pi to your workflow, not the other way around.' In other words a fleshed out pi is unique to you.
Could you share some of the ecosystem/plugins/workflows you're using with Pi?
Sure, I use this, as pretty much my only plugin, I also have one for web-search on top of this. https://github.com/danielcherubini/pi-archimedes
as for workflows, its all skills/agents based, here's my dotagents folder
https://github.com/danielcherubini/dotagents
> 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
In my experience, the Rust community very much cares - it is a struggle to find a modern Rust application of any popularity that does not abide by XDG.
.cargo's placement is a historical mistake that can't be undone now, but ecosystem participants are generally good participants.
why can’t it be undone?
for new installations going forward, why not put the folder in XDG_CONFIG_DIR and an optional symlink from ~/.cargo that can be opted in
[flagged]
Not sure about use in the Go community at large but Go introduced os.UserConfigDir[1] which is portable across Windows, macOS, Plan 9 and Linux/BSD as per XDG back in 2019. Also CacheDir.
[1]: https://pkg.go.dev/os#UserConfigDir
> On Darwin, it returns $HOME/Library/Application Support
Which is not the behaviour most people would think is sensible, especially for CLI programs.
Ghostty has chosen to use that as the default and I feel like it's going to be the tipping point where people will assume $HOME/Library/Application Support is normal for CLI programs.
Mac users are used to checking ~/Library/Application Support/App, ~/.app, and ~/.local/config/app
fwiw, it absolutely drives me nuts that cli programs are putting configs in that hard to reach folder (long path name and _spaces_ in the folder name ugh)
Go isn't perfect, but $GOPATH isn't really used that much anymore. There's a bunch of stuff in ~/.config/ and ~/.cache/
Go creates `~/go` by default. It's not even hidden. Unfortunately, saying it's not really used that much doesn't help with this.
> 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'd also add that convenient recursive folder creation was only added relatively recent for many languages (eg: "std::filesystem::create_directories" was only added in C++17). And since "~/" is pretty much guaranteed to exist, the fewer folders you needed to create, the less code you had to write.
I think underuse/under-marketing of XDG_STATE_HOME is a contributing factor. Developers see XDG_DATA_HOME and XDG_CONFIG_HOME and, following the spec, don't feel like their app's files conform to either definition. It's easier to just not bother. Neovim now uses all 3 and it's very nice IMO.
The problem with the XDG spec is that it now forces you to have different paths on different platforms. It just increases the complexity and at the end of the day unless all software adheres to it, you still end up with a “polluted HOME”.
I’m not a fan of config directories being in different locations on different platforms because it’s now one extra thing everyone needs to handle.
(Disclaimer: I work on Pi but I dislike XDG in all settings)
Platform standards already require things to be in different locations compared to *NIX dotfiles and dotdirectories - for example Windows %APPDATA%.
I find it a bit shocking that someone working on an agent harness can't be bothered to spend 5 minutes to research this with the help of an LLM and holds such rigid and uninformed views.
And if you don't want to respect platform standards, just respect XDG on all platforms. The .app solution is the laziest one possible.
Just follow XDG everywhere and create .config/app & co everywhere, at least that way there's a chance more apps end up in subfolders instead of ending up with a million folders in the user directory on BOTH Linux and non-Linux.
I suspect some people are out there who actually like the single directory style. Obviously it's easier for the software developer, but I suspect some users like it too because everything's all in one place. It's very likely that Mario is one of those people.
it's certainly easier to keep a single directory under version control and share between Linux and macOS
Yeah but what happens when it's a mix of config and local state like logs and the app database?
Looking around my own cluttered home folder, the pattern seems to be that applications will split their "singlefolder" into a subtree.
For example:
- .sdkman has: bin, candidates, contrib, etc, ext, libexec, src, tmp, var
- .gitkraken has: logs, notif, profiles, repohooks, service, themes
- .mullvad-browser has: Downloads, .cache, .config, .local, .mullvad
- .dropbox has: events, instance1, instance_db, logs, machine_storage, metrics, ssa_events
- .steam has: bin, bin32, bin64, debian-installation, root, sdk32, sdk64, steam
- .xpipe has: cache, logs, settings, shell, storage, webview
...etc
I will say that even though I really don't like having a cluttered home folder, I do appreciate things being more or less in one place and so can be easily uninstalled and cleaned up. Flatsweep even being a thing is a testament to the tedium created by dispersing everything across the file system. It reminds me of macOS and not in a good way: I had an equivalent to Flatsweep on my old macbook but I couldn't remember its name so I searched "macos app cleanup tool", and the first page is just a bunch of comparison articles for the 10 (or whatever) best cleanup tools. This shouldn't be a thing. Alas, it is because applications can't or wont clean up after themselves.
Totally valid, and the Unix-style filesystem sprawl is definitely a pain sometimes. On the other hand, when an application does follow standards, you always know where something is, and just by looking at the name of the directory you know what's in there.
The other thing that's nice about the XDG standard is that it generally encourages developers to split binary state data, configuration, etc. even if you do it all within one folder, that's better (for the user) than jumbling it altogether in one big SQLite database or whatever.
It is a note that a lot of applications and even package managers are kind of moving back to the model you describe. For example Homebrew installs each package into its own prefix and symlinks into /opt/homebrew/bin,lib,etc...
I still don't like hard coding the MYAPP_HOME dir in ~/.myapp and prefer an environment variable to configure it. Personally I put all such folders into ~/.local/opt/$MYAPP if possible.
As in, $HOME? Version controlling it needs to be done very carefully.
As a user I still prefer .pi right there in my home directory.
i raised a bug for this on the pi repo. it was immediately triaged into `wont do`.
I am working on an agent implementation that you might like: https://github.com/OleksandrChekhovskyi/hax
Written in C, tiny footprint, minimalist approach to system prompt and tools (yet essential batteries are included, for example - it has subagents with presets, and background bash tasks out of the box), high quality polished presentation, inspectable (usable transcript view), does not mess with terminal scrollback, respects XDG directory spec, etc.
Open source, MIT-licensed, no commercial agenda. A tool that I myself wanted, so I built it.
> 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.
Have you looked at Crush (https://github.com/charmbracelet/crush)?
Written in Go, compiled binary, respects XDG (e.g. uses ~/.config/crush to store config), etc. No Lua scripting, but it includes a skill to manage its own configuration.
> standard C-p and C-n bindings don't work
I know it's little, but this was the first thing I noticed and it made me think, "Maybe this app isn't for me."
EDIT: FWIW, I just complained to pi and it added the keybinds for me in 10 seconds.
There is a keybindings file. Here's how to configure the "emacs" keybindings https://pi.dev/docs/latest/keybindings#emacs-example
It starts up for me in under a second on my M4 mac. (Obviously could be faster, but doesn't bother me personally on my hardware)
My one main "issue" is with using the pi-sandbox extension. It's based on a forked claude code sandbox runtime. Not exactly sure why a fork was needed, and the fork is a bit behind now. I also wish the sandbox feature worked a bit more like how Cursor's sandboxing worked. Not familiar with Claude Code sandboxing, so can't compare that. I describe the issue and a (slightly hacky, but productive enough) workaround here: https://github.com/carderne/pi-sandbox/issues/50
Obviously the fact that I can fork a plugin for pi and customize it as needed is quite a plus too. Really all the other features work quite well for me!
I don't get the XDG appeal of having all the data of an app scattered all over the home dir when I can just have a .dir of an app with everything inside.
Backups. If a program properly follows the spec I can just `rsync ~/.config/foo` or store it in a repo and not have to worry about it. If a program doesn't follow the spec I now have to write program specific filters for rsync/custom .gitignore entries to avoid backing up state and cache. Now multiply that across dozens of programs written by lazy devs who don't want to write 12 lines of code to determine the correct location for their files.
This exactly. My rsync patterns file is littered with dozens of edge cases to capture the configs and ignore state/caches of stuff that doesn't follow XDG. Really dislike the chore of double checking everything and adding new stuff to the list every time I take a backup.
Even worse are those that seemingly follow XDG but not really, like a lot of Electron apps, that just shove config, state and cache in ~/.config.... sigh
Not exactly what youre looking for but im working on a lot of these ideas with https://wingman.actor
The minimal harness is the one you build yourself. Use pi to do it if you want. Getting something barebones takes less than an hour. Then you can extend it exactly how you want.
I'm using maki (https://maki.sh), it has 1, 2 and 3.
I just wish it wouldn't ask me to pipe an install script directly to shell to install.
Yes, I can probably inspect that but I do think installing through package managers is the best practice.
It looks better than pi with XDG and not being JS but that is it's own red flag for me.
I personally also don't like this, so use cargo to install it, it's in the readme. Takes a reasonable time to build on my X220, but on a modern computer it is plenty fast.
Is there a meaningful security difference between curl-pipe-bash and cargo install --git? Couldn't the cargo install include a buildscript that jumps right into a shell?
Sure, but you can review the git repo's content/commits in plain text, while curl-pipe-bash would require you to reverse engineer the binary that's downloaded.
If somebody hacks the project's home page and switches the download location to a hacked binary, you'd be none the wiser. Of course, somebody could hack the repo and add a deliberate vulnerability as well, but at least you would have a trail of it.
You can review the contents of the git repo before building it.
For curl | bash, you cannot. “But you can pipe to a fil—“ nope: https://tferdinand.net/en/why-curl-bash-is-a-dangerous-bad-h...
Me too, maki in --yolo mode within an incus NixOS container, giving maki rootless (nested) podman and nix flakes powers (so it can install and run whatever tools it needs), with 100% ds4-flash it's extremely powerful and super cheap.
The fact that you can easily change the key bindings and $HOME and tons of other stuff by telling pi itself to go write an extension in 20 seconds(or just go customize one after forking it) is awesome, not because you can do it YOLO but because I could on-board faster with these and get to work ASAP.
I've been able to get near exactly the workflow I want: Navigate and search sessions, Delegated extensions that allow you to run deterministic code for sensitive operations like read, write and search-result inference, I have an extension to prune tool calls in batch mode: saves tons of context space on GPT-5.x trading off prompt prefix performance. And another one very similar to auto search mentioned in the blog. And the Tmux integration allows you to spin work trees in separate windows/panes.
I've never had a perf issue simply because harness interaction being a human in the loop process you(thinking and writing) are the bottleneck.
I'm building roughly this in Rust: single binary, XDG-native, with Landlock/seccomp, scoped filesystem access, default-deny egress, and policy-based approvals. https://github.com/vinhnx/VTCode
Here's some annoyances of my own that honestly baffle me:
- The command to exit the program is /quit, not /exit like literally everything else. If you type /exit, it'll get sent as a message to the AI. Apparently, /exit was an alias of /quit at some point, but was removed because it was simply too intuitive.
- It has terminal subcommands, such as `pi install` to install an extension. Any reasonable person would expect that `pi help` would give you a list of such commands. Nope! That actually starts it up and sends the message "help" to the AI. Amazing.
It's a common theme that most AI-generated or AI-adjacent software is full of nonsensical little decisions like this, that almost make it feel like it's not intended to be used by sane humans.
I'll take any scripting language over Lua any day. Every time I had to extend a tool that used Lua as a scripting language, I abandoned that tool because Lua was such a pain. I genuinely don't understand the praise it gets
I'd agree with you based on the language itself; Lua has some annoying idiosyncrasies like e.g. (my main pet peeve) 1-based indexing.
But I suspect the positive opinion on Lua stem more from the standardized environment the language is built around (i.e. how it is embedded into applications): If you don't explicitly pass capabilities like file handling etc. into the script, it CANNOT use them. Sooo many scripting languages get this wrong, it's actually embarassing.
1-based indexing is really a lame duck argument - if you can't get past that, you're simply being stubborn.
You absolutely can have tables indexed at 0 - what you cannot do, is fail to take responsibility for the use-patterns you apply to those tables, if you do so - and more specifically you have to take responsibility for the requirement that you use 0-based tables, instead of more optimal methods.
The table is an extraordinarily flexible type. You will gain immensely from using it properly - whether its the newbie dilemma over pairs()/ipairs(), or whether its the professional metatable manipulations - the power of this type is undeniable.
However, if you cannot get past the fact that you must learn it, and that it is applicable to your requirements in every single case, then you are for sure going to have a hard time.
Too much power + too little attention to important details = burnt fingers = endless whining. This is my personal stance having used Lua for decades now, professionally and personally, to do amazing things.
I have used Lua for years and love it, I don't have any issues with its features, and I've shipped many products with it, across a variety of use cases.
I genuinely understand however, that some people just don't get Lua, and have little energy for it.
However, I think it is awesome and every good software developer should have some experience with it. Whether it is a positive or negative one, you will learn a lot that will help you stay relevant in today's crazy software world.
I have similar sentiment but still haven't spent time to give it due process to come to good conclusion.
I tried the bare pi and now I am using oh my pi. At this point I feel that unless I am really concerned with maximizing token usage the Claude, Codex and Cursor cli are good enough. I think if you're looking for a reason to use pi versus you have a problem and pi is the solution than it's probably not a good fit.
I do think using it with open weight models may be worthwhile. I can see value with using it with a open router subscription. I have used opencode but I would rather standardize on it pi.
I've absolutely had the same experience. Pi has been praised a lot, people speaking so highly of it's code quality.
And then I installed it and found all the problems you mention. Not only that but I read Github Issues about the XDG problem and was a bit taken aback by the reaction of the developer.
It's one of the best agents I have used so far but I'm still looking for a very lightweight, token efficient agent NOT written in a JS framework and which respects XDG
I don’t know what the standard C-p and C-n bindings are. Could you share?
The startup time is a known issue and scales badly with extensions. We’re aware of it but fixing it is tricky.
C-p and C-n (aka Ctrl-P and Ctrl-N) are the Emacs-style keybindings for previous (line) and next (line), very commonly encountered on the command line and in terminal applications. For example, most shells can use this in addition to up-arrow and down-arrow to cycle thru command history. Many, many more examples exist of applications (not just terminal-based, there are plenty of GUI apps too) that use this convention, as well as other Emacs-style keybindings (e.g. C-a for beginning of line, C-e for end of line).
Ctrl+P in most coding agents is bound to bringing up a command bar. You should be able to bind both hotkeys to the functionality you want already.
Naturally! Being able to use your tools how you want/what works best for you is fundamental in my opinion.
That's wrong. Both Claude Code and Codex have C-p/C-n as down/up.
I love Pi and right now I'm developing a project like Pi, focused only on local inferences. https://github.com/m4ns0ur/iris
nice, very minimal!
Pi but in Rust: https://github.com/Dicklesworthstone/pi_agent_rust
One look at that project and I'm already losing my mind
smol is ~20 lines of Go, uses only stdlib
but also highly opinionated (no mcps, no agents.md, no system prompt, …)
so not sure it checks all of your boxes
that said: because smol is so smol you can adapt it easily and agents (including smol) can work well with it because the whole implementation fits comfortabliy into the context window
https://github.com/smol-env/smol
It's not 20 lines of Go because you decided to merge multiple lines of code into one. Why not advertise it as one line of code if you don't care about readability?
Here is my fork of smol, by the way:
https://pastebin.com/imdWVrQ2
Edit: after reading my fork of smol, I realized it literally just feeds everything into bash, making it completely pointless.
Edit 2: I decided to read the readme instead and it raised a question
"Compare smol with Pi, OpenCode, Codex, Hermes, Claude Code and highlight key pros and cons. Audit the code of all of them and tell me how confident you are that you found all potential issues of smol vs the other agent implementations?"
After thinking about the difference between the original and my fork, I'm confident that smol has more problems than all of the agent harnesses combined and my fork has made an important step towards fixing one of those issues.
Edit 3: I hope the community can fork my version and add sensible variable names.
Edit 4: I can't decide whether this is the best satire of coding agents I've ever seen and I just ruined it or it is horrifying that someone even entertains the idea of publishing it.
> feeds everything into bash, making it completely pointless
here is a typical bench run with 9 runs and traces for opencode, pi and smol
you can look at every step and which tools are used and how
https://smolenv.com/t/nested-template-includes-60636/
sh is pretty versatile and composes well
pi also only has 4 tools (good!)
I think I'm done with trying to tear this apart.
I mean, you can't be serious, right? Think about the unintentional commentary you're making here.
You're saying it can be understood in an afternoon but it is intentionally obfuscated.
It might as well be proprietary code, but if it is proprietary code, you're actually making fun of all the coding agents for being a walking security nightmare, because in the end all they do is run bash and no amount of sandboxing or regexes will make bash secure.
So why not drop the pretenses and just expose the coding harnesses for what they are? Inscrutable bash executors that have the potential to go out of control.
your favorite agent will help you de-golf and analyze the implementation
I'm confident you can understand what it does (and does not do) and why in an afternoon
(probably in 20-30 minutes actually, even if you are not familiar with Go)
the same is way more difficult with larger agent implementations even if you only want to understand the direct implementation ignoring all the 3rd party dependencies that come with them
but I think what I want to say is: diy
no need to start from smol (even though I think it makes a decent starting point)
[dead]
i guess what i'm saying is: it's not so hard to start with a minimal, well working agent and then only add exactly what you need instead of taking a more complex agent and then trimming it down or configuring it (and staying compatible with its continued development and deps)
diy ftw
Pi is ok, but I dislike needing plugins to do anything useful. Subagents, MCP, /goal ... none of these things should be plugins.
pi is in YOLO mode by default. What the heck do you care if it's respecting XDG or not: this thing is not meant to be run in your main user directory with access to your secrets, bank accounts, emails, etc.
I couldn't care less about something that's meant to be run/discarded/re-created in a VM (or microVM or container) at will respecting XDG or not.
Why could you care less?
You gave an agent access to your really home directory?
lol
> Lots of praise for Pi in this thread, so I'll offer up a diverging opinion.
Being reflexively contarian is not what HN is for.
https://news.ycombinator.com/item?id=45530593
> For a program that's minimal it sure takes a long time to start up
It took the same amount of time (3 seconds) as cursor-agent and codex on my machine, which isn't particularly high-spec.
> the standard C-p and C-n bindings don't work
It has programmable keybindings and you can ask the agent to remap them in five minutes, if not 30 seconds.
> it doesn't follow the XDG Base Directory Specification and just pollutes my $HOME directory
You can make it put .pi/agent anywhere with $PI_CODING_AGENT_DIR in 10 seconds.
> scriptable in a simple (aka non-JS) scripting language
This doesn't make any sense. The very point of Pi is that instead of implementing all of your features directly in the harness, you make the harness minimal and then implement the functionality you want as extensions, which necessarily means that you have some powerful and expressive extension language, ideally the one the harness was written in.
I suspect that if the harness was written in Lua (which I love and is probably the least bad choice of "scripting" language), you would have far more issues with it.
If these are your complaints, then this is one of the strongest endorsements of Pi that I've ever seen. I think I'm bookmarking this comment.
This is an incredibly reflexively contrarian comment
This is factually false.
A contrarian is "A person who likes or tends to express a contradicting viewpoint, especially from one held by a majority of people, usually because of nonconformity or spite."
The post I replied to is literally being contrarian:
> Lots of praise for Pi in this thread, so I'll offer up a diverging opinion.
Meanwhile, my post was not being contrarian in the slightest. I didn't offer a contradictory viewpoint - I provided factual information and context to dispel false claims/misinformation in the post I was responding to (e.g. the claim "the standard C-p and C-n bindings don't work" is highly misleading/false because you can trivially rebind them), and the opinions I provided were completely orthogonal to the opinion expressed ("I suspect that if the harness was written in Lua [...] you would have far more issues with it."
I expressed no opinion either for or against "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."
It always surprises me when someone so confidently makes an objectively incorrect statement when they could have spent 30 seconds looking up the definition of a word and realized that they were in the wrong.
https://en.wiktionary.org/wiki/contrarian
https://dictionary.cambridge.org/dictionary/english/contrari...
https://www.merriam-webster.com/dictionary/contrarian
> It took the same amount of time (3 seconds) as cursor-agent and codex on my machine, which isn't particularly high-spec.
A simple CLI tool should start instantly and lazily load anything that can't be loaded instantly.
> Being contrarian for the sake of it is not good form.
Why would you say that? Is it good form to post that someone is being contrarian for the sake of it? OP’s comment looks like constructive criticism with plenty of good points.
> It took the same amount of time (3.5 seconds) as cursor-agent and codex on my machine.
So what? Nobody is pretending that these are minimalist. Codex is 1.2M of Rust LOC.
> which necessarily means that you have some powerful and expressive extension language, ideally the one the harness was written in.
Don’t be silly, JS is a joke. I was going to check Pi out, but now that I know it’s based on a shitty stack, I’m staying the fuck away from it. I don’t have the RAM to spare.
> If these are your complaints, then this is one of the strongest endorsements of Pi that I've ever seen. I think I'm bookmarking this comment.
> good form
>> Being contrarian for the sake of it is not good form.
> Why would you say that?
Because it's true.
> Is it good form to post that someone is being contrarian for the sake of it?
It's orthogonal to good form - it's preserving the value of HN, which is meant for intellectual curiosity and not knee-jerk emotional reactions, like your comment.
> OP’s comment looks like constructive criticism with plenty of good points.
You must have missed the very first line in their comment where they said:
> Lots of praise for Pi in this thread, so I'll offer up a diverging opinion.
...which is literally admitting to being reflexively contrarian.
Additionally, their criticisms were extremely shallow and/or misleading, and I addressed every one.
> So what?
Nobody is inconvenienced by a 3.5s startup time of an application meant to run for hours or days. That's a trivial complaint akin to arguing about the color of paint on a bikeshed.
> Don’t be silly, JS is a joke. I was going to check Pi out, but now that I know it’s based on a shitty stack, I’m staying the fuck away from it. I don’t have the RAM to spare.
You're just operating based on emotion and not a state of reason or intellectual curiosity. And I highly doubt that you "were going to check Pi out" - this wording follows the pattern of fabricating falsehoods out rage due to an opinion expressed that you didn't like.
>> If these are your complaints, then this is one of the strongest endorsements of Pi that I've ever seen. I think I'm bookmarking this comment.
>> good form
Did you forget to make a point here?
> Nobody is inconvenienced by a 3.5s startup time of an application meant to run for hours or days.
For the record, I measure acceptable latency in milliseconds. I think it has something to do with my brain.
> which is literally admitting to being reflexively contrarian.
They’re very clearly stating that they’re expressing their opinion because it is underrepresented.
> Did you forget to make a point here?
No.
> For the record, I measure acceptable latency in milliseconds. I think it has something to do with my brain.
That's a personal preference thing. You're not really being inconvenienced.
> They’re very clearly stating that they’re expressing their opinion because it is underrepresented.
That's literally the dictionary definition of being contrarian:
"A person who likes or tends to express a contradicting viewpoint, especially from one held by a majority of people, usually because of nonconformity or spite."
https://en.wiktionary.org/wiki/contrarian
https://dictionary.cambridge.org/dictionary/english/contrari...
https://www.merriam-webster.com/dictionary/contrarian
I suggest consulting the dictionary before using terms you're not familiar with.
> No.
If you're going to copy-paste random pieces of text without making a point, you probably shouldn't be on HN. HN is for intellectual curiosity and debate, not Reddit-esque expressions of randomness conflated wuth humor.
> you probably shouldn't be on HN. HN is for intellectual curiosity and debate, not Reddit-esque expressions of randomness conflated wuth humor.
Thank you for this beautiful insight. Just to clarify, you consider yourself an intellectually curious, HN-worthy individual?
I seriously don't get the hate for JS/TS. it's a lot more ergonomic than Lua.
just yesterday I saw someone claim they'd rather learn COBOL and use it than use JS
it's ridiculous imo.
the ram usage is one thing sure, but then it also means you can't use Claude Code because it also runs on top of JS.
so I guess we should all stop using Claude Code, right? cause it's "based on a shitty stack"
Consider this:
- I regularly have 10+ instances of my harness running or idling on my laptop.
- My laptop is often at near-100% CPU and memory usage due to the (irreducible) cost of the development tools and environment.
- I often (50% of the time) downclock my laptop’s CPU to 1-2 GHz to save battery and/or reduce noise and thermals while charging.
- I sometimes run my harness on machines that are low-power, low-RAM single-board computers.
If my harness was written in JS, this would be both annoying in terms of responsiveness and limiting in terms of how much work I can do in parallel. This is why using JS for serious software is a... subpar decision.
> but then it also means you can't use Claude Code because it also runs on top of JS.
Correct. I don’t use Claude Code.
That's fair. I think with a lot of these harnesses they didn't really think people would be running so many instances of them at once
I think for claude code it really would be best if they made it native, but for plugins I think JS wins, because it's just a lot more easier for most to write plugins in that.
from my POV the performance used to be bad but it's pretty good now, every now and then though it'll start just growing in memory usage and needs to be restarted every now and then. so if you'd 10x that then I could see it really limiting workflows, especially with SBCs
The claims being made here are fallacious in three extremely basic ways.
First, "I regularly have 10+ instances of my harness running or idling on my laptop" implicitly asserts that you need that many instances running at once.
You don't. You can have a single instance running that handles your sessions in parallel.
Second, "I sometimes run my harness on machines that are low-power, low-RAM single-board computers." presumes the whole agent has to run on the SBC itself. It doesn't. There are agents (including Pi, which makes this even sillier) that can run their tool calls in a separate process/host, meaning that the agent can live on your development machine while the tiny tool-call daemon runs on the SBC.
Finally, "If my harness was written in JS, this would be both annoying in terms of responsiveness and limiting in terms of how much work I can do in parallel." could only be written out of a complete lack of understanding about how harnesses are actually implemented.
Agent harnesses don't do very much. The limiting factor is not the harness itself, but in the filesystem (reads, writes, file searches, greps), the computational tool calls (compilers, linters, evaluating the program), and the LLM API itself.
Your arguments against Javascript appear to be based on fallacies, lack of understanding of technology, and strong emotions against JS rather than actual fact.
This is getting silly, I can’t tell whether you are kidding, never launched a Node-based app, or never checked htop.
> that can run their tool calls in a separate process/host
That indeed seems like a simple and elegant setup. I can’t recall a single instance of using a harness when I didn’t want the tool calls to be local, though. Why would I be SSHing into a SBC just to run the agent back on my laptop?
> You can have a single instance running that handles your sessions in parallel.
Sounds even more elegant! Presumably, they communicate via HTTP?
> implicitly asserts that you need that many instances running at once.
I don’t need to, but I can. That’s the entire point, in case you’re still missing it.
> Your arguments against Javascript appear to be based on fallacies, lack of understanding of technology, and strong emotions against JS rather than actual fact.
How beautifully ironic.
> This is getting silly, I can’t tell whether you are kidding, never launched a Node-based app, or never checked htop.
You're very much operating based on emotion rather than reason. That's fine in general, but it's not OK for HN, which is not a place to blast out your emotions and try to assert that your opinion is factually true by getting maximally angry about it.
> That indeed seems like a simple and elegant setup. I can’t recall a single instance of using a harness when I didn’t want the tool calls to be local, though. Why would I be SSHing into a SBC just to run the agent back on my laptop?
You don't understand how harnesses work. Let me explain: in a harness, the tools that the harness provides are the only way for the agent to interact with its environment, and as such, if the harness is run on one host, and the tools on another, the agent's perspective is that it is running on the second host. This is effectively true modulo some small set of scenarios that are mostly irrelevant in the case of "I'm SSHing into an SBC" (e.g. the harness logic and LLM API calls would both be happening on the SBC, which you definitely don't want when you're resource-constrained).
> Sounds even more elegant! Presumably, they communicate via HTTP?
No. Why would you think that? Again, I don't think you understand how harnesses work.
> I don’t need to, but I can. That’s the entire point, in case you’re still missing it.
That's a useless point, if so, akin to saying "I want to have Vim running at address 0x00000001beef0000 in physical memory" - you're conflating use-case (needing a large number of agents running in parallel so you can work on things in parallel) with implementation detail (having a large number of separate processes running on your computer).
> How beautifully ironic.
I'm meeting every single one of your technical arguments and factual inaccuracies (e.g. your misunderstanding of the word "contrarian"), and you're continuing to get very angry at Javascript. I don't think there's any irony here.
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.
> 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.
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 for sharing this! It is so much smoother than the vibe coded monstrosity I had been using.
Thanks!
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.
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.
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.
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...
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.
at this point, what's the advantage of this setup vs something like hermes?
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.
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.
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.
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.
If you like Emacs, why not make Emacs your harness?
https://github.com/karthink/gptel
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.)
What is that set of functions for you?
I can't offer a definitive list. But some/all of web access, web search, sub-agents, plan, goals, looping, and maybe a to-do list.
I'd suggest the default should be anything that makes the model more efficient or effective to a reasonable current level.
I disagree on plan and todo-list, which seem relatively not needed to me. No comment on goals/looping, which I don't have much experience with.
To me it's great how minimal the system prompt and tool set is, and I doubt those features are worth the tokens for every model. (Who knows if they improve performance for SOTA models, and they probably harm performance for small local models.)
I would add "better sandbox" support, which I think should be included out of the box. Not having a very simple way to get out of "yolo" mode is kinda crazy. Sure, there are plugins, but they do have some issues.
pi-bash-approval is good, but manual approval plus allowlist is a "bad" way to run coding agents.
The "best" way in my current opinion, is where commands run by default in a sandbox, but commands can be ran unsandboxed as needed, requiring approval or allow-list in that case. Cursor was pretty good at this (when I used it). For example I don't want to configure my sandbox with access to docker, which would present easy jailbreaks, but I do want to allowlist certain docker commands or approve them to run on my host as needed. pi-sandbox is good at allowing me to configure sandbox access, but this feature where somethings can run unsandboxed is missing. I write more about this and about (hacky, but productive enough) workaround here: https://github.com/carderne/pi-sandbox/issues/50
the thing is about some of these things, like sub-agents, is that any implementation of sub-agents is going to be extremely opinionated, so it would never make sense to be in pi out of the box.
Are you sure those tools make the model more efficient?
No.
But:
web access, web search --> basically essential at this point
plan, goals, looping --> necessary if this is how you work, and working like this is probably (arguably?) more efficient
to-do list --> IME seems to help efficiency with local agents if they utilise it, but this is totally subjective
sub-agents --> who knows
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.
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)
Double escape in other coding agents
I think cursor has this where you can fork a thread from a previous message
Yes, pi's works a bit better since it exposes the whole tree to you, but in the simple case of forking to a new conversation it is about the same as Cursor and probably other coding agents.
One thing you can do in pi that you can't in Cursor: Have a 5-prompt conversation, jump back to prompt 3 and have a new conversation [call this convo2], then jump back to the original point 5, then jump back to convo2.
So fork is really only needed for when you need to interact with the conversation tree in two separate processes.
You can fork a conversation in Claude as well.
Only at the current point in the conversation though, right? You can't rewind and then fork from a previous message, as far as I know
[dead]
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)
the compaction does not compact whole context, but keeps last ~20k tokens as is, I believe this helps a lot to model to not get confused what it is doing right now.
it also have soft/soft compaction limit, it tries to compact on turn boundary when possible. with combining with above this can get you about 35% more context (at least it looks like this with the sol)
codex when shell command is executed, will pull output with hard cap at max 30s, so for running compilation it will burn tokens without any benefit.
I have some tasks where agent will have to run some suite that can take over an hour, and codex burns about $20/h just waiting and reasoning every 30s "yep, that's still running". And what is going to happen after compaction, when whole context was just waiting? it will loose the plot and when I'm back it just does completely different thing that I asked it to do.
codex also have a bug, that opening refuses to resolve that adds your last steer after compaction, so imagine that you asked it to cleanup some tmp files or refactor/simplify something. it will do that again and again after each compaction, best case it just burns tokens and figures out, this is already done, or worse do it again and mess up everything and forget about it's task
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
It’s failed every single time I’ve tried, and yes I’ve tried all the auto-compaction extensions :(
So unless it’s been fixed or someone knows a work around, Pi is DOA - I’ve found that on a MULTI tool call (ie one prompt firing off multiple tool calls until it prompts you again) that’s close to hitting the auto-compaction limit (default compactor or extension) it will either keep going until your context spills over and you OOM, or it interrupts itself to compact but then loses the context.
From reading issue after issue on GitHub, I think it’s because Pi doesn’t let extension writers (nor the built-in compactor) hook in between each tool call and so the only place to check if it can compact is when it finishes a request and is about to wait for the next prompt - too late by then
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).
It doesn't do anything unique WRT context management. It's just much less opinionated.
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.
The changing header is really distracting when trying to read your blog. Then it followed me when I scrolled and I just gave up.
Not my blog :)
It's pretty much what I do as well, piclaw has had selective tool activation since... March, I think.
in my experience pi does much better than codex for compaction and token use. And this is the main reason I switched to it.
migrating to the same compaction and exact tools as codex uses will make it at the same level as codex so what benefit will it have over codex? sure you can customize tui to your liking and add something on top, but the efficiency gains will be gone
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 depends on how you see things. By default OMP with all its options turned off is very much like Pi, just with a better UX/UI - and - a faster start, somehow. And you can turn things on when needed. I see people like Pi because it's super skinny and they can tweak it with extensions A, B or C. I like OMP because I don't have to spend time figuring out the next best thing while there is a guy out there who knows (more than me) what he is doing and packaging all the good stuff into his app. Yes it's opinionated, but I use regularly half of the installed extensions - and occasionally play with other features too.
But I can agree on a thing: the best for OMP would be to have a clear "list of extensions" that can be activated or deactivated (to unclutter the menus)
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.
[dead]
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 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.
> 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.
I found the new deepseek flash is so good I rarely have to pull out gpt sol anymore. if anything for coding tasks, gpt sol ends to go out of scope and I have to reign it in. Trying to keep my tasks managably small for human review is a endless battle with the frontier models.
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.
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
Love pi. It's good to have a minimal agent, always welcome. Even if only to bootstrap install other agents. E.g. recently Hermes stopped installing under Termux (v0.19 - no, v0.18 - yes). Agent pi to the rescue: installed it under Termux (Android), started it, pointed pi to the Hermes github, asked for v0.18 specifically - and it did it. Cherry on the top - asked it to install a plugin from github I use (unmerged PR), did that too. Even if nowadays for coding I mostly use OMP (the pi with wheels and bells and whistles). For general computer use mostly use Hermes. Model-tied harnesses have their place e.g. Codex for me. I never know if it's allowed or banned using the sub from non-Codex harness - so stick with it. Even if only to have the 'canonical reference setup' to compare with and measure against.
I am starting to share the opinion in the article. I used to use Claude Code with strong open models, and sometimes pay for Opus.
Now one of my main drivers is out of the box pi’s 4 built in tools, and I add just two extra tools: pi-sandbox and a paid for search service tool. This setup works great with the latest deepseek v4 flash, switching to more powerful open models occasionally.
I wrote my own coding harness in Common Lisp that is almost free or 3rd party libraries and I basically copied pi + the 6 tools I use for pi (except I have two search tools using different vendors in my Common Lisp code).
Everyone (and every company?) should run their own tests and experiments. I find it sad when I talk with people who default to the most complex and the most expensive tools without even trying to evaluate alternatives.
A fundamental limitation of third-party harnesses is that they can't see all the data. As earendil pointed out, providers are now moving to encrypted thinking blocks.
As an example, this could affect compaction. If pi calls another agent to do the compacting, that agent can't read the encrypted thinking blocks. In contrast, if codex calls another openai-codex agent to do the compaction, they can feed that agent the thinking blocks. In theory, this additional information could be useful to the compacting agent. In practice, I don't think it helps too much right now. But I could see ways for providers to exploit this to drive a bigger wedge between their harnesses and pi.
This is interesting because of just how old-school SaaS it is. They're using old modes to build a wider moat around their product, hoping that it will keep their customers within it.
The AI boom feels different from the SaaS boom though because of all the different flavors of open that are available to people right now, from self-hosting your own stuff if you're a rich tinkerer to hooking up to OpenRouter or another service and getting your pick of models. I feel like some of the biggest providers are going to find themselves on the wrong side of the moat because, despite being massive innovators in their field they're monetizing it like they did in 2014.
They removed ~80% of Claude Code’s system prompt for Claude 5 models so the harness cost-per-task benchmark could be stale.
I recently moved entirely to Pi, and I am really enjoying the journey so far.
I am slowly shaping it to the way I like to work. It's a bit of a bumpy start, but there are two benefits I see from it:
First is that you get to understand better what goes on behind the scenes. Since it is minimalistic, you have to think about your workflow, about what you want your agents to do, how you want them to do it, etc. It's a completely different way to work since tools like ClaudeCode do a lot of heavy lifting behind the scenes and just force on you their established way of doing things. By adding the building blocks yourself, you end up with a better understanding (and in many ways, control) of what is happening there.
Second, I adore how I can juggle sessions in Pi. /tree, /clone and /name quickly became second nature for me to manage agents. I am totally abusing prompt templates in my development workflows.
Also, it is an awesome harness for the models I use. DS and MiMo feel very snappy now, especially after I started to adapt Pi to my way of working. Lastly, even though those models are already cheap even on Claude Code, it feels like it is even cheaper now.
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 don't remember endorsing any rust rewrite of pi.
Ok, I'm a dummy: https://github.com/Dicklesworthstone/pi_agent_rust
"pi_agent_rust is a from-scratch Rust port of Pi Agent by Mario Zechner (made with his blessing!)."
It's pi, not pi.dev
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
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 is the new enterprise trend (RAG? no, we need our own pi plugin/adaptation).
It’s interesting. Many ways these things will be optimised. Just at the beginning !
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?
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.
That's hilarious
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.)
...funnily enough, a few hours after posting this, it stopped working.
Oh, I stand corrected. It's been a while since I've used their models.
Glad we can still use OpenAI subscription through Pi.
They had plans to do that for CLaude SDK and claude -p usage, but paused them indefinitely.
openai works well with subscription, as many non major providers subscriptions
I use OpenRouter, currently Kimi K3 which has been extremely effective.
[dead]
We are having a problem with namespace collisions. I really thought this was related to the Raspberry Pi (which is a very minimalist computer). Earlier today, I saw something about a Rio terminal and thought about Plan9.
We’ve been building atop the .agents standard and have written some tools around this under the ai-outfitter org few interesting repos.
- outfitter compose different agent profile w, eg skills, mcp, context and wrap pi,Claude,codex - agent-operator run these agents into kubernetes - actions run pi during investigations on failed ci or weekly updates - channels give pi agents an inbox for slack/email/websocket access, calendar wake ups - deepwork build long running workflows with verification gates
The best example of different profiles is having a prod/nonprod bot that has grafana mcp for incident investigation
Meta: this reads like a corporate article, info-selling a solution to enterprises. The style is a far cry from anything Mario or Armin usually write.
First indication of business strategy around Pi's reverse acquisition of Earendil, perhaps?
The first indication was them adding telemetry to Pi right after the acquisition.
I built Fusion (software factory) on top of Pi and have been thrilled with it https://github.com/Runfusion/Fusion
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.
even if they are is no guarantee that for 'your' specific tasks is beneficial in any means
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.
[dead]
Is there any good benchmarks for coding harness? In terms of tokens consumption, Pi is awesome..local model etc.
But regarding coding quality, task completion, over engineering, all related to the final result that the LLM is delivering trough the harness, is there any benchmark that shows the ups and downs of each one?
I'm struggling rotating harness because of a lack os a way to truly compared what is good or not.
One recent example but also quite specific to Kimi K3 can be found here https://xcancel.com/composio/status/2083161873357111297
it's very difficult and time-consuming to make good comparisons (especially for open ended tasks) also because there are so many configuration options
etc etcalso you kinda have to look at many runs and study their traces, if you look at too few runs the outcome variability you're drawing from is too high
Feels like a problem where you have to quantify/test for your own use-case. Otherwise just go by the generic SWE-bench scores etc.
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.
https://swival.dev remains my favorite agent for local models.
Sorry for negativity, but it wouldn't hurt to put some qualifier in the title, like, "Pi agent". So people, not interested in that theme can avoid your article. Thank you.
I was expecting an article about Pi constant or maybe raspberry Pi computer. "My Disappointment Is Immeasurable And My Day Is Ruined!"
I'm very excited about pi.dev but naming it Pi when there are people like me who've got seven Raspberry Pi around is just... Confusing.
To me there's pi, the constant. Then there's "a pi": a Raspberry Pi. Now there's "pi, the agent" too.
It gets confusing.
Especially if you use pi on a Pi to write code that uses pi.
When I first heard about pi.dev I was also initially confused. Raspberry Pi is already very big in the hacker community... they really should not have named this harness "Pi".
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 .
I love using Pi and its design philosophy. The minimalism is what resonates with me. It just works, update after update.
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 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 this seems pretty strange to me, I feel like I don't really care about messing around with all the tooling surrounding AI. I just want to get my actual work done. When I first moved to VS Code from Sublime Text I think I spent maybe 15 minutes setting up a few extensions like Emmet and then never really thought about it again - because I had actual work to do. I've just been waiting for all the constant change around AI coding to die down, assuming whatever is best will emerge and then I'll just use that.
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.
You don't need any extensions to use Pi. You can get far without any.
I do think that the value of these harnesses is inverse to the abilities of the frontier models - meaning - that as the models get smarter (by whatever benchmark you want to use) the harness matters less - it becomes more around context i.e. data.
Small model-facing surface, more responsibility in the harness. I'm exploring that tradeoff in Rust with VT Code: https://github.com/vinhnx/VTCode
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
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 is genuinely useful on its own. I have enjoyed discovering the things I want and adding them bit by bit.
I'm doing quite well with just a "todos" extension, and a "plan" prompt template (doesn't enforce read only tool usage, but prompts to build todos and discuss before doing anything).
I will probably try out some subagent systems soon, but I'm doing surprisingly well without them.
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 really like Pi and have recommended it to many people. It has been my daily driver for months and really changed my perspective on how to design tools. The `bash` tool is magic.
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...
Under 1,000 tokens for the system prompt and tool defs is the number that matters here. Everything else is downstream of not crowding the context.
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.
re: overloaded naming
Anyone else think "Pi" was a bad naming choice? raspberry pi was already big in the hacker community
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
Same experience, sometimes using Little Coder helps make things faster because it is built on pi and strips out some functionality. Probably best to stick with pi however, adding pi-sandbox for some security. I will only run Little Coder in an Apple Container.
Haven’t heard about little corer but I’ll give it a try
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
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.
We are just moving towards simpler an simpler agent setups. The harness moat will dissapear
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.
Only thing that runs easily on termux now that gemini-cli has been discontinued..
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
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.
Can file edits be erroneous?
yes but GPT 5.6 Sol is pretty good at editing files via sh (e.g. using python)
I also see codex do it that way quite often
and at the same time Opus struggles with using the edit tool in Claude Code even though model and harness are by the same company
I think banging on the "pi minimalism" thing is already old. Pi needs to have another dagger in its cachet. And frankly, I'm already tired of fighting Claude's lack of proper memory. So I guess I'm not-minimalism, but does that make me a maximalist?
I'm getting more development done with opencode, orca, and hermes. I do care about the harness though, as it extracts more juice from the rock model.
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.
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.
[dead]
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.
you can just use the --tools flag to disable bash tool
The secret here is giving pi its own user account on your machine, using Unix permissions.
It doesn't do auto approval.
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.
I've been satisfied with using Pi inside of srt [0].
I launch with `srt pi` and get file system and network isolation. There is a seemingly infinite risk surface area to protect, but I think does a reasonable job of balancing security and convenience.
I've also heard good things about nono [1] from colleagues, but I haven't personally tried it out yet.
[0] https://github.com/anthropic-experimental/sandbox-runtime
[1] https://github.com/nolabs-ai/nono
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
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.
This is backwards. If you're a power user you want full control over all the tools granted to the agent and not let the agent bypass them by using bash. It's the people who don't want to customize anything that don't care about letting the agent go haywire and just run whatever bash commands it needs in a sandbox.
Think about why a sandbox is needed: Your permissions have been too loose. You now need to deal with the fallout of your decision externally. If all the agent was allowed to do is read your files and run cargo test, you wouldn't need a sandbox at all, the agent is the sandbox.
Now you might say, but what if it needs to modify files? If you wanted to build a sandbox or approval workflow here, you'd put it right into your custom write tool. It could be an extension you just download so you can pick your favorite write tool. Instead, the authors of pi.dev chose the worst possible defaults.
Power users don't want sandboxing and security??
You have a wildly different understanding of what a power user is...
Or you could do any of the things they suggest in their documentation: https://pi.dev/docs/latest/security#running-untrusted-or-unm...
It's not like there isn't competition in this space.
Like I said, it's okay if you need those things. Pi might not be for your use-case and that's okay, too.
I find pi-sandbox works well for me. Did you evaluate pi-sandbox? If not, give it a try.
I just run it as a separate Unix user. Good enough for me.
It would be funny if suckless.org had a harness.
I use pi for agentic CI; reviews, etc.
It's so easy- npm install, a little markdown boot camp, and you get great results.
Unrelated to Pi (which is great) can we please stop using LoTR names for companies. The Peter Thiel glazing/cargo culting is pretty cringe at this point
To paraphrase Office Space - Why should we change names? He's the one who sucks.
Example of how easily humans are biased by the bubble they live in and start projecting assumptions everywhere (seemingly against their own interest).
Please provide evidence of relationship of pi/earendil to peter thiel.
I also suggest that if you believe peter thiel relationship with anything is a nuisance then - maybe - try avoiding gut-assigning links of anything in the world to him. you maybe see things in more positive light and it would be fairer to those things.
Peter thiel doesnt own tolkien work. The world is bigger than one mans bias
+1
#teampi
And I thought that this was going to be about the number PI
name your product pi
become ~~ungovernable~~ ungooglable
that website is horrendous to look at on an eink display btw
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!
[flagged]
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.