It also fills up my HD with old versions. I investigated and it took up something like 12 gigabytes in total on my system; which seems insane to me, it’s just a harness?
People moan about how badly made Claude code is but Codex seems much worse on every metric
All of the harnesses I've used are terrible at cleaning up after themselves. They leave all kind of clutter behind, to the point where on my dev VM, I now have an LLM run once a day to just look through the disk and delete everything that looks like it's leftover garbage.
It's like fighting fire by employing an arsonist.
Running an LLM to delete files seems like overkill to me. Couldn't a cron job do the same thing? Or is the clutter just put into random places, which, if true, seems like bad software, which then leads me to consider the output of LLMs in general, which then leads me to wonder why are we doing this?
But, I'm just wondering.
Installed "clor.com" and it got into a loop of downloading its docker image from ghcr them throwing it away immediately because it was supposedly out of date (iirc). 65mbps continuous transfers for a week until I looked at my network traffic and saw 500gb of rx per day.
I just erased 20GB of Cursor’s cruft.
Is that cruft or past conversation history / subagent history and observability logs?
Just garbage. Temp files, worktrees that weren't removed after subagents finished, build files... all kinds of things.
But that's agent behavior, and not harness responsibility...?
Harnesses should be responsible IMO for managing lifecycle stuff, including worktrees and temp files.
It’s simple, deterministic stuff. At least most of the time.
Over eager use of /tmp is the worst. That’s RAM, my boy! Precious gold.
I don't think that's always true.
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??
Harness problem, or model problem?
Let's be real, what do you think wrote the harness?
> I now have an LLM run once a day to just look through the disk and delete everything that looks like it's leftover garbage
...are you sure it wouldn't consider your personal files garbage?
"In my dev VM". Everything of value in there is in a git repo.
Can't wait until we get really well designed harnesses written in a compiled language that doesn't bloat my computer. Will probably have to be written by a company other than OpenAI because codex is like the exact opposite of everything I just listed
Codex is written in rust, fyi... Not that I disagree.
Oh, I haven't been keeping up. I assumed it was still TS since it prompts me to run npm all the time.
They just use npm as a binary delivery mechanism, for whatever reason (I guess they expect all their users to have npm?)
It's pretty darn ubiquitous, yeah. Plus enterprises tend to run npm mirrors, so delivery integrates into existing IT compliance frameworks.
Which generates unnecessarily huge binaries.
It's because they statically linked it, and probably rely on a trillion pointless crates (as is standard in Rust development). A good statically linked harness can easily be ~5MB MAX
Found this one: https://usehax.dev/
Anyone experiences with it?
it's okay.
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.
(author passing by) Could you please report the issues you've experienced on the repo? I did quite a bit of testing myself on local models (Qwen, Ornith, Gemma, Muse Glimmer) with llama.cpp, and they all worked fine. Details would be helpful.
Also one brief note for Codex users specifically. hax can work out-of-the-box as codex-cli drop-in replacement (since it can use the already authenticated codex token), so it's super easy to try it - basically it will be a zero-config experience.
Just write your own harness. Ironically Codex/Claude are both abysmal.
How do you even write a harness that can use a Claude subscription? I thought it was not allowed by Anthropic's ToS and can get you banned?
Amp recently achieved it. Apparently it's permitted as long as you use the Claude Agent SDK. https://ampcode.com/news/use-your-claude-plan
It's trivial to bypass this by tweaking the system prompt in other harnesses. They use string matching and a blacklist.
https://x.com/FlorianKluge/status/2041855675295318039
(Whether that's against the ToS is not clear.)
That’s a different discussion.
I suspect a lot of people wouldn't use AI if they had to pay per token at current rates. Yes, it's technically a different discussion, but "just write your own harness" isn't really an answer for the vast majority of us riding on the investor-subsidized subscription plans.
If you're using the sub, only OpenAI (via the OAuth token) is viable. Claude is API_KEY only
It's allowed, but you get bumped to per token pricing.
Not true; They rolled back some of the changes you're thinking about IIRC.
That defeats the purpose of using the Claude subscription.
I did, and the weird things you have to do to make work at least decent. I’ve been doing evals and I got some things better than opencode but not as good as pi. Though my goal is to optimize for a browser and browser based llm so it can create stuff in a web container or at least generate ui by requesting json schema (a2ui style).
They're not made of fairy dust; you can build your own.
Omp
> People moan about how badly made Claude code is but Codex seems much worse on every metric
Also, it feels that chatgpt.com and aistudio.google.com are the buggiest websites I have seen for long time. Why it is always something related to LLMs?
All the LLM turds we've curled out at work are the same.
It’s actually insane how buggy the Gemini web version is (or at least was a few months ago, since I stopped using it).
It's improved. The scrolling used to be terribly glitchy and would make it difficult to read as text was generated.
But in the same fix, they also removed the reasoning-sample, which kinda sucked.
Because they're the most likely to be 100% vibe coded. And as much as some people still deny it, AI code = buggy code.
ChatGPT.com is dreadful. The whole thing chokes when the conversation gets moderately long. It's amazing that it's been allowed to stay this way.
[dead]
My preferred Nix package for this patches at least that behavior out, afaict: https://github.com/numtide/llm-agents.nix/blob/dc285bfd94ec7...
https://github.com/numtide/llm-agents.nix/
It’s extremely ironic that the software that’s meant to end software is itself pretty terrible software.
for some reason I had 11 separate codex and codex-code-mode-host binaries in my ~/.bun/install/cache/@openai . each weighing about ~300 MB. might be worth a look to anyone running low on disk space.
Don't get me started on my custom NES harness, it generates ~10MB per turn. At least the harness itself is pretty tiny
I haven't worked with the update subsystem before but that seems like an oversight to me. I'm gonna fix it.
Yep, .codex/packages/standalone/releases keeps all the old versions. Also each codex bin is somehow ~300MB.
thanks, I just removed all the old stuff.
what's the lazy way to check? can you share where/how you cleaned up?
Even if you installed codex with brew?
Remember: VSCode runs a complete headless Eclipse instance as its Java LSP, so I don't expect quality code from any of the big companies anymore.
Are you referring to something built into VS Code, or an extension? It looks you're talking about https://github.com/redhat-developer/vscode-java, which is RedHat's doing.
Yes, my DEV VM tended to fill up with VSCode backups as well. I finally expanded the disk so it's less of an issue today, but for a while ENOSPC was resolved by cleaning up ~/.vscode-server/cli/servers.