Pi's Minimalism Is Its Advantage
earendil.com476 points by luispa 17 hours ago
476 points by luispa 17 hours ago
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
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
> 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
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.
> 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.
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.
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 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.
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.
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
i raised a bug for this on the pi repo. it was immediately triaged into `wont do`.
> 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.
> 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
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 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.
Not exactly what youre looking for but im working on a lot of these ideas with https://wingman.actor
> 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'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.
cargo install --locked --git https://github.com/tontinton/maki.git makiIs 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.
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
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'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
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'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 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.
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
I love Pi and right now I'm developing a project like Pi, focused only on local inferences. https://github.com/m4ns0ur/iris
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
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
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:
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)
Pi is ok, but I dislike needing plugins to do anything useful. Subagents, MCP, /goal ... none of these things should be plugins.
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.
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?
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.
Out of curiosity, do you use the pi-xmpp[1] extension or do you have your own?
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.
> 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.
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.
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.
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...
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.
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.
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.
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’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.
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.
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)
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
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:
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’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
That's not true, pi auto-compacts when getting close to the context window limit?
It doesn't do anything unique WRT context management. It's just much less opinionated.
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).
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.
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.
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.
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.
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.
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...
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
They removed ~80% of Claude Code’s system prompt for Claude 5 models so the harness cost-per-task benchmark could be stale.
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.
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 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.
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.
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).
Small model-facing surface, more responsibility in the harness. I'm exploring that tradeoff in Rust with VT Code: https://github.com/vinhnx/VTCode
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.
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?
I think for indie hackers and people that build their own stack is great, but real scenario and people with money Enterprise likes the idea of batteries included.
I found this one a little bit better and they do support Extensions like Pi. But comes with all features like codex, claude code and it's open-source.
What it hints at is the direction of model agnostic and custom agents. I could see companies using Pi to create a product for orgs, for example. Low cost and closer to the customer needs than a general harness.
This is the new enterprise trend (RAG? no, we need our own pi plugin/adaptation).
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.
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.
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.)
They had plans to do that for CLaude SDK and claude -p usage, but paused them indefinitely.
Oh, I stand corrected. It's been a while since I've used their models.
Glad we can still use OpenAI subscription through Pi.
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.
It would be funny if suckless.org had a harness.
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.
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
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.
it's very difficult and time-consuming to make good comparisons (especially for open ended tasks) also because there are so many configuration options
- which env do you provide?
- which model(s)?
- subagents?
- system prompt (default or custom?)?
- agents.md
also 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
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
even if they are is no guarantee that for 'your' specific tasks is beneficial in any means
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 .
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
We built our first version of our in-app agent with opencode, but we're probably going to switch to Pi. Fundamentally, Pi is the shape of the thing that should exist, and it's awesome to see that it works. Very satisfying to my engineering brain. Been having fun with ohmypi as my personal harness, but going to switch over to pi soon and just mess around with it until it works the way I want. The idea of completely personalized software is so cool and now that it's finally possible I am having so much fun.
Haven't heard of ohmypi, thanks! I feel like this is a good starting point for someone like me who is not ready to configure a harness from zero right now.
I love hacking away at pi extensions.
I realised how use case dependent harness behaviour is when I tried to use my customised-for-a-side-project pi config at work and realised I needed to tweak it significantly to be useful - I would not be surprised if tools like Claude Code needing to be all things for all people is hurting their peak usefulness.
End up building Pi extensions instead of actual product.
Doesn't make sense to me, but to each their own.
Yeah, but the future will essentially be building extensions for agents. Agents will become the new web browser and extensions will be the new apps. We are already seeing the early stages of this.
how many extensions do you need for browsing the web? Adblocker. Not much else because the browser already does the important work.
Same with any of the off the shelf harnesses.
Go build something useful instead of tweaking the minutiae of the harness.
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.
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.
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 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.
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.
I love using Pi and its design philosophy. The minimalism is what resonates with me. It just works, update after update.
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
Only thing that runs easily on termux now that gemini-cli has been discontinued..
Pi has the best code out of all coding agents. The only problem is it’s not as fully featured and some of its modules should be factored out into their own code base.
I 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.
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
name your product pi
become ~~ungovernable~~ ungooglable
Honestly I think the thing I love most about Pi is that I'm not dealing with a tool with a thousand undiscovered features. I either pick and install what I want from the package ecosystem or I bottle up my own workflows into extensions as I find what works best for me.
The result is that the tool gradually morphs into the thing I need rather than me having to adapt myself to whatever new thing Anthropic or OpenAI comes up with.
I can also feel confident that the thing it becomes is what I actually need and not what maximizes token usage...
But wouldn’t Tau be twice as good as Pi?
It already is, to the point I’ve forked it https://rcarmo.github.io/projects/tau-prime and am playing with bolting on my “standard” web UI onto it.
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 built Fusion (software factory) on top of Pi and have been thrilled with it https://github.com/Runfusion/Fusion
+1
#teampi
I found the nice part of Pi was the plugin system and the ability to hook into any part of the agentic loop. But minimalism is a net negative in my experience. What you really want is a harness that meets the expectations of the model and steers it in the right direction.
There are also a ton of small mechanical things a harness can handle that make the whole process much smoother. A really simple example is auto balancing parens. Even frontier models like Claude still struggle with this. Often the model will end up writing a python script to figure out where the mismatch is, and then generate a new version of the code. All of that simply wastes tokens and eats up context on a task that could've been accomplished completely mechanically.
The approach I took with dirge, is to put the model in a loop where it has clearly defined tasks, and the harness handles any repairs that can be done automatically. And I used Janet to provide a plugin system based on what Pi is doing. You get a batteries included experience out of the box, and you can customize it to fit a specific project using plugins if needed.
I use pi for agentic CI; reviews, etc.
It's so easy- npm install, a little markdown boot camp, and you get great results.
And I thought that this was going to be about the number PI
that website is horrendous to look at on an eink display btw
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.
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
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.
I find pi-sandbox works well for me. Did you evaluate pi-sandbox? If not, give it a try.
My very first request, after reading this thread and deciding to try pi out--it went out of the app directory it started in, and made code edits to a sibling directory in a different git project repo.
opencode has never done that.
I'm allured by the minimalism, so I didn't quit there, but I'm not keen on letting it loose with vague instructions, that's for sure.
Yeah, I think Pi is good to use now because the AI has became so good that they almost can run on their own. Previously, AI agents do so many dumb and expected things that I really didn’t want to let them run on a loose leash and manual+automatic approval helped me steer them better. Even now, sometimes agents in Pi do things that startled me when I realized I didn’t explicitly approve that!
I don't really want to do approvals though. Either I put stuff into a real sandbox, or #yolo
The secret here is giving pi its own user account on your machine, using Unix permissions.
Correct. pi.dev is not a minimal coding agent. It already comes with crazy amounts of preconceptions baked in.
For example, it comes with a bash tool built that you cannot disable. This is not minimal, it's the full kitchen sink. If I want to build a custom agent I have to literally stop using pi.dev and switch to something else.
So yeah, I fully disagree with the title. "Pi’s Minimalism Is Its Advantage" No. full stop. It's too bloated for me already. It's not minimal enough. If it's minimalism was its strength. it might not even need a sandbox, because it can't run bash commands or update files to begin with.
This is also by design. Pi assumes you’re a power user and you know what you you’re doing and what you want. If sandboxing and the security that Claude and codex offer is something you truly need, pi might not be for you and that’s okay.
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.
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]
[dead]
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.