My Rust target/ said 325 GB. My disk said 1.65 GB free.

so last week my Mac said the disk was full. like, actually full. 1.65 GB left out of 494 GB.

I ran du on my Rust projects and target/debug came back at 325 GB. ok. found it.

I posted the screenshot on Threads, three lines, asked how everyone else deals with this. got 140 comments lol. so I tried the suggestions.

some context. I'm building a Rust CLI called Contexere (used to be OMNI), and I run a few AI coding agents on it at the same time, each in its own git worktree. every worktree builds its own copy of every dependency. debug, test, release, each with their own copies too. that's how one folder gets huge without you doing anything weird.

what people told me

• cargo clean more often. one guy runs it from a post-merge git hook, so every pull on main starts clean. smart.
• symlink target/ to an external SSD, or a NAS
• buy a bigger disk ("512 GB is the minimum for a Mac now", more than one person said this haha)
• kache + blaze combo
• stop building on the laptop, code on a remote server

the two tools I could actually measure, so I started there.

kache

kache sits in front of rustc as RUSTC_WRAPPER, hashes every compile input and keeps the output in a shared store. so a second checkout of the same project can reuse what the first one built.

I tried it on two worktrees of my repo, cargo build --locked, debug. disk measured with df free space before/after, because on APFS du lies (remember this, it comes back later). one run each, so take it as rough.

second worktree: 230 of 232 crates came from the cache, 100 s down to 42 s. nice.

but the first build was 48% slower, and the store eats disk too (default budget is 5% of the volume). it pays off when you have lots of checkouts of the same project. I only had one extra worktree at the time, so not worth it yet. uninstalled, will look again when I'm at 3+.

blaze

didn't even install this one, its own docs answered it. blaze is about fast incremental rebuilds and it's impressive at that. but no clean command, no GC, no size cap. on macOS arm64 their benchmark shows ~1.5x the disk of cargo (598 MB vs 416 MB on ripgrep), and the daemon uses 2.6 to 2.9 GB RAM on small projects.

my Mac has 8 GB RAM and a full disk. so no.

both tools make builds faster. my problem was never speed. it was disk.

what I ended up doing

one comment just said "time to code on a remote server". I took that literally.

my Mac now does 3 things: write code, commit + push, and tell a cloud VM what to run over ssh. everything else runs on the VM. builds, tests, lint, the full CI gate, dev servers, even browser screenshots.

git archive HEAD | ssh myvm 'tar -x -C ~/project' ssh myvm 'cd ~/project && make ci' 

shipping from a commit with git archive means .env, local data and gitignored stuff never leave the laptop. only results come back.

full gate (fmt, clippy, tests, security check, binary smoke test) runs green there in ~4 min cold. I still cargo clean at the end of a session, never in the middle, otherwise every build after it pays the full compile again.

ok but about that 325 GB

this is the part I got wrong. if target/ was really 325 GB, cleaning it would give me 300+ GB back. it never did.

a few days later, before a big cleanup, I had 34 GB free. then I deleted other junk (48.5 GB of old node_modules, an 11 GB VM bundle from a desktop app, some apps I don't use anymore) and got to 139 GB. nowhere near 325.

on APFS, du can count clones and hardlinks more than once, and a cargo target dir is full of hardlinks. so the real size was way smaller than what du told me. if you want to know what a cleanup actually frees, compare df before and after.

worth it?

to be fair, most of the room came back from that big cleanup, not from moving builds. what the VM changed is target/ on my Mac is 0 B now and stays there, and df shows 136 GiB free. building remotely adds a few seconds of ssh + copy, and offline I can't run the full gate. fine for me. the laptop is for writing code now, and a VM is cheaper than a bigger SSD.

one Rust project and a big disk? cargo clean in a git hook is probably enough. lots of worktrees of the same repo? try kache. agents building in parallel on an 8 GB laptop like me? move the builds somewhere else.

the project behind all this

the repo that kept filling my disk is Contexere, formerly OMNI. the one place for the skills, keys and memory of every agent you use. written in Rust.

right now it ships the context layer. when an agent runs a noisy cargo test, it keeps the result and the failures and drops the progress noise. when the agent reads a file it already read, it gets a one-line handle instead of the whole file again. tokens and passwords in the output it rewrites get redacted. nothing is deleted, one command brings back whatever it trimmed. skills, keys and shared memory across agents are next.

brew install fajarhide/tap/contexere && contexere init 

still early. if you run agents all day too, try it and tell me what breaks hehe

how big is your target/ right now? 😅