Posted by rob 8 hours ago
Try Zed[1] for GUI and pool[2] for TUI.
[1] https://zed.dev/
So I'm sold on that level alone. Good stuff.
As far as I can tell, they tick the same boxes- but one has the support of a big boy model provider.
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.
From watching Pr's and issues- seems like openai at least wants to come across as if theyre supporting non-oai models :/
You would think they would support their own GPT-OSS model, but, not really anymore. I wish they would release a GPT-OSS 2, but this doesn't fill me with confidence.
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 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.
One caveat is that it doesn't do MCP tools, but can wire them up with bash (or use CLIs if those are available).
(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
[1] https://news.ycombinator.com/item?id=9318286Is it likely? No. Can it happen? Yea.
Just make it `curl -o <file> <url> && sh <file>` and this entire problem is gone.
(At least for bash scripts, I’m not sure whether these are POSIX syntax to be frank.)
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.
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.
There's plenty of big projects that don't suggest you curl a script right into your shell.
If you have curl, you're probably on Linux. Just use the package manager like an adult.
what has worked over time is having computers of various types in schools, where teachers teach students and let them play with it.
nobody teaches about the command line, so nobody knows what to do with it. its also inscrutible without a useable help view, unless you already know how to use the terminal
I’m all for higher Linux adoption on desktop, but there’s still a lot of resistance to making less-skilled users the primary target instead of power users.
Teaching can help, but if it takes 50 hours to learn the basics of Linux versus 5 hours for Windows, it’s a losing battle.
Users need to figure out which of the 10+ package managers they should be using, then run several commands. If something fails, the error messages are often cryptic and not easily configurable by the distributor.
And that’s before getting into the many rough edges of package managers. Most of them flat-out refuse to handle configuration and leave that part to the end user. Now you also need to document how to edit YAML and restart a systemd service. With an install script this is also solved.
For power users, this always looks trivial. In practice it raises the barrier to entry and can meaningfully affect adoption if your product is often used by less technical people.
In what world does a user have to choose between 10 package managers? Each distro has exactly one. There are also only about three, maybe four main package managers out there.
A shell script being piped into bash has so many more ways to break than a package. And if yhe theory is that package managers are fickle (they aren't), then how does adding more complexity help?
It is much simpler, much safer, and easier to maintain a package than an install.sh, eapecially for a big project.
Configuration can be handled by a script, yes. Here's a crazy idea: Your package can include scripts for configuring the software. It's almost as if most packages do. The scripts/utilities could even restart a systemd service for you.
Unless you're talking about configuring your build, in which case we're dealing with an experienced developer who will have no trouble just cloning the repo and building from source.
My biggest issue is: if we're dealing with someone who can't use a package manager, we're dealing with someone who doesn't have the capacity to judge how safe a script downloaded off the internet is. This does not drive linux adoption, it drives botnet adoption.
I'll stop there. I'm not interested in continuing this discussion when it's being conducted in bad faith.
Rather than argue with those of us who are pointing out messy realities, this commenter might be better served filing a bug against any number of the projects that offer installation this way, asking them to remove it, and see if it lands any better.
Technical purity/superiority isn’t the only factor, or even the most important one, driving projects to offer quick installers like this.
IMO a lot of the blame falls onto the package manager ecosystem refusing to take into account very valid needs and claiming they aren't real / desirable.
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.
curl -fsSL https://claude.ai/install.sh | bash
Oh wait (from another comment under this article): > https://pi.dev/models is throwing an internal server error for me.
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.
/s
Maybe security should be at a higher position on our priority list.
The careless days are ultimately over but we still don’t act like that.
oh wait...
"curl -fsSL https://claude.ai/install.sh | bash"
(right from https://claude.com/product/claude-code)
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...).
Because then you can install it without depending on a package manager?
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.
See also: XZ hack.
I would never runa script without reviewing it. I would install a package from a distros repository without reviewing the contents, however, because I can trust that a distro maintainer has reviewed it, that anyone else in the community can review it, and that that the bytes I'm downloading are the specific bytes I'm supposed to be downloading.
If you run a script off the open internet, you're being massively irresponsible. There are so many attack vectors that could be used here, and they are much easier to implement than something like the massive social engineering attack that was XZ.
You think it's hard to obfuscate shell calls from inside a built executable?
What it tells us is that you're probably searching for reasons to grouse about AI.
I get the power of LLMs, and I do find them useful. But I find them useful in much the same way I find a really good set of random tables useful, or a good set of rules for procedurally generating something like a star sector for a science fiction campaign.
For my day job developing software, and for the RPG campaigns and books I run and publish today, LLMs are, in many cases, random tables on steroids. After using them for two years, even with all their improvements, I am continually reminded by the results I get that, at the heart of it, I am still dealing with what amounts to randomly generated content.
Yes, I know it is more accurate to call the process probabilistic rather than random. And yes, somebody can construct a technically deterministic setup with fixed weights, fixed seeds, fixed sampling parameters, and a frozen runtime environment. But that is like saying you can recreate a rainstorm if you get a thousand butterflies to flap their wings in exactly the right way. It may be technically true, but it is not how the technology behaves in normal day-to-day use.
For practical purposes, given the same prompt and the same apparent starting conditions, the result can differ each time you use a model. The outputs will often be highly correlated, and often useful, but they are not deterministic software in the ordinary sense.
So far, I am failing to see how the inherent probabilistic nature of the technology can be fully overcome. I understand how we got to where we are today from older neural net technology, including the systems used for vision and sound. What we have now can be very useful. But my view is that it is being badly oversold and overhyped. Its probabilistic nature is being vastly underestimated, and that is a major reason for much of the weirdness and many of the failures we keep seeing.
In tabletop roleplaying, there have been times when hobbyists relied too much on procedurally generated content and ultimately got burned by it, either through campaigns that were not as fun or products that were subpar. Each time, the lesson was the same: there is no substitute for human judgment.
Any workflow or technology incorporating LLMs has to keep humans in the loop, and not merely as rubber stamps. The human has to remain the primary decision maker.
I deeply hope we never reach the point where that’s overcome. What we’ve seen over the past few years is how AI will destroy humanness from pretty much the entire digital realm. It’s by far the most evil, anti-human technology ever created, corrupting everything it touches. The last thing we need is for it to become reliable
For many of these problems, I think it is likely that no deterministic algorithm can exist because the problems are fundamentally underspecified. E.g. a common task in computer vision is generating a 3D depth map from a 2D image. This is inverting a lossy projection, so any solution must be a least partially a hallucination.
I think we just have to accept this. It's a different type of algorithm, built out of statistics instead of logic, with different strengths and weaknesses compared to traditional software.
Now, biology exists. It’s wet and messy and impossible to understand (we haven’t invented the microscope yet). That doesn’t mean biological study is not worth doing.
This is common in image generation pipelines because if you find an image you really like, you can store the seed and then reproduce it with small tweaks, otherwise - to quote Borges - “Look at it well. You will never see it again" User-facing deterministic pipelines do exist for generative AI.
I know you make this argument in your post, but that's really the answer if you want repeatable results. For a classifier or a detector, determinism is a requirement, but for an LLM non-determinism desirable property because it feels like a more natural conversation. The downside is it's extremely difficult to replicate a response without pointing the model to an earlier conversation.
And specifically for the RPG case, don't you want non-determinism? You don't want the model spinning up the same identical person if you say "Generate me an NPC character sheet for an innkeeper". This was a complaint that people had in the past, that models would regurgitate the same scenarios or the same jokes.
Where I suspect DMs run into trouble is not randomness, but lack of self-consistency in worldbuilding. Say you generate an NPC and then refer back to them later and the model gets some details wrong. You could compare to a system like Dwarf Fortress where everything down to the genealogy and faction relationships are rigidly generated.
LLMs can contribute quite reliably given very narrow prompts and short horizons (keeping turns low and context brief). If you chain a bunch of these narrow contributions together and define guardrails (structured outputs, online evals, other-llm-as-judge/jury, etc...) you can produce a very repeatable workflow that reliably delivers to defined service levels.
The obvious issue being - you've got to define the workflow and implement all the guardrails, not hope that the LLM will infer them during a session or a one-shot prompt.
Those chemical interactions and quantum effects lead to emergent properties like judgment, experience, context, accountability, and an understanding of consequences. Those are not properties that LLMs possess, regardless of how useful their output can be.
That is not to say that, in the future, LLMs won’t be used as part of other systems that add some of those properties. But that is not what we have today, or what can be seen in the foreseeable near future.
What makes you say that? Other than the usual "I'm a human, and humans must be very special, so when something that's not a human does X, it's either not real X, or X wasn't important in the first place".
It highlights, in my eyes, that "critical flaws" of LLMs are the same exact flaws that humans routinely suffer from. Sometimes LLMs have it worse, but sometimes they have it better too.
LLMs do improve release to release though. Humans are more of a mixed bag.
Computed from the page’s own data for 2026-03-26 through 2026-06-23:
- Partial outage: 43h 15m 1s
- Major outage: 6h 46m 48s
- Total affected time: 50h 1m 49s
- Major-only uptime: 99.6861%
These stupid SLAs in the SaaS contracts should be reframed like this: 99.9% during working hours, not 99.9% overall. Would also give the SaaS vendor leeway to only guarantee 90% availability outside working hours, and then do their maintenance tasks in those windows.
> Optimize your bottom line for token spending so you collect $$$$
> Release Ultracode feature that optimize for Token Spending (a.k.a Dynamic Workflows)
> Tokenmaxxing achieved + 529 Overloaded unsustainable APIs everywhere
This video, wow: https://www.threads.com/@founder__growth/post/DZz_9Ikj3Wx
Out of desperation, I moved to ChatGPT and it's working better than I remember. All these companies are playing games under load, under failure. No wonder we can't agree on what's good for what.
ClaudeCode still has a 99.27 % uptime
ClaudeCowork has 99.52 % uptime
ClaudeForGovernment has 99.93 % uptime