I can understand someone being overwhelmed and not wanting to configure and "build your own pi" which is really one of the beautiful points of pi, but like with vim, I do recommend that after playing with this for a while you go back to pure pi and then decide what do you really need and incrementally add it.
The power of the incremental in control approach is huge. It allows you to keep moving in whatever direction you want instead of taking yet another dependency.
Pi makes you think about what you’re doing with it on purpose. This defeats that, as the Mario quote on the page says, and therefore isn’t worth using.
People really need to try out “less is more”. The new models are quite smart, so suffocating their context with dozens of MCPs and skills isn’t necessary like it used to be. A cli tool with good built in help and good errors is amazingly easy for the model to figure out.
If Pi is too minimal for you and you don’t want to dig into it, OpenCode is pretty good out of the box. I use it for general work I haven’t setup Pi for. The only thing I add to OpenCode is some commands that are shortcuts to save me typing frequent prompts, and a subagent with a fixed model for implementing changes.
My first thought when reading about this was, why does Pi with 8 custom skills and one extension work so well for me, and apparently so poorly for others that they are compelled to go to these lengths?
> The new models are quite smart, so suffocating their context with dozens of MCPs and skills isn’t necessary like it used to be.
Genuinely curious, how MCPs can suffocate the context? And what exactly do you mean by this?
I have probably more than a dozen of MCPs enabled in my Claude Code (slack, jira, github, many internal ones), and I have never seen model calling into them unnecessarily unless it’s explicitly needed for a task. And in the latter case, well, it cannot do much without the right tools access (MCP in this case).
Skills and plugins are a bit of grey zone, yes, but even there it heavily depends on what you put there. Just plugin loading always takes infinitesimal portion of the context in my experience
To let the model know when to call them, you send a list of it to the model as part of the context. Each MCP contains a description and sometimes each tool contains a description.
No, I don’t think I would. Filling the model’s context with a bunch of junk and actively making it perform worse isn’t the same as adding opinionated defaults/settings. The GPT-5.6 announcement just made it clear that these huge agents files are actually doing more harm than good.
If this just added skins or something I wouldn’t be arguing against it.
I like the Pi approach, but I think I didn't "hold it correctly" so to say.
I would like to migrate away from Claude Code and use Pi as my "peimary" harness. I really like in particular how it manages conversation trees and branches.
But I think I didn't do a good job in customizing it for my work. While nothing dramatic, I think the LLM I was using did a better job on Claude Code than on Pi a couple of time when I tried giving it the same work.
which is designed around the Pi philosophy of less is better by focusing on ondemand context/guidance. I won't bloat the context unless the LLM needs to do something I know it will need better guidance with. I have a demo repo for this at https://github.com/gitsense/gsc-rules-demos
One of the examples is, if I know the agent is reading a specific file, I will inject additional context. So if the agent never needs to do something in a certain file or directory, I don't need to pollute the context with "what it may need to know".
It's difficult to be very specific, because this was not a formal experiment.
I was using LLM collaboratively to help me setting up and document a home server. I was using DeepSeek for that matter. I tried some tasks on Claude Code and some on Pi.
Subjectively, I felt that it was marginally "smarter" on Claude Code. It would figure things out better, that sort of thing.
I am still using Pi btw. My current set up is using MiMo on Pi as a planner, ans DS in Claude Code to validate/execute the plan.
I may try moving it all to Pi, but I wonder if I should learn how to better configure the things there.
> I may try moving it all to Pi, but I wonder if I should learn how to better configure the things there.
Honestly if the difference was marginal, I would move to Pi. I just tried layzpi and I had the agent write/compile a hello world in c and it required 20k in tokens. My minimal setup required 5.3k in tokens.
People will say the cost is minimal since this is cached but 15k is a lot since that needs to be reasoned by the LLM. I haven't looked at Claude Code but I read somewhere the system prompt is like 20k so I can see how Claude Code might have seem smarter as what you are working was probably addressed in the system prompt.
For me the bloat is not worth it since I am more interested in the LLM being able to reason better.
That’s why I like things like oh-my-pi and lazypi, nothing’s stopping you from modifying it after you install; I find that when I’m working on my own sometimes I brick myself into a corner and it’s nice to see someone else’s starting point for reference.
This is so easy to do because we are unable to contemplate every edge case at the time of inception right? At least that is what I am telling myself as I brick myself on a "manifest driven system" that surely will detect drift as I bolt more and more on, right? no... bricked as fah.
At least I am learning to build modular so I can reuse parts like image gen, audio gen (STT/TTS), knowledge management. I have probably built 4 of these systems in the last year, each one gets better and lasts longer until I brick the crap out of it. Super fun.
From my limited time using pure Pi, I found quite a few of the plugins lacking and had no desire to upgrade/fix and maintain them myself. I know others feel differently though.
I like the idea of keep Pi minimal but having “official”, high quality optional plugins to make it more usable.
Making the upgrades or maintaining or crafting from scratch a plugin isn't free, it costs tokens and time and attention. And you're almost assuredly reinventing a wheel that someone else already did and probably did better. I like have the ability, but I prefer not needing it.
Funny you mention that because the OMP GitHub issues (https://github.com/can1357/oh-my-pi/issues) is almost exclusively attended to by a very efficient bot. I routinely submit issues and they’re replicated and resolved (via PRs) in ~30 mins.
To your question: it’s the difference between one person and an agent working on something vs an experienced dev and the entire community.
60+ ! oh my, while this is cool it seems that is overkill. I want to know all my skills back and forth.
But I like this kind of projects where I can peak of what extensions other people use. Is like .vimrc file back in the day. Do not clone blindly, but peak, learn and copy what is needed.
I use lazyvim for all my neovim config. Does it fly in the face of the configurability or minimalism of vim? I'd argue no, but rather it is an expected outcome of a highly configurable system. Some people don't want to think about this kind of thing, they just want something that works.
I'd have to say at least a bit? Which is totally fine if it works for you, but there's gotta be some amount of extra features added after which "minimal" stops being a good description.
Edit: Although, we should also acknowledge that minimalism is a sliding scale. Compared to plain vi, vim is bloated. Compared to a full blown traditional IDE, lazyvim probably is minimal.
I think the developers of Pi made a supply chain mistake by stripping down the core agent and requiring features like subagents to load plugins written by some random person.
Pi is meant for people who know what they are doing. If you dont fall into that category use OpenCode, etc. The whole idea is that you customize Pi to your own needs by asking it to modify itself through extensions.
That said, sometimes it is really easy to leverage existing extensions. You run the risk of supply chain attack though. I installed one extension that was useful, modified it to my needs and pinned it.
> Pi is meant for people who know what they are doing
How many people genuinely know what they're doing when the value prop of Pi is basically to vibe code it to your taste? The entire point of vibe coding being that you don't actually have to know what you're doing?
We are going to address this. Not by loading the agent but by finding a way to provide official plugins or blessed plugins. But we’re not yet sure what the right approach is.
If you're going to have "blessed" plugins, which seems like a good idea, you'll need a review and possibly hosting process.
- Review to check that the plugin is reasonable quality/isn't malicious.
- hosting (e.g. the plugin is retrieved from a repo. you control) or "known good" checksums so pi will only download the plugin with a version that you've reviewed.
From a security/supply chain aspect, ironically what you're looking to do is deliberately add some friction to the publishing process, which sounds bad, but can be quite effective at mitigating attacks. Most of the recent supply chain attacks get found by automated scanners in < 24 hours, so having a review process for new releases that takes a while will reduce the number that affect users.
I think having this is handy as it'll give security conscious users more confidence in using pi, without the anxiety of pulling a load of additional code from effectively random sources.
ironically (?) i prefer to improve Pi by connecting MCP servers instead of native extensions in part due to this (process-level sandboxing is trivial; anything more granular -- as would be required for in-process plugins -- is far more intimidating).
On the one hand, sure, why not have a default install throw a bunch of bells+whistles via skills and extensions.
But I like pi precisely because it is so minimal. I want understand and work around the simplest possible agentic coding setup, find the sharp edges, maybe even improve my prompting ability. And doing all three with a locally hosted LLM.
At some point, if I don't understand the foundations, am I just punting on actually thinking about what I'm doing?
Of course, making individual choices about how to do agentic coding are precisely just making individual choices. People should do what makes them happy and productive.
What AGENTS.md and skills are people relying on these days?
I have little to none and am successful building full stack Go apps Claude Code, Codex, and Shelley which covers the spectrum of crazy black box to simple `bash` clanker.
It makes me think the models are continually improving in knowing what to do on their own.
I do put some major work into the classic "Developer Experience" (DX) of my code base. Standard Go tooling, idiomatic Go, well designed initial test harnesses, GitHub actions that enforce some linting.
I think that works better than any markdown instructions ever will.
Nothing in (AGENTS|CLAUDE).md, no Cursor style rules. Just some skills for Jira/Confluence, CI, and Playwright.
Haven't bothered doing any extra customisation in Claude Code or Codex as I don't really trust those things to apply consistently. And if you can run your CI steps locally before you push you don't need to tell an agent to remember it.
That said I've been playing with pi today and given how stripped down it is I've used it as a sandbox for customisation. Still, I haven't gone quite as far as laying down project level instructions. More that Claude Code in particular is quite heavy, and so it its prompt, and adding stuff like rich integration with GitHub and SourceHut (CI status, active branch or PR) seems comparatively trivial in pi.
Only thing left to do is switch out ghostty for the time being as it's misbehaving. Laptop hot to the touch even after idling overnight.
I’ve tried quite a few, from oh-my-openagent’s gargantuan hooks+plugin system to minimal add-i like wozcode, and I’ve been most impressed by that (wozcode) and oh-my-pi.
I get that pi is supposed to be roll-your-own but I think OMP’s config is a great starting point; pi removed all the fluff and OMP added just enough orchestration and tooling back in to take things to the next level.
Wozcode is great if you like CC because it doesn’t mess with the fundamentals, it just adds things like batching for efficiency—CC’s system prompt alone is absurd.
Caveat: I’m a data scientist/researcher, not a professional SWE, so take my experiences with a grain of salt. I’m just a python monkey most of the time
I've been using oh-my-pi for a while and I'm very happy with it. If you're not going to build out your own Pi setup I'm not sure why you'd pick this over oh-my-pi.
I like peeping at other people's skills but it is unclear to me what/where the claimed 60+ skills are actually located. Compound Engineering conveys a few but nowhere near 60.
The power of the incremental in control approach is huge. It allows you to keep moving in whatever direction you want instead of taking yet another dependency.
People really need to try out “less is more”. The new models are quite smart, so suffocating their context with dozens of MCPs and skills isn’t necessary like it used to be. A cli tool with good built in help and good errors is amazingly easy for the model to figure out.
If Pi is too minimal for you and you don’t want to dig into it, OpenCode is pretty good out of the box. I use it for general work I haven’t setup Pi for. The only thing I add to OpenCode is some commands that are shortcuts to save me typing frequent prompts, and a subagent with a fixed model for implementing changes.
Genuinely curious, how MCPs can suffocate the context? And what exactly do you mean by this?
I have probably more than a dozen of MCPs enabled in my Claude Code (slack, jira, github, many internal ones), and I have never seen model calling into them unnecessarily unless it’s explicitly needed for a task. And in the latter case, well, it cannot do much without the right tools access (MCP in this case).
Skills and plugins are a bit of grey zone, yes, but even there it heavily depends on what you put there. Just plugin loading always takes infinitesimal portion of the context in my experience
If this just added skins or something I wouldn’t be arguing against it.
I would like to migrate away from Claude Code and use Pi as my "peimary" harness. I really like in particular how it manages conversation trees and branches.
But I think I didn't do a good job in customizing it for my work. While nothing dramatic, I think the LLM I was using did a better job on Claude Code than on Pi a couple of time when I tried giving it the same work.
I was not sure how to improve on it though.
https://github.com/gitsense/pi-brains
which is designed around the Pi philosophy of less is better by focusing on ondemand context/guidance. I won't bloat the context unless the LLM needs to do something I know it will need better guidance with. I have a demo repo for this at https://github.com/gitsense/gsc-rules-demos
One of the examples is, if I know the agent is reading a specific file, I will inject additional context. So if the agent never needs to do something in a certain file or directory, I don't need to pollute the context with "what it may need to know".
I was using LLM collaboratively to help me setting up and document a home server. I was using DeepSeek for that matter. I tried some tasks on Claude Code and some on Pi.
Subjectively, I felt that it was marginally "smarter" on Claude Code. It would figure things out better, that sort of thing.
I am still using Pi btw. My current set up is using MiMo on Pi as a planner, ans DS in Claude Code to validate/execute the plan.
I may try moving it all to Pi, but I wonder if I should learn how to better configure the things there.
Honestly if the difference was marginal, I would move to Pi. I just tried layzpi and I had the agent write/compile a hello world in c and it required 20k in tokens. My minimal setup required 5.3k in tokens.
People will say the cost is minimal since this is cached but 15k is a lot since that needs to be reasoned by the LLM. I haven't looked at Claude Code but I read somewhere the system prompt is like 20k so I can see how Claude Code might have seem smarter as what you are working was probably addressed in the system prompt.
For me the bloat is not worth it since I am more interested in the LLM being able to reason better.
At least I am learning to build modular so I can reuse parts like image gen, audio gen (STT/TTS), knowledge management. I have probably built 4 of these systems in the last year, each one gets better and lasts longer until I brick the crap out of it. Super fun.
From my limited time using pure Pi, I found quite a few of the plugins lacking and had no desire to upgrade/fix and maintain them myself. I know others feel differently though.
I like the idea of keep Pi minimal but having “official”, high quality optional plugins to make it more usable.
When do you get it to make you the thing versus choosing to vendor something out like back in the day?
To your question: it’s the difference between one person and an agent working on something vs an experienced dev and the entire community.
Time and tokens too of course.
I guess it's the same kinda friction with vanilla vim/neovim vs vim 'distributions' that provide a bunch of stuff out of the box.
I tried pi before but the gap between codex and pi is too big for me to be productive. Ideally lazypi is easy to disable or add plugins as well.
But I like this kind of projects where I can peak of what extensions other people use. Is like .vimrc file back in the day. Do not clone blindly, but peak, learn and copy what is needed.
Probably not.
> or minimalism of vim?
I'd have to say at least a bit? Which is totally fine if it works for you, but there's gotta be some amount of extra features added after which "minimal" stops being a good description.
Edit: Although, we should also acknowledge that minimalism is a sliding scale. Compared to plain vi, vim is bloated. Compared to a full blown traditional IDE, lazyvim probably is minimal.
That said, sometimes it is really easy to leverage existing extensions. You run the risk of supply chain attack though. I installed one extension that was useful, modified it to my needs and pinned it.
How many people genuinely know what they're doing when the value prop of Pi is basically to vibe code it to your taste? The entire point of vibe coding being that you don't actually have to know what you're doing?
- Review to check that the plugin is reasonable quality/isn't malicious.
- hosting (e.g. the plugin is retrieved from a repo. you control) or "known good" checksums so pi will only download the plugin with a version that you've reviewed.
From a security/supply chain aspect, ironically what you're looking to do is deliberately add some friction to the publishing process, which sounds bad, but can be quite effective at mitigating attacks. Most of the recent supply chain attacks get found by automated scanners in < 24 hours, so having a review process for new releases that takes a while will reduce the number that affect users.
I think having this is handy as it'll give security conscious users more confidence in using pi, without the anxiety of pulling a load of additional code from effectively random sources.
But I like pi precisely because it is so minimal. I want understand and work around the simplest possible agentic coding setup, find the sharp edges, maybe even improve my prompting ability. And doing all three with a locally hosted LLM.
At some point, if I don't understand the foundations, am I just punting on actually thinking about what I'm doing?
Of course, making individual choices about how to do agentic coding are precisely just making individual choices. People should do what makes them happy and productive.
I have little to none and am successful building full stack Go apps Claude Code, Codex, and Shelley which covers the spectrum of crazy black box to simple `bash` clanker.
It makes me think the models are continually improving in knowing what to do on their own.
I do put some major work into the classic "Developer Experience" (DX) of my code base. Standard Go tooling, idiomatic Go, well designed initial test harnesses, GitHub actions that enforce some linting.
I think that works better than any markdown instructions ever will.
Haven't bothered doing any extra customisation in Claude Code or Codex as I don't really trust those things to apply consistently. And if you can run your CI steps locally before you push you don't need to tell an agent to remember it.
That said I've been playing with pi today and given how stripped down it is I've used it as a sandbox for customisation. Still, I haven't gone quite as far as laying down project level instructions. More that Claude Code in particular is quite heavy, and so it its prompt, and adding stuff like rich integration with GitHub and SourceHut (CI status, active branch or PR) seems comparatively trivial in pi.
Only thing left to do is switch out ghostty for the time being as it's misbehaving. Laptop hot to the touch even after idling overnight.
Caveat: I’m a data scientist/researcher, not a professional SWE, so take my experiences with a grain of salt. I’m just a python monkey most of the time
It still tends to do those things, but maybe 40% less.
But it's a useful list of things and they are links.
What, no kitchen sink?