Codex CLI installs a persistent, self-updating background daemon by default

it's minimal and somewhat opinionated, not integrated well with memory subsystems (although that's kind of the point)

my only real criticism is that last I played with it it deals with slow provider responses very poorly , so lots of locally hosted llms require a lot of tuning to get it to handle streaming/non-streaming/timers well.

way less minimal (but still pretty minimal) I prefer Pi; but different markets I think.

hax fit my openbsd laptop well, espescially since Pi and related derivatives are kind of un-spokenly incompatible with the BSDs.

So far I have very positive experiences, the results are generally better (and not just faster) than in other harnesses with the same models. I've done the same (user) prompts for tasks in a range of them, and compare the outcome to eval between them. Simple (harness) beats complicated one many times. I do wish it could use MCP though, but not as often as I think, and CLI tool usage often compensates on this front with little extra effort)

That is now my usuall go-to harness for things usually. Still figuring out the edges though (when we get off the happy path, like models reaching their max context, or such...)

It's very light, recommed you try it out, and see if it fits your toolbox.

And it worked. I'm switching to this unless i find a reason not to.

my main issues with maki are that the line editor (what you use to enter your prompts) is very barebones, copy-paste is broken (no middle-click paste, or copy to PRIMARY; implicit copying to CLIPBOARD that can only be used with a mouse), and scrollback is not native. So it's not a real cli, but some sort of weblike tui.

I tried 3code; it does not mess with selection, but code printed in the conversation has | markers in every line, and is thus uncopyable in practice. Don't know how to use that.

Although I just looked into it, and even Ubuntu 26.04 appear to default to tmpfs for /tmp storage, so I guess it's fairly universal now.

Not sure if I agree with that idea in principle... What's wrong with just wiping it intermittently??

But in the same fix, they also removed the reasoning-sample, which kinda sucked.

Chat sessions are not metered by token usage but rather a fairly high limit of messages per day or something.

The longer chats you have, the more context and token input. So I think that discourages longer chats, and encourages users to start new chats.

you can also switch the model at any point too after resuming.

But honestly i dont think there is that big a difference between these “minimal harnesses” to begin with so long as they have the basic functionality…

The future is here! It's a shame it has to be _this_ future...

Firefox does not only not prompt me for updates (it only updates if I manually run an update), even if I do update with Firefox running, it does not stop me from continuing to use Firefox without restarting it. All I did was install Firefox from flathub (packaged by Mozilla (a default configuration provided by Mozilla)).

Jokes aside I do the same I tend not to upgrade my Mac, my phone unless I really have to.

The “update” button on the top of my brave install has now turned from green to orange and I’ll likely wait until it goes red

There are contexts where "move fast and break things" can make sense, but usually not when it's other people's workflows that you're breaking.

Just how old do you think a category of software product needs to be before it's reasonable for users to start expecting professionalism from the developers?

But I am not satisfied. I am trying to find a really lightweight container/VM for macOS that eats very less RAM on its own and expands as needed. Because I really don't want to run an agent outside a container on my mac.

The thing that really validated this point was when I recently tried Codex again. Out of the box it was OK, but not great. I swung over the memory apparatus and had it import directives from my existing Claude install and it was almost immediately quite useful in its own right and, especially, as a counterpoint to Claude when dealing with some fairly complex operational issues.

Maybe it's like online services/tools. Use them until they are VCed and gone pivoting and then move to another tool.

That's a pretty bold use of "has to". None of the financing behind AI seems sane, yet it continues to defy rational expectations. Reminds me of the comment "the market can remain irrational longer than you can stay solvent". It's not the exact meaning but has the same feeling. The circular financing going on does not help anything either

I think that's exactly the standpoint of Yann LeCun.

The same story for Google's products - their products were always buggy even before AI. And so is the case for Microsoft.

I think the reasonable argument is that AI or not, software problems are hard problems to solve. And software is constantly evolving. AI isn't a magic wand. It also depends a lot on the humans using it, including prompting and context supplied to it.

Drawing a massive conclusion from a tiny, unrepresentative sample is just hasty generalization.

> [...] vs something that's rickety

A 100 percent of modern bridges are rickety. There has been dozens of high profile incidents because of this.

> Just because you built something that might fall apart at any moment doesn't mean it's been engineered with narrow tolerances.

Here the software they are building falls apart in ..say.. two days of use, but can be updated in 5 seconds at close to zero marginal cost. The software is useful enough that people keep updating and using it. This iteration gives them a competitive advantage over the safer choice of rigorously testing every new thing for several weeks.

That's why I didn't mind it when Pi added native MCP capabilities. What dismayed me was they didn't other tools like subagents, and other stuff. I mean why do I have to scour the Interwebs to find something that doesn't possibly screw everything up for me.

I have a feeling harness usage will finally move to lots of harnesses with usage clusters - as in not X million harness for X million devs/users but a lot and people will use what suits them, and if not a more inclined coder will fork/make one just for them. In all their faults LLMs have made this a possibility.