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?

> 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

Quite the opposite is true. The agent and the harness is more important than the model on normal tasks. Just for extremely deep problems Fable 5/... are needed.

I'm using oh-my-pi with gortex MCP, context7 and LSP servers. Plus tons of skills. Without that enhancements it's almost useless, missing all the file edits, git amend or fixup strategies, or github api calls.

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.

Would you say the same about something like, say, Spacemacs?

To be clear, Oh My Pi isn't simply batteries included like LaziPi. It's a fork with a bunch of foundational extra features built into the core.

I'm exploring the pi based options now and I like that Oh-my-pi actually adds new value over extensions (the advisor and stream interruption hooks are pretty clever).

I just wish it had a way for me to downlimit tool access (I love midsized local models, and I'd love to enable only 30% of the power for some usecases).

As AI outsider, can you speak to how you draw the line here? Like doesn't the agential blahblah make upgrades/maintenance trivial?

When do you get it to make you the thing versus choosing to vendor something out like back in the day?

It looks exactly like neovim plugin ecosystem and I was waiting for someone to make this.

I tried pi before but the gap between codex and pi is too big for me to be productive. Ideally lazypi is easy to disable or add plugins as well.

I use lazyvim for all my neovim config. Does it fly in the face of the configurability or minimalism of vim? I'd argue no, but rather it is an expected outcome of a highly configurable system. Some people don't want to think about this kind of thing, they just want something that works.

Nothing in (AGENTS|CLAUDE).md, no Cursor style rules. Just some skills for Jira/Confluence, CI, and Playwright.

Haven't bothered doing any extra customisation in Claude Code or Codex as I don't really trust those things to apply consistently. And if you can run your CI steps locally before you push you don't need to tell an agent to remember it.

That said I've been playing with pi today and given how stripped down it is I've used it as a sandbox for customisation. Still, I haven't gone quite as far as laying down project level instructions. More that Claude Code in particular is quite heavy, and so it its prompt, and adding stuff like rich integration with GitHub and SourceHut (CI status, active branch or PR) seems comparatively trivial in pi.

Only thing left to do is switch out ghostty for the time being as it's misbehaving. Laptop hot to the touch even after idling overnight.

I’ve tried quite a few, from oh-my-openagent’s gargantuan hooks+plugin system to minimal add-i like wozcode, and I’ve been most impressed by that (wozcode) and oh-my-pi. I get that pi is supposed to be roll-your-own but I think OMP’s config is a great starting point; pi removed all the fluff and OMP added just enough orchestration and tooling back in to take things to the next level. Wozcode is great if you like CC because it doesn’t mess with the fundamentals, it just adds things like batching for efficiency—CC’s system prompt alone is absurd.

Caveat: I’m a data scientist/researcher, not a professional SWE, so take my experiences with a grain of salt. I’m just a python monkey most of the time

My Claude.md is a maybe 30 lines. I only adid something if it repeatedly does something that annoys me.

It still tends to do those things, but maybe 40% less.

Second this. I went back to vanilla zsh after oh-my-zsh. Turns out I really just wanted 2 features that are built into zsh, and a custom prompt that includes git info that I just wrote myself in ~20 neat, readable lines of shell (minus the ANSI coloring).

I maintain vim and neovim confugs, never going with a distribution of plug-ins, and can't imagine how grotesque those must be.

The difference here though is that zsh and vim are old projects. My configs with them never break. I can't say the same about neovim, and Pi also probably isn't stable.

Pi is perfectly usable in its "raw" state (except perhaps an extension for your specific provider, if not built in).

Configuring it isn't really overwhelming: you use it for a while and then find that you'd want to extend it with some particular functionality.

If you like OpenCode, there is a vim input plugin (only one I use) https://github.com/Tarquinen/opencode-vim

The memory footprint of Opencode is prohibitive to run 10+ copies at once.

I personally find OpenCode's TUI atrociously awful, I guess a matter of taste.

Sounds like a great monetization strategy. Official/blessed plugins (benchmarked and optimized) + access to open models, all in one sub, competitively priced to match OpenCode subs and I'll switch back over to Pi.

If you're going to have "blessed" plugins, which seems like a good idea, you'll need a review and possibly hosting process.

- Review to check that the plugin is reasonable quality/isn't malicious.

- hosting (e.g. the plugin is retrieved from a repo. you control) or "known good" checksums so pi will only download the plugin with a version that you've reviewed.

From a security/supply chain aspect, ironically what you're looking to do is deliberately add some friction to the publishing process, which sounds bad, but can be quite effective at mitigating attacks. Most of the recent supply chain attacks get found by automated scanners in < 24 hours, so having a review process for new releases that takes a while will reduce the number that affect users.

I think having this is handy as it'll give security conscious users more confidence in using pi, without the anxiety of pulling a load of additional code from effectively random sources.

the approach is a plugin_name_spec.md that builds the plugin from plain text.

> Pi is meant for people who know what they are doing

How many people genuinely know what they're doing when the value prop of Pi is basically to vibe code it to your taste? The entire point of vibe coding being that you don't actually have to know what you're doing?

That’s why Mario said “YOLO” is enabled by default from what I remember—something like, I want you to think about what you’re doing.

Not necessarily. I had almost no idea what I was doing when I started using Pi. The goal was to learn harness engineering and understand how it feels like thinking about things that are provided in other harnesses by default.

It took time to learn all of these before I managed to do something similarly useful as OpenCode, and now I am ready to use some sane defaults for things that I really know I need in Pi.