Every time I post something about coding agents, someone asks me the same question:
Have you tried OMP yet?
Or the opposite:
Why are you still using Pi when OMP exists?
I understand why people ask. Both are forks of the same project, both run in the terminal, and both have active communities.
What I don’t see very often is why someone prefers one over the other. Most discussions end with people recommending a tool without explaining what made them choose it.
So I decided to try both.
Not just installing them and trying them for ten minutes, but actually using them in my daily work for about two weeks. I switched between them regularly and also compared my experience with a colleague who uses Pi every day.
Here’s my conclusion before we dive into the details:
I’ll probably go back to Pi.
Even if that means spending more time looking for extensions—or building my own when nothing available fits what I need.
Pi terminal UI, from pi.dev.
Quick vocabulary, so we’re on the same page
If you haven’t been following this corner of the AI tooling world, here’s a quick overview.
- Pi — a minimalist terminal coding agent by Mario Zechner. The core comes with only four tools: read, write, edit, and bash. No built-in sub-agents, no plan mode, and no permission gate. Everything else comes through extensions.
- OMP (Oh My Pi) — a fork of Pi with a “batteries included” philosophy. It comes with 32 built-in tools, LSP, DAP for debugging, sub-agents, cross-session memory, and more, all available from the start.
If Pi’s philosophy is “build only what you need,” OMP’s philosophy is “everything is already here—you can disable what you don’t need.”
Neither approach is objectively better.
But after using both for two weeks, I realized they feel very different in everyday work.
“Isn’t Pi more annoying to set up?”
Yes.
That was the first thing I noticed.
Setting up Pi took longer because I had to choose my own extensions. The problem isn’t installing them—it’s deciding which ones to install.
There are thousands of extensions available. I spent a surprising amount of time reading descriptions, especially for planner and sub-agent extensions.
Finding a planner wasn’t difficult.
Finding the right planner was.
I ended up comparing several extensions with very similar names and overlapping features before deciding which one to use.
To be fair, this is exactly what Pi is designed for.
Its philosophy is simple: keep the core minimal, then let users build the workflow they want.
I like that idea.
But if your goal is to install a coding agent and start working immediately, this setup process is real friction.
The biggest problem I found: sub-agent auto-invocation consistency
This is still my biggest complaint about Pi.
I installed a sub-agent extension with a planner sub-agent, typed “plan”, and expected the right planning flow to start automatically.
Sometimes it did.
Sometimes it didn’t.
That was the core issue for me: the planner sub-agent itself was useful, but the auto-invocation did not always feel reliable.
When the planner sub-agent was called correctly, the result was usually fine. The frustrating part was getting Pi to consistently understand that this was the moment to hand the task off to it.
Sometimes everything worked exactly as expected.
Other times I had to invoke the extension manually or rewrite my prompt before the planner finally loaded.
I don’t know whether this is a Pi issue or simply a limitation of the third-party extensions I chose.
Either way, it affects the overall experience.
If sub-agent routing isn’t always reliable, it’s difficult to fully trust it with larger or more complicated tasks.
Where Pi still wins for me: UI and initial context
Despite the setup process and the sub-agent auto-invocation issue, Pi still has a few advantages that matter a lot to me.
The first is the UI.
I simply prefer it.
It’s clean, lightweight, and doesn’t try to show everything at once.
The second is the initial context.
Pi starts with a much smaller context than OMP, which means I’m already spending fewer tokens before I ask the model to do anything. I like that because it keeps the cost predictable from the beginning of a session.
The third advantage is how Pi handles permissions.
Pi has no permission gate by default, which means the agent can edit files and continue working without asking me to approve every step. For me, that’s actually a feature, not a downside.
I don’t want to approve every file edit before the agent can continue working.
For my workflow, I’d rather trust the agent and step in only when something goes wrong.
“So why does OMP feel heavier despite being more complete?”
This was the part that surprised me the most.
From a performance perspective, OMP actually feels fast. That makes sense because many of its heavy operations—such as ripgrep, globbing, and search—have been rewritten in Rust.
I never felt like the application itself was slow.
What felt heavier was everything around it.
The UI shows much more information than Pi. More tools, more panels, more features. Some people will probably appreciate that. Personally, I found it distracting. I prefer Pi’s cleaner interface because it lets me focus on the task instead of the tool.
The other difference is the initial context.
Before either harness starts working, the model needs to understand what tools it has available. Pi starts with only a handful of built-in tools, so that initial context stays relatively small.
OMP is different.
Because it comes with many built-in tools, sub-agents, and other capabilities, the model starts each session with a much larger context.
That doesn’t automatically make it bad.
If you use those features regularly, the extra context may be worth the cost.
But if you don’t, you’re paying for capabilities that might never be used during that session.
Then there’s Plan Mode.
I genuinely like the quality of the plans it produces.
They’re detailed, well structured, and usually useful.
The first time I used it, though, I looked at the token usage afterward and thought:
Wow… that’s expensive.
Would I use it for a large migration or a complicated refactor?
Absolutely.
Would I use it every day for regular frontend work?
Probably not.
Numbers that convinced me, not just a feeling
Everything above is still subjective.
UI preference is subjective.
Workflow is subjective.
Even my opinion about Plan Mode is subjective.
Token usage, however, is something we can actually measure.
I’m on an OpenCode GO subscription, so I could compare my own usage while testing OMP against a colleague who uses Pi every day.
My colleague works on backend systems across multiple complex projects.
I mostly work on frontend, with a much narrower scope.
The model setup wasn’t identical, but it was close enough to make the comparison meaningful.
- My colleague (Pi): DeepSeek V4 Flash for fast tasks, DeepSeek V4 Pro as the main model, and Kimi for multimodal support.
- Me (OMP): DeepSeek V4 Flash for fast tasks, DeepSeek V4 Pro as my main model, and occasionally GLM or Kimi when I wanted to compare results.
In other words, our primary workflow was almost identical.
The fast model was the same.
The main reasoning model was the same.
The only meaningful difference was that I sometimes experimented with another model out of curiosity.
If project complexity were the biggest factor, my colleague’s usage should have been much higher than mine.
He works on multiple backend projects.
I mostly work on frontend.
But that wasn’t what I saw.
| Role | Project complexity | Relative token usage | |
|---|---|---|---|
| Me (OMP) | Frontend | Narrower scope | ~1–2× higher |
| My colleague (Pi) | Backend | Multiple complex projects | Baseline |
Instead, my usage on OMP was consistently around 1–2× higher than his.
That was the moment I stopped thinking,
Maybe it’s just the models.
Now, to be clear, this isn’t a scientific benchmark.
It’s only one comparison between two people.
Different prompts, different tasks, and my occasional model switching could all affect the numbers.
I’m not claiming that OMP always uses 1–2× more tokens.
I’m saying that this was my experience after two weeks of real work, and it was enough to change my mind.
For me, it was a strong signal that OMP’s built-in features introduce real overhead in day-to-day usage—not just in theory, but in my monthly token bill.
So… back to Pi?
Most likely, yes.
Not because Pi is perfect.
It isn’t.
The setup takes longer, choosing extensions can be frustrating, and I’m still not completely happy with sub-agent auto-invocation consistency.
Those are real problems.
Even so, I still find myself wanting to go back.
For my workflow, a clean UI, a small initial context, and no permission gate are worth more than having every feature available from day one.
The trade-off makes sense to me.
I’d rather spend an extra hour setting up my environment once than pay for unnecessary context every time I start a session.
The other option I’m still considering is giving OpenCode another proper look.
I’ve used it before, but at the time I preferred a simpler interface over a more feature-rich one.
After spending time with both Pi and OMP, I think it’s worth revisiting with a fresh perspective.
So what’s my takeaway after two weeks?
A “batteries included” harness feels impressive on day one. A minimalist harness feels better after day thirty.
That’s probably the biggest lesson I learned.
When I first started using OMP, I thought all the extra tools would make me more productive.
Some of them did.
But over time, I realized I cared more about a smaller initial context, an interface that stayed out of my way, and a system that was easier to extend based on my own needs.
That doesn’t mean OMP is the wrong choice.
If you regularly use its built-in features, the trade-off may be completely worth it.
It just wasn’t the right trade-off for me.
For now, I’ll probably go back to Pi, continue improving my setup, and maybe even build a few extensions myself.
Ask me again in one month.
I might have a different answer.
But based on the last two weeks, this is the one I’d give today.