My work provides me a Mac laptop plus remote Windows VMs and I've completely stopped using my Mac for agent builds/tests - I give them ssh access to WSL instances and they can go hog wild on the VMs.

It's all a bit adhoc - agents still need to pull (or I need to keep the main enlistment up to date on these machines) - I'm thinking of using containers or something else like github actions keep things cleaner, but right now it's "good enough".

Regardless I'm pretty happy with how it's working so far. Previously I'd be letting agents do work in the background and they'd kick off builds in the middle of a meeting or something and I'd start dropping video streams until I killed everything.

It's so goddamn bad, I wish it was easier to turn all of this garbage off. I used to spend time defining parallel work lanes to issue to subagents as frontloaded development work with set validation checkpoints and it worked great. Now attempting to do this with 8, 16 subagents will balloon out into hundreds of gigs of fucking mess

Copy on write worktrees do absolutely nothing to solve this, either. The build artifacts alone will do it

If git used reflink / CoW when available it would make this a lot faster.

switching to copy on write worktrees is the biggest game changer it should become common knowledge pretty soon and it's already available on most operating systems

On Linux I’ve taken to disabling swap before doing memory heavy operations. Claude will carelessly run benchmarks and tasks which gobble up all available memory. When that happens, I’m not sure why but my system becomes unresponsive and I can’t kill the process. If I disable swap, the oom killer takes care of whatever Claude was doing and Claude figures it out after the fact.

I ran into similar issues. Sometimes though there are good language specific solutions. For Rust based worktrees you should definitely check out https://mr-boxington.jdx.dev/ .

Regarding swapping, are you sure it's not just from ram backed tmpfs partition? For me that was it and most of the swap was from /tmp. So I created an agressive job that runs frequently to delete all tmp files not used in the last ~2 hours without any command holding handles to it.

The other thing I found was that there were a bunch of leftover processes from prior coding agents forking commands and just leaving them. So I had to build a system into my agent spawner to automatically launch each agent session in a cgroup whose processes all get killed on task completion.

For the first part you might be interested in Anthropic recently creating their own version control system that's server based like SVN, and it seems to ease their memory pressure too. It's called `scion`.

> I use ZFS bc Btrfs has massive contention problems with concurrent Rust builds

I haven't read about btrfs having issues with concurrent workloads like multiple concurrent rust builds. Are there notes on this somewhere I can read?

QDirStat is free and does the job really good

https://github.com/jesusha123/qdirstat-macos

Mole is ok too

TUI version is free, though there is a paid app if that’s your thing

https://github.com/tw93/Mole

DaisyDisk is such a nice app. I just checked and I purchased it over 11 years ago.

They still update it, it works perfectly, no version 2.0 forced obsolescence. Just a nice, reliable tool.

DaisyDisk is great. Mole also found and deleted a bunch of stuff on my mac from Claude, Gemini, etc.

https://github.com/tw93/Mole

I’ve been using it altogether too much this last month and just bought a 4TB USB4 SSD.

And yes, codex is eating my disk, too. Ironically my solution is mostly codex - I have a task which goes around stomping on detritus.

It's silly I have to tell it to make part of the build process to clean old artifacts or it'll just default to keeping endless folders of test builds and old builds without cleaning them up. The same seems to usually be true with documentation and reference material.

There was a REALLY annoying period where I'd give it full control of a VM and a dedicated project folder and it'd continually refuse to delete anything I asked it to or just silently archive it, even though everything was already in a git repo. It seems to have gotten somewhat better about that now, but I still include "create cleanup scripts to delete unnecessary project content" in the default steps before doing the final merge on a change.

Heh, Claude recently (last couple of weeks) left behind several jj workspaces with many GBs of builds in my env.

Had to tell it to update it's agents.md to not do that...

Codex is obsession with validation tests. It drives me insane.

Rust is notorious for this, one thing some people do is force Rust to have a salvage yard for builds so all those dependencies are shared by everything regardless of what you are building or where, but holy moly, can someone make Rust output smaller files? Hard drives are always having some reason to never go down to sane prices.

When I was younger I thought we would be having exabyte hard drives by now.

Before Windows XP, desktop Windows users were accustomed to frequent system crashes. Viruses in the 1990s would take out offices around the world. Nothing collapsed, and nobody switched to Linux. Everyone was just used to it. I think most people will accept the tradeoffs, because it used to be much worse than it is now.

The term super intelligence makes me cringe so hard, you can just use the regular term.

You don't have to give any more legitimacy to Trump's inane ramblings than they already get.

> If OpenAI's super-intelligence can solve Navier-Stokes why can't they fix this stupid bug that ate up 330GB of my Mac's disk space?

Because the former can be marketed very prestigiously, the latter hardly can.

According to https://www.briefia.fr/en/article/openai-revendique-la-resol... it is estimated that solving Navier-Stokes did cost OpenAI 40 million USD. I would bet that if OpenAI spent the same amount of money using its super-intelligence to fix this bug, this would work.

But seems not to be very economical. :-)

because they'd need to pay a real mathematician to verify the proof they claim.