Your Coding Agent Is Eating Your Disk

Of all the programs most of us run every day, a coding agent is the hardest one to see into. It writes files we never opened and kicks off work we didn't schedule, and it keeps a long history that nobody reads. So when it's taking up 50 GB of disk, most of us honestly can't say what's in there. We went and looked. On one developer's Mac, AI tools were holding **72.6 GiB**. Codex alone was 53.7 GiB across 21,613 files. Claude Desktop had 11.8 GiB, and 10.1 GiB of that was virtual-machine bundles. Then Cursor at 5.4 GiB, Claude Code at 1.5 GiB and Gemini CLI at 0.2 GiB. :::agent-product-shot The total itself isn't that surprising. Every developer we've shown this to has a number like it. What surprised us was what the bytes actually are. Almost nobody guesses it right, and we didn't either. ### The text is small The usual guess is that a long-running agent writes a lot of text and the text adds up. It doesn't, because text takes almost no space. We streamed the 50 largest active session files (10.9 GB in total) and hashed every embedded payload on device. Images accounted for **8.43 GB of the 10.9 GB**. So 77% of this "conversation history" is pixels: screenshots the agent took, images it generated, and visual tool output it looked at once. Then we checked how many of those images were unique. Of the 8.43 GB, only 5.17 GB were. **3.26 GB, or 39%, were copies of something already stored in the same file.** That's 17,643 embedded images, of which 11,790 are distinct and 5,853 are repeats. :::agent-composition ### How compaction makes copies The way this goes wrong is pretty simple. A long session eventually runs out of context. To keep going, the agent compacts its history. It summarises what happened so far and carries on from the summary, which makes sense and is necessary. In these sessions an image is stored whole, inlined into the record as a data URL. There's no path to a file on disk. And when a compaction record gets written, some of them re-embed the image payload they just summarised instead of pointing back to it. So round one carries the original. Round two carries the original plus round one's copy, and round three carries all of that again. Each compaction makes the history bigger, and the growth is linear in the size of all the images that came before. :::agent-duplication-anatomy The largest single session file we looked at was 14 GiB, all one conversation. It had 359 compaction events and 13.6 GiB of embedded image data, and the unique image content in it was only **155 MiB**. 99% of it was the same pictures repeated. Five of the images showed up between 45 and 136 times each. At that point the compaction records are mostly copies of images the file already had. ### Where the bytes came from There's a popular explanation for agent disk bloat going around right now, and it sounds convincing. Agents spawn subagents, subagents inherit the parent's history, each branch copies the payload again, and the tree keeps multiplying, so more agents means more copies until the disk fills up. We believed it too. But the machine has the data to check it, so we checked. Codex keeps its own thread database, and it includes a table of spawn edges that records which thread created which. We matched every rollout file on disk to its thread and looked at where the 50.4 GiB sat. :::agent-attribution Root sessions started in the editor: **32.9 GiB, 65.4%**. Spawned subagent threads: 15.1 GiB, 30.0%. Command-line sessions: 2.1 GiB. So two thirds of the bytes had nothing to do with subagents. This changes what you'd do about it. If fan-out were the cause, the fix would be about how you run agents: fewer of them, lower concurrency, more careful delegation. That's useful advice, but on this machine it would have fixed a third of the problem at most. The cause is the re-embedding, and that doesn't need a subagent, only a long conversation with pictures in it. Subagents make it worse by multiplying it. If you only cut down on subagents, the duplication is still there. If you remove the duplication, the subagent threads get smaller too. ### "Archive" does not free anything One more thing, because people lose afternoons on it. Archiving a conversation in the agent just moves the file from one directory to another. On the Mac we measured, 1,174 archived conversations still held 16.1 GiB. Archiving keeps the list tidy and doesn't save any space. You only get space back when something is actually deleted. ### Reading 14 GB without killing the machine A quick engineering note here, since this almost ended the whole investigation. Our first analyzer streamed those session files with Foundation's `FileHandle.read(upToCount:)` in a background loop. Every call returns an autoreleased buffer and nothing drains the pool until the loop ends, so the process just holds on to everything. Reading 1.15 GB left 1,097 MB resident. When we pointed it at a 14 GB file, the Mac ran out of application memory. The rewrite uses POSIX `open`/`pread` into one reusable buffer, and the same 1.15 GB read holds 14 MB. After the rewrite, the full inventory pass covered 72.6 GiB in 8.6 seconds at 28 MB resident, and the deep hashing pass streamed 10.9 GB at 42 MB. There's also a runtime check on it: if resident memory grows by more than 256 MB while one file streams (or by more than a sixteenth of the file, for very large ones), the pass stops itself instead of taking the machine down. We bring it up because without this, a tool can't look inside these files at all. Nobody can ship an analysis that needs 18 GB of RAM to run. ### De-duplicate instead of delete Once you know the bytes are duplicates, deciding what to do gets a lot easier. Deleting a conversation throws away work: the reasoning, the diffs, why a decision was made. Nobody should be pushed into that just to get disk space back. De-duplicating inside a conversation doesn't lose anything. The first occurrence of every image stays where it is, and each later duplicate becomes a small marker that points back to it. :::agent-the-fix The conversation still opened in the agent and the screenshots were still visible. Because the first copy never left the file, the change could be reversed byte-for-byte from the file itself, with no vault and no outside state that could get lost. We shipped that first, as **Optimize**, and what it claimed was true. Then we ran the same measurement over the entire store instead of the fifty largest files, and three things came up. In-conversation duplicates were the smallest of three pools. Most of them were in conversations still in use. And a forked conversation can depend on another file's bytes, which makes rewriting the base in place unsafe. The full census is in [What 22 GB of Agent Conversations Is Made Of](/build-journey/what-22-gb-of-agent-conversations-is-made-of). So is what replaced it. The button is still called **Optimize**, but now it keeps every word and turns every screenshot into a small preview. Some things stayed the same. **Delete permanently** removes whole conversations through the agent's own archive and delete calls, so its index stays consistent. Nothing is pre-ticked. Every run asks you to confirm before it touches a file. Neither Optimize nor Delete permanently can be undone, and Mint tells you that before either one runs. ### What we learned Agent storage feels like a black box mostly because nobody looks at it. It isn't that complicated. The files are plain text on your own disk, the thread database is a SQLite file you can open, and you can measure the duplication with a hash function in an afternoon. We went in expecting to write "agents generate a lot of data, here's a cleaner." What we found was more specific: most of it is the same data stored again and again. You can see exactly how much, per file, on your own machine, without uploading anything. That's why Mint shows you the numbers and the reason, so you don't have to just trust it. It doesn't delete a conversation unless you pick Delete permanently. Optimize keeps every word the agent wrote and shrinks the pictures, since that's where most of the space went. --- *Every number here was measured with Mint's own scan hooks on one developer Mac in August 2026. The scans are read-only, run entirely on device, and you can reproduce them on yours.*

How this was measured