What 22 GB of Agent Conversations Is Made Of

Last month we opened one developer's agent storage and sampled the fifty largest conversation files. Seventy-seven percent of the bytes were images; thirty-nine percent of those were copies. That was a sample, and a sample answers "what is in there" only roughly. So this time we read all of it. Every conversation file in one Codex store — **1,231 files, 22.83 GB** — every embedded image fingerprinted, every fingerprint compared inside its own conversation and across all the others, every conversation dated by when it was last used. Not a sample. A census. The census changed what we shipped. ### Seven bytes in ten are pictures :::census-composition Images are **16.18 GB** of the 22.83. Text — prompts, tool output, the agent's reasoning — is 6.65 GB. Nothing else is worth naming: audio rounds to zero, there is no video, and there are no build products, only build *logs* inside tool output. The interesting split is inside the images. Only **3.81 GB** are pictures the store holds once. **5.71 GB** are repeats of a screenshot that already sits earlier in the same conversation — the compaction mechanism from the last post, re-embedding what it just summarised. And **6.66 GB** are repeats of a screenshot that sits in a *different* conversation: the same terminal, the same page under test, pasted into another thread days later. Put differently: of every ten bytes of "conversation history" on this machine, seven are pixels, and fewer than two are pixels that exist nowhere else. The text has a smaller version of the same shape. About **2.7 GB** of the 6.65 is the same text written twice — the agent records each completed step once as the step and once as the event that completed it, and a command's output lands both as the output and as an aggregated copy, each capped at a megabyte. One long build log can be stored up to four times. We measured it; we do not touch it. That is the agent's own reader contract, and a tool that rewrites what another program relies on has stopped being a cleaner. ### The duplicates are recent The obvious cleanup axis is age. Show the user a slider — "untouched for 7 days, 14, 30" — and let them clear what they no longer use. Every storage tool has that slider; we did too. Then we sorted the in-conversation duplicates by the age of the conversation they live in. :::census-duplicates-by-age **92% of them sit in conversations used within the last six days.** The single largest file on the machine — 1.76 GB, 3.9 days old — held 1.57 GB of repeated screenshots on its own. Conversations older than a month held 0.02 GB between them. This is not a quirk of one Mac. Duplication is a property of *long, recent, screenshot-heavy* sessions: compaction only runs when a conversation is long enough to need it, and it re-embeds the images of the session it is in. Old conversations were short or textual or both. So a cleanup that starts from "what haven't you touched for a week" points away from almost everything worth reclaiming — and a user who drags the slider to seven days, presses the button, and gets 151 MB back has been told, in effect, that there was nothing there. There was 5.7 GB there. It was under the other end of the slider. ### Five depths, one ladder Once every byte has a fingerprint and an age, you can price every cleanup strategy before running any of them. Here is that ladder for this store: :::census-depth-ladder Deleting conversations untouched for five days would free **16.02 GB**, and it is the only strategy that touches text. It is also the only one that destroys something you might want back: the reasoning, the diffs, the record of why a decision was made. In-conversation de-duplication — the idea we shipped first — frees **5.71 GB** across the whole store, of which only **2.73 GB** sits in conversations the user has archived and stopped using. Across-conversation de-duplication would free **6.66 GB** more, but it needs a shared store that the agent knows nothing about, and an undo path that depends on that store surviving. We measured it and did not build it. And replacing every screenshot with a small preview — keeping the text, keeping the conversation readable — frees about **9.7 GB** of the archived conversations alone. The 49,597 screenshots in those files come to 10.31 GB; their previews come to roughly 0.6 GB. That ordering surprised us. The clever strategy was the smallest. The honest one was the second largest. ### A conversation can depend on another one's bytes One more thing the census turned up, because it read the file headers and not just the payloads. Agents let you fork a conversation — branch off from turn 30 and continue somewhere else. The forked conversation does not copy the first thirty turns. It records *"my history is the first 117,348,378 bytes of that other conversation."* A byte offset, into a file it does not own. Shrink the base — de-duplicate it, compress it, touch it in any way that moves a byte — and the offset now points past the end of the file. The agent refuses to open the fork: *cutoff byte offset is past the source rollout.* On this machine, 22 of the 1,231 conversations are forks. Sixteen were fine. **Three had been broken by our own earlier de-duplication**, which had shortened two base conversations without knowing anyone depended on them. Three more had been broken by the agent itself, which had shortened bases of its own. We restored the two bases byte-for-byte — the first version's reversibility earned its keep — and the forks opened again. And the tool now refuses to change any conversation that another one is based on, before it reads a single payload. The lesson generalises beyond agents: a file that looks self-contained is not necessarily self-contained, and the cheapest safety check is to ask the program that owns the format whether it can still read what you produced. We now do that with the agent's own reader after every change. ### What we shipped instead Start from what the user actually wants. Nobody keeps an agent conversation for its screenshots. The screenshots were the agent looking at a terminal, a failing test, a page it was fixing — workflow, not work. The work is in the repository, the pull request, the deploy. What people come back to a conversation for is the *text*: what was tried, what was decided, why. So the verb we shipped is **Compress**. Pick the conversations you still want to be able to read; every screenshot inside them becomes a small preview, every other kind of media a placeholder, and the text is not touched. The conversation opens in the agent exactly as before, with the previews where the screenshots were. It frees roughly nine gigabytes of the twenty-two on this machine. It is permanent, and the confirmation says so in one sentence: the full-size originals cannot be brought back. The first conversation we ran it on was the 14.84 GB one from the last post. It became **907 MB**. 15,354 screenshots turned into previews; the agent's own reader returned the same 68 turns and 3,895 items afterwards, and the text was byte-for-byte what it had been. A batch of 275 conversations — three gigabytes of files — takes about twenty seconds. Next to it sits **Delete**, for the conversations you are done with: the whole thing leaves the agent, through the agent's own delete path, and all of its space comes back. The two buttons are explained side by side in the product, from the user's side — *still want to look back at it?* versus *done with it?* — because the census taught us that the difference between them is most of what a storage tool has to say. We retired the in-place de-duplication button. It was reversible, it was clever, and on the whole store it was worth 2.73 GB of archived space while the honest verb was worth 9.7. ### The other agents The same census, run over the other tools on the machine: - **Claude Code** keeps its sessions as plain files under its projects folder: 610 sessions, 1.75 GB, of which **526 MB (30%)** is embedded images — 175 MB repeated inside a session, 66 MB across sessions. The same shape at a smaller scale; the same verb would apply. - **Cursor** stores chat images as ordinary files next to its workspace data — 284 of them, 56 MB — and its 2.6 GB state database is text. There is nothing for this verb to do there. - **Claude Desktop** keeps conversations on the server. Its 12.6 GB of local data is 10.9 GB of virtual-machine bundles for its computer-use feature and a gigabyte of session records with no images at all. A different problem, and a different post. ### What we actually learned A sample told us agents store a lot of duplicate pictures. The census told us *where* — in the conversations people are still using, not the ones they have abandoned — and *how much each remedy is worth*, before we built any of them. That reordered the roadmap: the obvious lever turned out to be the smallest, the obvious axis pointed the wrong way, and the honest verb — keep the words, shrink the pictures, say it is permanent — was worth three times the clever one. It also told us that a conversation is not a file. It can be a window into another file, and a cleaner that does not know that will break things it never touched. Mint does not know these things because it is smarter than the folder listing. It knows them because it read everything, fingerprinted everything, and asked the agent afterwards whether it could still read what was left. --- *Every number here is a byte-level census of one developer Mac's agent storage, taken in September 2026 with Mint's own read-only analysis, entirely on device. The companion piece on the mechanism is [Your Coding Agent Is Eating Your Disk](/build-journey/agents-are-not-a-black-box).*

How this was measured