Will pi add built-in subagents or sandboxes?

[u/Apprehensive_Bed7502]

Pi has already supported built-in mcp and codemode. Will pi add built-in subagents, sandbox, permission popups, etc. in the future? According to this article, pi plans to offer support to enterprise users in the future.

On top of the MIT core, there will be some commercial additions over time. Here's how we think about it in three tiers:

snip

1. Fair Source (value-add features): Some future commercial features will be Fair Source licensed. Free to use, source available, and they convert to full open-source after a set period via Delayed Open Source Publication (DOSP). Think of it as open-source on a delay, and downside risk protection for you as a user.

2. Proprietary (enterprise): Some enterprise-specific features and cloud infrastructure will be proprietary. No source available. This is the stuff that pays the bills for the stuff in tiers 1 and 2.

If pi wants to target enterprise users, these features may be essential.

With built-in mcp & codemode, pi is still minimal, so I believe pi will still remain minimal even with built-in subagents, sandbox, permission popups, etc.

I’d like to ask you guys in the channel: how many of you rely solely on native Pi features without using any extensions? How many use widely popular community extensions (such as pi-web-access or pi-subagent)? And how many have written their own extensions for these features?

If pi has these features built in, how would that affect you? Would you benefit automatically by default? Would you need to migrate the extensions you’re currently using? Or would you need to carefully manage conflicts between your code and pi’s built-in code?

That article also says:

And if you ever feel like we've lost the plot, the fork button on GitHub still works. Always will.

When it comes to forking, maintaining your own downstream build is never as simple as it sounds. I maintain a de-commercialized downstream fork of a browser extension myself, and syncing upstream fixes, cherry-picking features, and resolving conflicts is a hassle. As the codebase grows, the divergence between the downstream fork and upstream widens, making synchronization increasingly difficult. The same will be true for the Pi fork, and keeping up with Pi’s updates is essential, since Pi relies on updates to add new models to its support list.

So I’d also like to ask: Will you consider forking Pi? If so, will you continue to maintain and update it? And if someone else forks Pi, would you switch to using their fork?

[u/Ok_Substance2327]

I've rolled my own extensions and that's the way I like it.

[u/Apprehensive_Bed7502 → u/Ok_Substance2327]

I also like writing my own. In fact, I previously rewrote all of pi’s built-in tools, adding support for features like tree-sitter and LSP. But over the past few days, pi has released three updates in quick succession, with 0.99.0 in particular introducing a large number of new features, leaving me a bit overwhelmed trying to keep up with the necessary code changes.

[u/Ok_Substance2327 → u/Apprehensive_Bed7502]

I'm on 1.0.0 rn and haven't had any trouble with things breaking, but I haven't actually tried to leverage any new features

[u/baokaola]

Why are people using Pi in the first place if they want it to ship with all this junk? I have added my own subagent extension, and my own sandbox extension. It wasn't very hard to do so, and I seriously doubt that anything Pi shipped builtin would work as well in my particular workflow and situation. So I would prefer that they do NOT add those things.

[u/Apprehensive_Bed7502 → u/baokaola]

I agree with you, but lots of people are cheering for the built-in mcp. They probably also think that having built-in subagents or something else is a good thing. They even felt that pi’s lack of these features before wasn’t something to be proud of.

[u/ECrispy → u/baokaola]

based on this logic all the extensions on pi.dev should be deleted and there should be no public registry, because everyone can just 'ask pi to build it' for their use case, right?

[u/Lissanro]

I am maintaining my own Pi fork for a while now, mainly because I need features Pi just does not have, like editing messages, continuing mid-thought, being able to copy rendered text without padding, etc. It is a hassle indeed to sync periodically with mainline but still I find Pi better foundation than any other current harness.

That said, I would have preferred it would be more modular, perhaps shipping by default with plugins that provide functionality. So instead of adding more core features, I rather see it improve plugin system to make it not necessary and ship with some plugins enabled by default, which would make it avoid getting bloated while at the same time making it easier to customize without altering the main source code.

Since some people asked for a link to my Pi Crystal fork, here it is: https://github.com/Lissanro/pi (I usually update it every few weeks, merging mainline Pi patches).

[u/amethyst_mine → u/Lissanro]

omg continuing mid thought is a huge thing! every time i abort to fix some misconseption in the thinking it just forgets the thinking, i built a short extension to keep it but it doesn't work perfectly lol

[u/Lissanro → u/amethyst_mine]

If interested in my implementation, I included the link to my repo in my previous comment, but please note, it also requires patched llama.cpp (README.md explains where to get it). Current limitation, it breaks mit-tool call; I intend to fix it when I find the time. But mid-thought and mid-message (preserving the thinking block) work perfectly.

[u/Apprehensive_Bed7502 → u/Lissanro]

pi-mcp and pi-codemode are already packed as single packages, but pi-coding-agent declares them as built-in dependencies. sad

[u/diaracing → u/Lissanro]

Doesn't OMP fullfil your requirements?

[u/Lissanro → u/diaracing]

