Comment by icantevenhold
5 hours ago
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.
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.
Over eager use of /tmp is the worst. That’s RAM, my boy! Precious gold.
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.
2 replies →
I just erased 20GB of Cursor’s cruft.
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.
2 replies →
Which generates unnecessarily huge binaries.
1 reply →
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.
1 reply →
They're not made of fairy dust; you can build your own.
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?
7 replies →
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).
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).
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.
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.