To me, the most interesting thing about Pi and the "claw" phenomenon is what it means for open source. It's becoming passé to ask for feature requests and even to submit PRs to open source repos. Instead of extensions you install, you download a skill file that tells a coding agent how to add a feature. The software stops being an artifact and starts being a living tool that isn't the same as anyone else's copy. I'm curious to see what tooling will emerge for collaborating with this new paradigm.
I'm presently in the process of building (read: directing claude/codex to build) my own AI agent from the ground up, and it's been an absolute blast.
Building it exactly to my design specs, giving it only the tool calls I need, owning all the data it stores about me for RAG, integrating it to the exact services/pipelines I care about... It's nothing short of invigorating to have this degree of control over something so powerful.
In a couple of days work, I have a discord bot that's about as useful as chatgpt, using open models, running on a VPS I manage, for less than $20/mo (including inference). And I have full control over what capabilities I add to it in the future. Truly wild.
> The nerds could always make a home with their linux desktop. Now everyone can. It'll change the equation.
Probelm is, to be able to do what you're describing, you still need the source code and the permission to modify it. So you will need to switch to the FOSS tools the nerds are using.
That's just because corporations got greedy and made their apps suck.
Strip away the ads, the data harvesting, add back the power features, and we'll be happy again. I'm more willing than ever to pay a one-time fee good software. I've started donating to all the free apps I use on a regular basis.
I don't want to own my own slop. That doesn't help me. Use your AI tools to build out the software if you want, but make sure it does a good job. Don't make me fiddle with indeterministic flavor-of-the-month AI gents.
I've been thinking about this lately too. I think we're going to see the rise of Extremely Personal Software, software that barely makes any sense outside of someone's personal context. I think there is going to be _so_ much software written for an audience of 1-10 people in the next year. I've had Claude create so much tooling for me and a small number of others in the last few months. A DnD schedule app; a spoiler-free formula e news checker; a single-use voting site for a climbing co-op; tools to access other tools that I don't like using by hand; just absolutely tons of stuff that would never have made any sense to spend time on before. It's a new world. https://redfloatplane.lol/blog/14-releasing-software-now/
I think people overestimate the general population's ability and interest in vibe coding. Open source tools are still a small niche. Vibe code customized apps are an even bigger niche.
> a living tool that isn't the same as anyone else's copy
Yes, which is why this model of development is basically dead-in-the-water in terms of institutional adoption. No large firm or government is going to allow that.
> It's becoming passé to ask for feature requests and even to submit PRs to open source repos.
Yet, the first impact on FOSS seems to be quite the opposite: maintainers complaining about PRs and vulnerability disclosures that turn out to be AI hallucinations, wasting their time. It seems to be so bad that now GitHub is offering the possibility of turning off pull requests for repositories. What you present here is an optimistic view, and I would be happy for it to be correct, but what we've seen so far unfortunately seems to point in a different direction.
We might be witnessing some survivor bias here based on our own human conditioning. Successful PRs aren't going to make the news like the bad ones do.
With that said, we are all dealing with AI still convincingly writing code that doesn't work despite passing tests or introducing hard to find bugs. It will be some time until we iron that out fully for more reliable output I suspect.
Unfortunately we won't be able to stop humans thinking they are software engineers when they are not now that the abstraction language is the human language so guarding from spam will be more important than ever.
Worse it better for you when it meets your needs better.
I use a lot of my own software. Most of it is strictly worse both in terms of features and bugs than more intentional, planned projects. The reason I do it is because each of those tools solve my specific pain points in ways that makes my life better.
A concrete example: I have a personal dashboard. It was written by Claude in its entirety. I've skimmed the code, but no more than that. I don't review individual changes. It works for me. It pulls in my calendar, my fitbit data, my TODO list, various custom reminders to work around my tendency to procrastinate, it surfaces data from my coding agents, it provides a nice interface for me to browse various documentation I keep to hand, and a lot more.
I could write a "proper" dashboard system with cleanly pluggable modules. If I were to write it manually I probably would because I'd want something I could easily dip in and out of working on. But when I've started doing stuff like that in the past I quickly put it aside because it cost more effort than I got out of it. The benefit it provides is low enough that even a team effort would be difficult to make pay off.
Now that equation has fundamentally changed. If there's something I don't like, I tell Claude, and a few minutes - or more - later, I reload the dashboard and 90% of the time it's improved.
I have no illusions that code is generic enough to be usable for others, and that's fine, because the cost of maintaining it in my time is so low that I have no need to share that burden with others.
I think this will change how a lot of software is written. A "dashboard toolkit" for example would still have value to my "project". But for my agent to pull in and use to put together my dashboard faster.
A lot of "finished products" will be a lot less valuable because it'll become easier to get exactly what you want by having your agent assemble what is out there, and write what isn't out there from scratch.
> Instead of extensions you install, you download a skill file that tells a coding agent how to add a feature. The software stops being an artifact and starts being a living tool that isn't the same as anyone else's copy. I'm curious to see what tooling will emerge for collaborating with this new paradigm.
I build my own inspired by Beads, not quite as you're describing, but I store todo's in a SQLite database (beads used SQLite AND git hooks, I didn't want to be married to git), and I let them sync to and from GitHub Issues, so in theory I can fork a GitHub repo, and have my tool pull down issues from the original repo (havent tried it when its a fork, so that's a new task for the task pile).
You can see me dogfeeding my tool to my tools codebase and having my issues on the github for anyone to see, you can see the closed ones. I do think we will see an increase in local dev tooling that is tried and tested by its own creators, which will yield better purpose driven tooling that is generic enough to be useful to others.
I used to use Beads for all my Claude Code projects, now I just use GuardRails because it has safety nets and works without git which is what I wanted.
I could have forked Beads, but the other thing is Beads is a behemoth of code, it was much easier to start from nothing but a very detailed spec and Claude Code ;)
I actually look at this another way. I think we’re going to see a lot more open source. Before you had to get your pr merged into main. Now people will just ask ai to build the tool they need and then open source it.
Maintainers won’t have to deal with an endless stream of PRs. Now people will just clone your library the second it has traction and make it perfect for their specific use case.
Cherry pick the best features and build something perfect for them. They’ll be able to do things your product can’t, and individual users will probably find a better fit in these spinoffs than in the original app.
Is it possible that software is not like anything else, that it is meant to be discarded: that the whole point is to always see it as a soap bubble?
--Alan Perlis
It's like the dude who monkey-patches their car and goes to the dealer to complain why the suspension is stiff.
It's because you put 2by4's in place of the shocks, you absolute muppet. And then they either give them a massive bill to fix it properly or politely show them out.
Same will happen in self-modifying software. Some people are self-aware enough to know that "I made this, it's my problem to fix", some will complain to the maker of the harness they used and will be summarily shown the door.
Think of skills more like Excel macros (or any other software with robust macro support). It doesn't make sense for Microsoft to provide the specific workflow you need, but your own sheet needs it.
My current fave harness. I've been using it to great effect, since it is self-extensible, and added support for it to https://github.com/rcarmo/vibes because it is so much faster than ACP.
Can you shed some light on the speed difference of the direct integration vs. ACP?
I’m still looking for a generic agent interaction protocol (to make it worth building around) and thought ACP might be it. But (and this is from a cursory look) it seems that even OpenCode, which does support ACP, doesn’t use it for its own UI. So what’s wrong with it and are there better options to hopefully take its place?
I've used ACP extensively because agent-shell in emacs uses it, although the Anthropic license change means I'm not sure if I can continue to use Claude through it without getting banned. I kind of wish it integrated more tightly but also you can't really expect someone to have magit involved such that agent-shell (or the like) starts interacting with emacs directly. I'd love it if it did though.
I've started using OpenCode for some things in a big window because its side-by-side diff is great.
Yeah, ACP adds another layer of marshaling/unmarshaling (or two-one on each side) and can be slower than API calls on occasion. Like MCP, it adds JSON overhead that doesn’t really need to be there.
The best option will always be in-memory exchanges. Right now I am still using the pi RPC, and that also involves a bit of conversion, but it’s much lighter.
The better web UI is now part of https://github.com/rcarmo/piclaw (which is essentially the same, but with more polish and a claw-like memory system). So you can pick if you want TS or Python as the back-end :)
I think the thesis of Pi is that there isn't much special about agents.
Model + prompt + function calls.
There are many such wrappers, and they differ largely on UI deployment/integration. Harness feels like a decent term, though "coding harness" feels a bit vague.
I haven’t met a single person who has tried pi for a few days and not made it their daily driver. Once you taste the freedom of being able to set up your tool exactly how you like, there’s really no going back.
> I haven’t met a single person who has tried pi for a few days and not made it their daily driver.
Pleased to meet you!
For me, it just didn’t compare in quality with Claude CLI and OpenCode. It didn’t finish the job. Interesting for extending, certainly, but not where my productivity gains lie.
Not the person you replied to, but I'll stress the point that it is not just what you can add that Claude Code doesn't offer, but also what you don't need to add that Claude Code does offer that you don't want.
I dislike many things about Claude Code, but I'll pick subagents as one example. Don't want to use them? Tough luck. (AFAIK, it's been a while since I used CC, maybe it is configurable now or was always and I never discovered that.)
With Pi, I just didn't install an extension for that, which I suspect exists, but I have a choice of never finding out.
I came here to say the same thing. It's basically _is_ Emacs. Heavily configurable tool, text-focused UI, primary interaction with a minibuffer ..er.. box to prompt at the bottom of the screen, package distribution mechanism, etc etc.
With Emacs modes like agent-shell.el available and growing, why not invest in learning a tool that is likely to survive and have mindshare beyond the next few months?
If you ever want to use other models, pi can do that. In the middle of a session I might switch from gpt-5.2 to opus and get it to do something or review something and then switch back to gpt. Since models are being released every few weeks this is interesting to compare models without having to switch to a different harness.
And if there’s any feature codex has that you want, just have pi run codex in a tmux session and interrogate it how said feature works, and recreate it in pi.
I've been using pi via the pi-coding-agent Emacs package, which uses its RPC mode to populate a pair of Markdown buffers (one for input, one for chat), which I find much nicer than the awful TUIs used by harnesses like gemini-cli (Emacs works perfectly well as a TUI too!).
The extensibility is really nice. It was easy to get it using my preferred issue tracker; and I've recently overridden the built-in `read` and `write` commands to use Emacs buffers instead. I'd like to override `edit` next, but haven't figured out an approach that would play to the strengths of LLMs (i.e. not matching exact text) and Emacs (maybe using tree-sitter queries for matches?). I also gave it a general-purpose `emacs_eval`, which it has used to browse documentation with EWW.
Nice! I'm curious to hear how you're mapping `read` and `write` to Emacs buffers. Does that mean those commands open those files in Emacs and read and write them there?
Let me also drop a link to the Pi Emacs mode here for anyone who wants to check it out: https://github.com/dnouri/pi-coding-agent -- or use: M-x package-install pi-coding-agent
We've been building some fun integrations in there like having RET on the output of `read`, `write`, `edit` tool calls open the corresponding file and location at point in an Emacs buffer. Parity with Pi's fantastic session and tree browsing is hopefully landing soon, too. Also: Magit :-)
The implementation is pretty terrible: a giant string of vibe-coded Emacs Lisp is sent to emacsclient, which performs the actions and sends back a string of JSON.
It's been interesting to iterate on the approach: watching the LLM (in my case Claude) attempting to use the tools; noticing when it struggles or makes incorrect assumptions; and updating the tool, documentation and defaults to better match those expectations.
It feels similar to the file-watching provided by Aider (which uses inotify to spot files containing `# AI!` or `# AI?`), which I've previously used with FIXME and TODO comments in code; but it also works well in non-file things, e.g. error messages and test failures in `shell-mode`, and issues listed in the Emacs UI I wrote for the Artemis bug tracker (Claude just gets the issue number from the current line, and plugs that into a Pi extension I made for Artemis :-) )
I dont. I use this as my coding harness (replacement of gemini-cli/claudecode etc). I dont want to sandbox it because I expect it to be used only for coding on projects. I dont want to over complicate it.
I am building my own assistant as an AI harness - that is definitely getting sandboxed to run only as a VM on my Mac.
I use a sandbox example extension with comes with Pi, it uses the anthropic sandbox runtime (bubblewrap on linux). The runtime has one bug and needs one improvement (I've made PRs, no response yet). Pi's sandbox example extension does not block internal tools (read/write) according to rules, I've created a PR but can't submit because of Pi's OSS vacation BS... https://github.com/badlogic/pi-mono/compare/main...k3a:pi-mo... I am quite happy with my patched forks for now
A few things. I intentionally clone the repo and build it locally for my use and use it as my-omp.. this way, I can make oh-my-pi make customisations like skills, tools, anything and yet retain the ability to do a git pull from upstream with cherry picking if necessary.
I have this in my shell rc.
# bun
export BUN_INSTALL="$HOME/.bun"
export PATH="$BUN_INSTALL/bin:$PATH"
alias my-omp= "bun/Users/aravindhsampathkumar/ai_playground/oh-my-pi/packages/coding-agent/src/cli.ts"
and do
1. git pull origin main
2. bun install
3. bun run build:native
every time I pull changes from upstream.
Until yesterday, this process was purely bliss - my own minimal custom system prompt, minimal AGENTS.md, and self curated skills.md. One thing I was wary of switching from pi to oh-my-pi was the use of Rust tools pi-native using NAPI. The last couple of days whatever changes I pulled from upstream is causing the models to get confused about which tool to use and how while editing/patching files. They are getting extremely annoyed - I see 11 iterations of a tool call to edit a damn file and the model then resorted to rewriting the whole file from memory, and we al know how that goes. This may not be a bug in oh-my-pi per se. My guess is that the agent developed its memory based on prior usage of the tools and my updating oh-my-pi brought changes in their usage. It might be okay if I could lose all agent memory and begin again, but I dont want to.
I'm going to be more diligent about pulling upstream changes from now on, and only do when I can afford a full session memory wipe.
Otherwise, the integrations with exa for search, LSP servers on local machine, syntax highlighting, steering prompts, custom tools (using trafilatura to fetch contents of any url as markdown, use calculator instead of making LLM do arithmetic) etc work like a charm. I haven't used the IPython integration nor do I plan to.
I happen to be somewhat familiar with OpenCode and am considering using it as a personal AI workspace (some chat & agentic behavior,
not worrying about initiative behavior just yet, I’d try to DIY memory with local files and access to my notes) because it seems to have a decent ecosystem.
Pi appears to have a smaller, less “pre-made” ecosystem, but with more flexibility, enthusiasm and extensibility.
Is this correct? Should I look towards Pi over OpenCode? What are the UI options?
I've been using PI for this - just switch to "oh my pi" and am liking it!
Honestly, it's been a dream, I have it running in a docker-sandbox with access to a single git repo (not hosted) that I am using for varied things with my business.
Try it out, it's super easy to setup. If you use docker sandbox, you can just follow what is necessary for claude, spin up the sandbox, exit out, exec into it with bash and switch to Pi.
I have the same question as you, but I want to add that I used OpenCode for general tasks like writing, organization and such but with a context of .md files and it works wonders. And like you, I am considering trying a better suited harness for this task.
I looked a bit into the reasoning for Pi’s design (https://mariozechner.at/posts/2025-11-30-pi-coding-agent/#to...) and, while it does seem to do a lot of things very well around extensibility, I do miss support for permissions, MCP and perhaps Todos and a server mode. OpenCode seems a lot more complete in that regard, but I can well imagine that people have adapted Pi for these use cases (OpenClaw seems to have all of these). So it’s definitely not out of the race yet, but I still appreciate OpenCodes relative seeming completeness in comparison.
This looks great but It feels really risky to add more and more tools to the harness from random repos. Nothing against this repo in particular but I wish we had better security and isolation so I that I knew nothing could go wrong and I could just test a bunch of these every day the same way I can install an app on my phone and feel confident it's not going to steal my data.
I test a bunch of these every day too, so I made a local sandbox to jail all TUI clunkers to $CWD and run all of them in —-yolo mode https://agent-safehouse.dev/
I feel like this misses the point of pi somewhat. The allure of pi is that it allows you to start from scratch and make it entirely your own; that it’s lightweight and uses only what you need. I go through the list of features in this and I think, okay, cool, but why should I use this over OpenCode if I just want a feature-packed (and honestly -bloated) ready-made harness?
Readit News
We know that a lack of control over their environment makes animals, including humans, depressed.
The software we use has so much of this lack of control. It's their way, their branding, their ads, their app. You're the guest on your own device.
It's no wonder everyone hates technology.
A world with software that is malleable, personal, and cheap - this could do a lot of good. Real ownership.
The nerds could always make a home with their linux desktop. Now everyone can. It'll change the equation.
I'm quite optimistic for this future.
Building it exactly to my design specs, giving it only the tool calls I need, owning all the data it stores about me for RAG, integrating it to the exact services/pipelines I care about... It's nothing short of invigorating to have this degree of control over something so powerful.
In a couple of days work, I have a discord bot that's about as useful as chatgpt, using open models, running on a VPS I manage, for less than $20/mo (including inference). And I have full control over what capabilities I add to it in the future. Truly wild.
Probelm is, to be able to do what you're describing, you still need the source code and the permission to modify it. So you will need to switch to the FOSS tools the nerds are using.
Strip away the ads, the data harvesting, add back the power features, and we'll be happy again. I'm more willing than ever to pay a one-time fee good software. I've started donating to all the free apps I use on a regular basis.
I don't want to own my own slop. That doesn't help me. Use your AI tools to build out the software if you want, but make sure it does a good job. Don't make me fiddle with indeterministic flavor-of-the-month AI gents.
Yes, which is why this model of development is basically dead-in-the-water in terms of institutional adoption. No large firm or government is going to allow that.
Yet, the first impact on FOSS seems to be quite the opposite: maintainers complaining about PRs and vulnerability disclosures that turn out to be AI hallucinations, wasting their time. It seems to be so bad that now GitHub is offering the possibility of turning off pull requests for repositories. What you present here is an optimistic view, and I would be happy for it to be correct, but what we've seen so far unfortunately seems to point in a different direction.
With that said, we are all dealing with AI still convincingly writing code that doesn't work despite passing tests or introducing hard to find bugs. It will be some time until we iron that out fully for more reliable output I suspect.
Unfortunately we won't be able to stop humans thinking they are software engineers when they are not now that the abstraction language is the human language so guarding from spam will be more important than ever.
I use a lot of my own software. Most of it is strictly worse both in terms of features and bugs than more intentional, planned projects. The reason I do it is because each of those tools solve my specific pain points in ways that makes my life better.
A concrete example: I have a personal dashboard. It was written by Claude in its entirety. I've skimmed the code, but no more than that. I don't review individual changes. It works for me. It pulls in my calendar, my fitbit data, my TODO list, various custom reminders to work around my tendency to procrastinate, it surfaces data from my coding agents, it provides a nice interface for me to browse various documentation I keep to hand, and a lot more.
I could write a "proper" dashboard system with cleanly pluggable modules. If I were to write it manually I probably would because I'd want something I could easily dip in and out of working on. But when I've started doing stuff like that in the past I quickly put it aside because it cost more effort than I got out of it. The benefit it provides is low enough that even a team effort would be difficult to make pay off.
Now that equation has fundamentally changed. If there's something I don't like, I tell Claude, and a few minutes - or more - later, I reload the dashboard and 90% of the time it's improved.
I have no illusions that code is generic enough to be usable for others, and that's fine, because the cost of maintaining it in my time is so low that I have no need to share that burden with others.
I think this will change how a lot of software is written. A "dashboard toolkit" for example would still have value to my "project". But for my agent to pull in and use to put together my dashboard faster.
A lot of "finished products" will be a lot less valuable because it'll become easier to get exactly what you want by having your agent assemble what is out there, and write what isn't out there from scratch.
https://github.com/rbren/personal-ai-devbox
I build my own inspired by Beads, not quite as you're describing, but I store todo's in a SQLite database (beads used SQLite AND git hooks, I didn't want to be married to git), and I let them sync to and from GitHub Issues, so in theory I can fork a GitHub repo, and have my tool pull down issues from the original repo (havent tried it when its a fork, so that's a new task for the task pile).
https://github.com/Giancarlos/guardrails/issues
You can see me dogfeeding my tool to my tools codebase and having my issues on the github for anyone to see, you can see the closed ones. I do think we will see an increase in local dev tooling that is tried and tested by its own creators, which will yield better purpose driven tooling that is generic enough to be useful to others.
I used to use Beads for all my Claude Code projects, now I just use GuardRails because it has safety nets and works without git which is what I wanted.
I could have forked Beads, but the other thing is Beads is a behemoth of code, it was much easier to start from nothing but a very detailed spec and Claude Code ;)
Maintainers won’t have to deal with an endless stream of PRs. Now people will just clone your library the second it has traction and make it perfect for their specific use case.
Cherry pick the best features and build something perfect for them. They’ll be able to do things your product can’t, and individual users will probably find a better fit in these spinoffs than in the original app.
Deleted Comment
It's because you put 2by4's in place of the shocks, you absolute muppet. And then they either give them a massive bill to fix it properly or politely show them out.
Same will happen in self-modifying software. Some people are self-aware enough to know that "I made this, it's my problem to fix", some will complain to the maker of the harness they used and will be summarily shown the door.
It’s going to be very likely that once something is patched is to be considered as diverged and very hard to upgrade
Dead Comment
I’m still looking for a generic agent interaction protocol (to make it worth building around) and thought ACP might be it. But (and this is from a cursory look) it seems that even OpenCode, which does support ACP, doesn’t use it for its own UI. So what’s wrong with it and are there better options to hopefully take its place?
I've started using OpenCode for some things in a big window because its side-by-side diff is great.
The best option will always be in-memory exchanges. Right now I am still using the pi RPC, and that also involves a bit of conversion, but it’s much lighter.
Model + prompt + function calls.
There are many such wrappers, and they differ largely on UI deployment/integration. Harness feels like a decent term, though "coding harness" feels a bit vague.
and you can build cool stuff on top of it too!
Pleased to meet you!
For me, it just didn’t compare in quality with Claude CLI and OpenCode. It didn’t finish the job. Interesting for extending, certainly, but not where my productivity gains lie.
Deleted Comment
I dislike many things about Claude Code, but I'll pick subagents as one example. Don't want to use them? Tough luck. (AFAIK, it's been a while since I used CC, maybe it is configurable now or was always and I never discovered that.)
With Pi, I just didn't install an extension for that, which I suspect exists, but I have a choice of never finding out.
Can't do that with Claude =)
With Emacs modes like agent-shell.el available and growing, why not invest in learning a tool that is likely to survive and have mindshare beyond the next few months?
And if there’s any feature codex has that you want, just have pi run codex in a tmux session and interrogate it how said feature works, and recreate it in pi.
The extensibility is really nice. It was easy to get it using my preferred issue tracker; and I've recently overridden the built-in `read` and `write` commands to use Emacs buffers instead. I'd like to override `edit` next, but haven't figured out an approach that would play to the strengths of LLMs (i.e. not matching exact text) and Emacs (maybe using tree-sitter queries for matches?). I also gave it a general-purpose `emacs_eval`, which it has used to browse documentation with EWW.
Let me also drop a link to the Pi Emacs mode here for anyone who wants to check it out: https://github.com/dnouri/pi-coding-agent -- or use: M-x package-install pi-coding-agent
We've been building some fun integrations in there like having RET on the output of `read`, `write`, `edit` tool calls open the corresponding file and location at point in an Emacs buffer. Parity with Pi's fantastic session and tree browsing is hopefully landing soon, too. Also: Magit :-)
The implementation is pretty terrible: a giant string of vibe-coded Emacs Lisp is sent to emacsclient, which performs the actions and sends back a string of JSON.
It's been interesting to iterate on the approach: watching the LLM (in my case Claude) attempting to use the tools; noticing when it struggles or makes incorrect assumptions; and updating the tool, documentation and defaults to better match those expectations.
I've also written some Emacs Lisp which opens Pi and tells it to "Action the request/issue/problem at point in buffer '<current-buffer>'" https://github.com/Warbo/warbo-emacs-d/blob/a13a1e02f5203476...
It feels similar to the file-watching provided by Aider (which uses inotify to spot files containing `# AI!` or `# AI?`), which I've previously used with FIXME and TODO comments in code; but it also works well in non-file things, e.g. error messages and test failures in `shell-mode`, and issues listed in the Emacs UI I wrote for the Artemis bug tracker (Claude just gets the issue number from the current line, and plugs that into a Pi extension I made for Artemis :-) )
https://github.com/can1357/oh-my-pi
More of a batteries included version of pi.
I am building my own assistant as an AI harness - that is definitely getting sandboxed to run only as a VM on my Mac.
I have this in my shell rc.
and do1. git pull origin main
2. bun install
3. bun run build:native
every time I pull changes from upstream.
Until yesterday, this process was purely bliss - my own minimal custom system prompt, minimal AGENTS.md, and self curated skills.md. One thing I was wary of switching from pi to oh-my-pi was the use of Rust tools pi-native using NAPI. The last couple of days whatever changes I pulled from upstream is causing the models to get confused about which tool to use and how while editing/patching files. They are getting extremely annoyed - I see 11 iterations of a tool call to edit a damn file and the model then resorted to rewriting the whole file from memory, and we al know how that goes. This may not be a bug in oh-my-pi per se. My guess is that the agent developed its memory based on prior usage of the tools and my updating oh-my-pi brought changes in their usage. It might be okay if I could lose all agent memory and begin again, but I dont want to.
I'm going to be more diligent about pulling upstream changes from now on, and only do when I can afford a full session memory wipe.
Otherwise, the integrations with exa for search, LSP servers on local machine, syntax highlighting, steering prompts, custom tools (using trafilatura to fetch contents of any url as markdown, use calculator instead of making LLM do arithmetic) etc work like a charm. I haven't used the IPython integration nor do I plan to.
Pi appears to have a smaller, less “pre-made” ecosystem, but with more flexibility, enthusiasm and extensibility.
Is this correct? Should I look towards Pi over OpenCode? What are the UI options?
Honestly, it's been a dream, I have it running in a docker-sandbox with access to a single git repo (not hosted) that I am using for varied things with my business.
Try it out, it's super easy to setup. If you use docker sandbox, you can just follow what is necessary for claude, spin up the sandbox, exit out, exec into it with bash and switch to Pi.
Dead Comment
I looked a bit into the reasoning for Pi’s design (https://mariozechner.at/posts/2025-11-30-pi-coding-agent/#to...) and, while it does seem to do a lot of things very well around extensibility, I do miss support for permissions, MCP and perhaps Todos and a server mode. OpenCode seems a lot more complete in that regard, but I can well imagine that people have adapted Pi for these use cases (OpenClaw seems to have all of these). So it’s definitely not out of the race yet, but I still appreciate OpenCodes relative seeming completeness in comparison.
Went from codex/claude code -> opencode -> pi -> oh-my-pi
It's just an opinionated fork, either you like it or you don't. I personally really like it.
I am still an avid user of opencode, my own fork though with async tools etc, but it is cumbersome and tries to do too many things.
https://x.com/victormustar/status/2026380984866710002