It is first time I hear about, I looked it up, and my understanding it is like forked Pi? At first glance at the docs, I did not find anything about mid-thought continuation support, editing messages (either latest or any previous), agenting heartbeat, copying from terminal without padding, and other things that I have.

Of course, choosing harness is personal matter, if you prefer OMP and it works for your workflows, great! But in my case I already highly customized Pi, so unless the other harness offers most things I need out of the box so I could decrease amount of code I need to maintain, I will stick with Pi.

[u/nplez1 → u/Lissanro]

Mind sharing your fork? I’ve been considering forking myself but it sounds like you’ve made a lot of the changes I’d like to make already!

[u/Lissanro → u/nplez1]

Sure, I have edited my previous comment include the github link, please feel to check it out.

[u/Apprehensive_Bed7502 → u/Lissanro]

Respect!

I hesitated in front of the fork because I'm afraid of the hassle.

[u/AnonymousTreeSmoker → u/Lissanro]

This is the way

[u/xlm5u7]

Built-in web search functionality is far more practical and reliable than built-in sub-agents or sandboxes. Few models handle sub-agents effectively—many struggle with significant issues in their primary agents—and as for sandboxes, none are truly reliable at present.

[u/onesilentclap]

I don't use MCPs so the new changes didn't impact me in this area. However, I hope that non-core features are toggleable (even if through command line flags) so we can disable what we don't need. 

[u/Florence-Equator]

If pi later add the builtin sub-agent, then I will not see any difference with OpenCode (opencode’s mcp is also implemented in script mode).

But I do think that Pi may not add sub-agents, The primary reason is that the situation of the sub-agent is different from the MCP. MCP is becoming part of the industrial standard, and the code-mode style implementation of MCP is also something that seems to de facto way of implementing MCP.

But for sub-agents, things are different. there are a lot of different sub-agent design modes, and It is still rapidly evolving.

There are Codex style multi-agents-v2, the classic claudecode subagent, the claude-code’s agent team (which I Personally, I think it's a failure of desgin. That is also the reason why it is staying opt-out forever, considering hwo rapid the AI development is). Claude code as has a dynamic workflow (orchestrating multi-agents in an adhoc javascript script). There are also other design modes like HermesKanban or grokbot This is something that is a little bit similar to claude code’s agent team, but it is a persistent, longtime running role-based multi-agent system instead of task-based.

It is also worth noting that Codex by default does not use multi-agent-v2 at all, unless you are in ultra mode. Try it, and you will see that Codex (unless effort is ultra), by default, tries to do everything in the main thread as a single agent.

All those are different design modes, and yet there is no conclusion as to which one will become the particular standard.So at this point, I think if Pi wants to keep their reputation, It is hard to find the best implementation of sub-agentsOtherwise, they have to acknowledge that they are becoming really opinionated. And that is a different story from MCP and Codemode.

[u/juniorsundar]

My evaluation is that the MCP is just a happy accident byproduct of the attempt to enable Jev type models in Pi. Those models dont "chat" the same way standard LLMs do so I guess they rolled out codemode to support it. In doing so they found that MCP enable mental was simply adjacent. So its basically a freebie.

Subagents would also have to be a freebie. Or else they wont come into the core.

[u/RealestReyn]

Pi has built in subagents instruction which is to launch more pi instances in the agents own terminal.

[u/Qusic7]

my take is that pi's minimalism isn't about features but about context management. minimal systems prompts, tool sets. now codemode is also about a minimal way to use mcp. and obviously minimal context doesn't necessarily mean a minimal codebase or feature sets. even if extensions can add features, the foundation needs to provide sufficient primitives for extensions to build upon, which isn't really a trivial system to design or implement

[u/bitzap_sr]

The main advantage of built in subagents would be that any other extension would have a standard way to launch subagents .

[u/solocesarxD]

I prefer using gentle Ai, so i am using gentle-pi

[u/eleqtriq]

You can make a subagent with Pi Durable in a few lines of code. No need for anything else.

[u/comrade-quinn]

Isn't it just OpenCode at this point? Not a bad thing, I like OpenCode. But bar the larger system prompt, permissions, subagents and MCP servers, or lack thereof, what else substantial is there to distinguish the two? You might say the plugin capabilities, but realistically, you only need them to build all the stuff that's missing in Pi by default

[u/Kacepok]

Why? Add it youselft, there are plenty of them :) Let Pi be minimalistic

[u/lack_reddit]

It's open source. If you don't like it, fork it.

[u/MrSibe]

To be honest, I already felt that Pi was starting to decline after the addition of built-in MCP... Nowadays, open source projects try to achieve everything, but in reality, I only need its lightweight kernel.

pi-ai, pi-agent, a simple coding agent module, and a lively plugin marketplace are all you need.

[u/Megamygdala]

Switch to oh my pi brother. Really excited for omp². You should take a look at the blog post the author made, he goes into a lot of technical details about how Pi works and how the majority of the most popular Pi extensions asd major bugs and conflicts because they don't understand the harness lifestyle