Rendered at 08:34:13 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
pavo-etc 8 hours ago [-]
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.
pkulak 2 hours ago [-]
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.
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.
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.
zrail 6 hours ago [-]
Thanks!
darkteflon 3 hours ago [-]
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.
pavo-etc 2 hours ago [-]
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.
mkagenius 4 hours ago [-]
> 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.
sroerick 2 hours ago [-]
Pi and XMPP is excellent
pavo-etc 2 hours ago [-]
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.
jdthedisciple 3 hours ago [-]
Interesting, I would be interested to read more about your setup and workflow
pavo-etc 3 hours ago [-]
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.
colordrops 1 hours ago [-]
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.
whazor 1 hours ago [-]
Both Codex and Claude have trained their models to their harnesses.
I'm expecting every model will have a fine tuned Pi extension at some point.
rcarmo 40 minutes ago [-]
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.
The result: 38% fewer startup tokens, 17 tools exposed through just three schemas, and 19 skills loaded only when needed.
carlsborg 42 minutes ago [-]
They removed ~80% of Claude Code’s system prompt for Claude 5 models so the harness cost-per-task benchmark could be stale.
swingboy 7 hours ago [-]
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?
timwis 3 hours ago [-]
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.
veber-alex 16 minutes ago [-]
You can fork a conversation in Claude as well.
paldepind2 1 hours ago [-]
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).
anon7000 2 hours ago [-]
I think cursor has this where you can fork a thread from a previous message
tosh 5 hours ago [-]
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
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)
4 hours ago [-]
TheRoque 6 hours ago [-]
A lot of harnesses compress the context when it becomes massive, Pi doesn't do that out of the box (EDIT: that's wrong, as pointed out below). It can be both good and bad. Also since it doesn't have a lot of tools out of the box, the context is not polluted with external tool call descriptions that the agent has to be aware of.
Basically, it doesn't handle the context "better", it barely does anything special to it, which can actually be better for cost efficiency.
Ok my bad. I remember hearing that it was a criticism of common harnesses and that the creator of Pi wanted more control over that feature, so I assumed it wasn't enabled by default. Thank for pointing it out !
That's not true, pi auto-compacts when getting close to the context window limit?
kadoban 5 hours ago [-]
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).
astrobiased 5 hours ago [-]
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.
rcarmo 42 minutes ago [-]
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.
malisper 9 hours ago [-]
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
HDBaseT 6 hours ago [-]
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.
samplifier 3 hours ago [-]
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.
cjalmeida 5 hours ago [-]
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
anon-torment 2 hours ago [-]
Other harnesses tend to have 20k tokens in their system prompt and too many tools, and that drags them down.
ssivark 5 hours ago [-]
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.
matthews3 2 hours ago [-]
If you like Emacs, why not make Emacs your harness?
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.
dasil003 5 hours ago [-]
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.
MattPerry 4 hours ago [-]
I agree. Pi is more like NeoVim if we have to map to Vim/Emacs. Emacs is full (at least compared to Vim) of the hidden features you didn't know it had installed. Pi doesn't bundle any hidden features. A bog standard GNU Emacs install contains, what, like ~10 games, a mail reader, a web browser, RSS feed reader, a nd a Morse code decipher?
Even more so, Pi even has opinionated forks and "distributions" like oh-my-pi that are like LazyVim/AstroVim.
OMP is great. I pair it with https://nono.sh/ and sleep alot easier at night.
LaurensBER 2 hours ago [-]
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.
alasano 6 hours ago [-]
I find omp funny because it's the opposite of why Iike Pi.
JSR_FDED 6 hours ago [-]
It’s more like a curated config. Like using Astro or Lunar instead of starting with a plain Neovim and crafting your own configuration.
jeremyjh 6 hours ago [-]
It goes further than that. I mean, it has a bash interpreter natively linked into it.
hakunin 8 hours ago [-]
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.
suprjami 8 hours ago [-]
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.
hakunin 7 hours ago [-]
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.
theshrike79 51 minutes ago [-]
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.
throw10920 4 hours ago [-]
> 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?
hakunin 4 hours ago [-]
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.
deadbabe 6 hours ago [-]
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.
TheRoque 6 hours ago [-]
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
trees101 5 hours ago [-]
you can copy extensions rather than install them to avoid that problem
ironfootnz 3 hours ago [-]
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.
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).
rcarmo 36 minutes ago [-]
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.
grewil2 2 hours ago [-]
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.
alexhans 59 minutes ago [-]
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.
You can use both providers in Pi using subscriptions. Be careful with Anthropic though, it’s against their TOS.
thehours 2 hours ago [-]
Doesn’t using the Anthropic subscription this way get charged as extra usage, and thus effectively billed at API rates?
thepasch 30 minutes ago [-]
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.
colinmarc 2 hours ago [-]
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.)
danslo 2 hours ago [-]
Oh, I stand corrected. It's been a while since I've used their models.
Glad we can still use OpenAI subscription through Pi.
berserkin1337 2 hours ago [-]
[dead]
ironfootnz 3 hours ago [-]
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.
1saadcodes 3 hours ago [-]
This seems like a more natural use of agents than asking them to one shot and push to prod. Give them a measurable objective, let them experiment, and judge the outcome instead of the implementation. Similar to how you would deal with a junior or intern basically
I 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.
langs 6 hours ago [-]
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.
prettyblocks 6 hours ago [-]
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.
tudelo 44 minutes ago [-]
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
zahrevsky 6 hours ago [-]
Yes, and the article makes the point that this might be changing.
genericacct 2 hours ago [-]
Only thing that runs easily on termux now that gemini-cli has been discontinued..
mraza007 3 hours ago [-]
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
peterldowns 9 hours ago [-]
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.
zahrevsky 8 hours ago [-]
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.
r0b05 3 hours ago [-]
I love using Pi and its design philosophy. The minimalism is what resonates with me. It just works, update after update.
orliesaurus 5 hours ago [-]
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?
schneehertz 23 minutes ago [-]
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.
kadoban 5 hours ago [-]
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.
ssivark 5 hours ago [-]
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.
rahimnathwani 5 hours ago [-]
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?
para_parolu 4 hours ago [-]
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
p1necone 9 hours ago [-]
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.
CharlieDigital 8 hours ago [-]
End up building Pi extensions instead of actual product.
Doesn't make sense to me, but to each their own.
impulser_ 6 hours ago [-]
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.
CharlieDigital 4 hours ago [-]
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.
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.
tosh 5 hours ago [-]
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
sebmellen 5 hours ago [-]
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.
tosh 4 hours ago [-]
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.
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.
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...
that website is horrendous to look at on an eink display btw
yogthos 6 hours ago [-]
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.
It's so easy- npm install, a little markdown boot camp, and you get great results.
Onavo 8 hours ago [-]
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.
spudlyo 7 hours ago [-]
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.
imtringued 29 minutes ago [-]
[dead]
sejje 7 hours ago [-]
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.
sinuhe69 5 hours ago [-]
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!
imtringued 31 minutes ago [-]
Correct. Pi 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.
klooney 4 hours ago [-]
I don't really want to do approvals though. Either I put stuff into a real sandbox, or #yolo
pavo-etc 7 hours ago [-]
The secret here is giving pi its own user account on your machine, using Unix permissions.
josh_p 7 hours ago [-]
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.
jauntywundrkind 7 hours ago [-]
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!
behnamoh 9 hours ago [-]
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.
unknownfuture 8 hours ago [-]
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.
nrb 8 hours ago [-]
Why is this relevant though? This project is so minimal that forking it at any point since it started “mainstreaming” and implementing any functionality that came after would have been utterly trivial.
I am running several named pi instances in parallel in their own user account on NixOS, so they can install whatever they want in ephemeral shells and I never need to worry about their env. The agents can spin up new enabled XMPP agents if I request it, though for now I've only needed a few since I'm not doing too much in parallel.
My Pi is very vanilla, only my own XMPP wrapper and pi-subagents extension for anonymous subagents.
Using it primarily with Deepseek v4 Flash for chipping away at coding tasks or server maintainence while I'm AFK or in transit.
NixOS is the key to all of this, since agents can interact see the whole server config, make changes and run compile-time checks before actually deploying. It also means that even if they do mess up I can always revert.
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...
[1]: https://pi.dev/packages/pi-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
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.
Funny that the XMPP clients has taken more of my time than the pi XMPP wrapper itself.
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.
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.
The result: 38% fewer startup tokens, 17 tools exposed through just three schemas, and 19 skills loaded only when needed.
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)
Basically, it doesn't handle the context "better", it barely does anything special to it, which can actually be better for cost efficiency.
https://pi.dev/docs/latest/compaction
https://github.com/earendil-works/pi/issues/92
IMO, I view it more than a coding agent, it's a coding agent platform with powerful extensibility.
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 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.
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
Also, you can version control your tweaks and easily sync with other machines, just like any code.
https://github.com/karthink/gptel
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.
Even more so, Pi even has opinionated forks and "distributions" like oh-my-pi that are like LazyVim/AstroVim.
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.
My advice: focus on getting work done and slowly adapt Pi with small augmentations as you go. You can start getting work done on vanilla setup. When the right idea comes along, try it. Be ready to refine it, and most importantly, rollback the addition. I've rolled back a bunch.
Many "batteries" that are "included" come from speculative and half-baked ideas, from people who were excited about something at some point in their journey. In practice, those ideas may not bring the desired results, and their creator may've moved on already. So it's better to either learn very well established tools, or mold your own slowly.
For example, many automatic memory systems are not helpful. I built a small extension that asked me whether it should remember something (and write it down to a properly scoped SKILL or AGENTS file). Turned out I accepted less than 5% of suggestions. Most were useless one-offs that would pollute the context. Can't imagine how much crap would accumulate if I wasn't in the loop.
Yeah maybe Claude/OpenCode/KiloCode/Hermes/whatever are not as minimal as Pi but they also work right now.
And if you try vanilla Pi, you will also find out that it works right now.
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.
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 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 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
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.
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...
Glad we can still use OpenAI subscription through Pi.
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 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.
Disclaimer: No first hand knowledge
I had a lot of success running it on my Mac with Qwen3.6-35B-A3B model
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 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.
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.
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 realised how use case dependent harness behaviour is when I tried to use my customised-for-a-side-project pi config at work and realised I needed to tweak it significantly to be useful - I would not be surprised if tools like Claude Code needing to be all things for all people is hurting their peak usefulness.
Doesn't make sense to me, but to each their own.
Same with any of the off the shelf harnesses.
Go build something useful instead of tweaking the minutiae of the harness.
at least with GPT 5.6 Sol fwiw
https://smolenv.com/t/nested-template-includes-60636/
sh is all you need
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 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.
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.
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...
#teampi
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
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.
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.
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.
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!
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.