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?
people use different models. I use small local ones for instance
Can this perform "agentic tasks" while using a local ollama instance
Yes, definitely.
Also if anyone wants opinionated and easy pi, oh-my-pi has been that choice for ages
> 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
Tip: You can see the token usage of MCPs/plugins/skills by using `/context`.
For example, the M$ 365 MCP occupies several thousands of tokens, and there's currently no way to disable it entirely in Claude Code...
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.
superpowers front-load 22k tokens before you even hit send and their context inflation balloons after 500k
Would you say the same about something like, say, Spacemacs?
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.
Oops. It wasn’t in the announcement, it’s in their Prompting Best Practices. I just noticed it because of the announcement.
https://developers.openai.com/api/docs/guides/latest-model#u...
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.
I was not sure how to improve on it though.
What was lacking? This is self promotional but I am working on
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".
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.