I just did a build in Nemesis8 (containerized agents) and Pi appears to be working fine. Opencode is a good choice too if you're interested in checking out GLM 5.2 from z.ai.
I haven't tried opencode, but when I opened pi I was able to complain about that silly and stupid left-padding that LLM TUIs have started using that prevents basic copy-paste operation, and pi was able to edit itself to fix it.
They are different models. OpenCode is trying to be a claude code/codex replacement, where-as pi is something you build yourself, kind of trying to be an emacs type thing compared to vs-code. As in emacs it is more common to write your own extensions, where as in vs-code most people just download them.
I keep butting into the question of; why opencode, when you've got codex available? Codex is open source as well, and i can't seem to picture a situation where one would want Opencode over Codex.
As far as I can tell, they tick the same boxes- but one has the support of a big boy model provider.
Well, the reason is simple: over the past several months, it has become very difficult to use Codex with non-OpenAI models. They removed the old edit tool that didn't require OpenAI's free form tool calling (that no other LLM host supports), they are adding tools to every request of a type that break most LLM hosts unless you use a proxy to filter them out, they add a "developer" role to some messages which breaks some chat templates, etc.
If someone wanted to fork Codex and make a community-maintained version that supports third party models, that would be great, because I liked Codex better than OpenCode for the most part.
Maybe you've found workarounds. Maybe you're using an old version of Codex. Maybe you have your own soft fork. I don't know. But I used to be able to use Codex with self-hosted models, and I gave up on that about a month ago as they kept breaking that.
If you care about privacy at all, you can route your Opencode requests through an inference provider that does not retain any logs or data. It is also much cheaper. So if your boxes include `Privacy` and `Affordability`, then no, they don't tick the same boxes.
oh-my-pi is a bit of a cross between the two; comes with basically everything OpenCode does, but still easy to customise.
OpenCode is nice if you don't want to do a lot of research and just want to get started right away. The OpenCode Go plan for $5 a month for your first month is a great way to do this, with good models to choose from and reasonable usage limits for a beginner.
I use Go plan precisely with Opencode IDE (and also Jetbrains IDE suite), but now also have access Gemini Pro and Claude Pro. And wonder which tooling to invest my time into, especially that MCP servers also potentially come into play here, and I want at least some models/tools to handle private tasks, like handling my increasingly-complex Home Assistant setup. And I also want to start using models according to needs (plan, execution, reviews). This shit gets extremely complicated extremely quickly, not to mention how often this field shifts direction.
I use “all of them”. My primary harness is oh-my-pi. I probably use 10 different models on a regular basis.
I occasionally use OpenCode.
I try to use Codex and Antigravity as much as I can, often using it as a secondary agent (due to different usage pricing models than API). The same skills and MCPs work across harnesses.
Edit: I don’t use Claude Code simply because I already have enough to deal with and don’t see a major advantage to their harness. I use Opus credits from my Google subscription on the rare occasion I need them.
Cursor is also worth checking out particularly at the $20 a month price tier. If you have Grok you effectively already have it too.
I expect to have a completely different answer a year from now. The main “lift” we’ve gotten from AI tools is our clients now get an Android + iOS app + macOS app + Electron + PWA to go with whatever web based app they want us to build, at essentially the same original price. (There’s also a CLI and a TUI, but so far none of them care about that…)
We just made the decision to start adding MCPs to apps. Gonna be an interesting conversation in a few weeks when I can tell my business contact he can use his favourite chatbot to now plug in directly to the custom app he bought from me.
I am genuinely curious what it tells you, as "curl https//.. | sh" has long been an enormously popular approach to distribution in the open source world. Homebrew, to name just one example, advertises a similar method.
(pi.sh also documents other install methods, like `npm`, on their homepage)
If trust and security is the issue, unfortunately "better" ideas like hashpipe [1] never achieved critical mass
I really hate the `curl <url> | sh` specifically because if your connection drops at a specifically unlucky point in time you are left with a partially executed script which if you are unlucky enough may just have been executing `rm -r ~/.cache/<pkg>/download` but it stopped at `rm-r ~/`.
Is it likely? No. Can it happen? Yea.
Just make it `curl -o <file> <url> && sh <file>` and this entire problem is gone.
Package managers: ecosystem is fragmented, requiring a long list of distro- and package-manager-specific instructions. Many scripts already install through package managers, they simply make the user’s life easier.
Flatpaks: These are clearly designed for desktop applications, with CLIs treated as an afterthought. They may be the best long-term hope, but today they are definitely not as convenient or widely available as a simple script.
If you care about adoption, `curl | sh` is the only real option today, which is why virtually all project show it as the first option.
The "like an adult" is what has and will continue to hold back linux on the desktop. Always gatekeeping less technical users instead of acknowledging adoption and ease of use are critical.
The ideas aren't mutually exclusive, and I've never seen an open source project support "curl | sh" without also supporting those methods.
Indeed, plenty of these scripts often act as a "what OS and packager do we have" mux. Just look at the source of this one, for example.
When you support an open source project at scale and/or with less savvy users, you come to see the benefit of "here, just f'ing slam this into your shell and we'll figure it out" installers. I know I have.
> I am genuinely curious what it tells you, as "curl https//.. | sh" has long been an enormously popular approach to distribution in the open source world.
It's plain horrible. You could have, for example, a compromised server serving malware but only one out of every 100 download. The only signature you rely on is TLS.
Proper package distribution are using proper signatures schemes, are decentralized, even for some offer reproducible builds (meaning you can rebuild the whole package yourself and verify your build matches), etc.
Hashpipe is an attempt at reproducing some of those guarantees. Not unlike container pining using hashes. It at least fixes the "Jack and John installed this already and I know I'm getting the same version as they did".
Proper software distribution is signed, reproducible and ideally also uses some proof-of-existence for the hashes.
My bet is this: in the face of the countless supply chain attacks, we'll see more and more people getting very serious about security, including the security of software distribution. And curl bash'ing won't be part of it.
There is no threat model that doesn't also apply to pretty much every other distribution method.
It's just people who have internalized "don't paste commands from the Internet into your terminal" and aren't thinking about exactly what makes pasting commands from the Internet into your terminal dangerous, and how that applies to this specific case.
it tells you they're just like basically every other CLI targeting project for the last 15 years? I mean is it a big security hole we all accept, yes, it is. But it's not really indicative of much. That's also how I install rust.
Further - what the flicking fuck do you think an installer is going to do on your system? Not run any commands? Because I've written installers for every platform... they ALL can run commands.
So what exactly is the complaint in this comment? If you want to go read the install script - knock yourself out (or hell, point your agent at it...).
Understand that 99% are comfortable trusting downloads. They know that it's just as easy to sneak backdoors into source code as it is to sneak backdoors into executables.