Why I Use Pi
I randomly read Mario Zechner’s article about what he learned building his own coding agent, which inspired me to try it. After a few days I made some small contributions, and within that first week I moved on from Claude Code to using Pi entirely.
Pi is also one of the building blocks of OpenClaw, which you’ve probably seen going around the past few weeks.
I mentioned to some friends that I had been contributing to the Pi repo and some asked why I started using it and whether they should too. Here’s why I use it, which might help answer that.
A tool that works for me first
One of the first reasons is that Pi is a tool that is easier to make work for me, the same way I’ve made Neovim work for me for the past 15 years.In other words, Pi is Vim. One thing that always bothered me with the different agents I’ve tried, whether it’s Claude Code or Amp, is that they’re either catered towards everyone or highly opinionated. That completely makes sense business-wise, but I always found myself trying to adapt to them instead of the tools adapting to the way I work. It felt somewhat backwards in a world where AI lets you create any tool you need that completely works for you. Why shouldn’t that extend to the tools you use to create those tools?Claude Code has a plugin system and you can set up marketplaces to package different plugins. I still felt limited. I also hear Amp is working on a plugin system I haven’t tried but will probably take a look at when it comes out.
Easily extensible
Pi by itself is very tiny but very complete. It has everything needed for a coding agent and you can simply use it without any changes. On top of that, you can create extensions that register custom tools for the agent to use or custom commands for you to use. What makes this even more powerful is that Pi knows it is extensible and knows where to find its own documentation because its system prompt references it. What ends up happening is that while you’re working, you can ask the agent “this was a difficult workflow, let’s abstract this into an extension we can reuse across projects.”
For example, I’ve needed multiple times to have the agent run a process in the background and continue working, whether it’s TDD with tests running on a loop while it implements features (session) or having the agent run a server and generate an OpenAPI client from it as it iterates (session, video). Before, I would just watch the agent struggle: either it wouldn’t try to start the server or it would try and stall because the server wasn’t running in the background. To avoid this, I created my own extension that runs processes in the background and that the agent knows about.This is not a novel idea; Claude Code has background bash commands as well.
The trade-offs
With all of this comes some trade-offs. You are building your own harness, which means you cannot delegate keeping up with models and tools to someone else. With Claude Code, the team building the models is also building the harness. With Amp, the team thoroughly tests how new models can improve their product. With Pi, you figure out which model provides what you need to do your work.
Pi is open source, and every time I’ve seen a bug or something that doesn’t work as expected or a small addition that could improve the tool, I open an issue or a pull request (e.g., allowing the tool to be put in the background, fixing image forwarding during streaming).
My extensions are also my responsibility. They can break for different reasons, and if I want to improve them, that’s on me too. (My extensions.)
Pi is open source if you want to look at it. Mario Zechner wrote about why he built it and Armin Ronacher wrote about why he uses it. Both are worth reading.