- The problem. One Codex folder was 22 GB. Seven of every ten bytes were screenshots, most of them the same picture saved again and again.
- What we found. 92% of the repeats were in this week’s conversations. Clearing old chats got back 151 MB; 5.7 GB stayed.
- What we built. Mint’s Optimize removes the repeats Codex won’t read again, and Undo puts them back. Or take the pictures out for good and keep every word.
Data and method
Last month we opened one developer's agent storage and sampled the fifty largest conversation files. 77% of the bytes were images, and 39% of those were copies. But a sample only gives you a rough idea of what's in there.
So this time we read all of it: every conversation file in one Codex store, 1,231 files, 22.83 GB. We fingerprinted every embedded image, compared each fingerprint inside its own conversation and against all the others, and dated each conversation by when it was last used. That full census changed what we ended up shipping.
We measured on one developer’s Mac on September 2 and 3, 2026, with a byte-level pass over every rollout file in the Codex store (1,231 files, 22.83 GB, about ninety seconds), not from Mint’s own summaries. We hashed every embedded image with SHA-256, compared it inside its conversation and against every other one, and dated each conversation by its last use. Codex’s own reader (the app-server’s thread/read) told us whether a rewritten conversation still opens; that’s also how we found the broken forks. The Claude Code, Cursor and Claude Desktop figures come from the same kind of pass over their own directories. The scan hooks behind these numbers ship in Mint and only read.
Finding 1: seven bytes in ten are pictures
Images are 16.18 GB of the 22.83. Text (prompts, tool output, the agent's reasoning) is 6.65 GB. Nothing else is big enough to name: audio rounds to zero, there's no video, and there are no build products, only build logs inside tool output.
The split inside the images is where it gets interesting. Only 3.81 GB are pictures the store holds once. 5.71 GB repeat a screenshot that already appears earlier in the same conversation, which is the compaction mechanism from the last post re-embedding what it just summarised. Another 6.66 GB repeat a screenshot from a different conversation: the same terminal or the same page under test, pasted into another thread days later.
Out of every ten bytes of "conversation history" on this machine, seven are pixels, and fewer than two are pixels that don't exist anywhere else.
Text has the same problem on a smaller scale. 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 is saved both as the output and as an aggregated copy, each capped at a megabyte. One long build log can end up stored four times. We measured this and leave it alone. It's part of the agent's own reader contract, and we don't think a cleaner should rewrite data another program relies on.
Finding 2: the duplicates are recent
The obvious way to pick what to clean is age. Show the user a slider ("untouched for 7 days, 14, 30") and let them clear what they don't use anymore. Every storage tool has that slider, Mint included.
Then we sorted the in-conversation duplicates by the age of the conversation they live in.
92% of them sit in conversations used within the last six days. The largest single file on the machine (1.76 GB, 3.9 days old) held 1.57 GB of repeated screenshots by itself. Conversations older than a month held 0.02 GB combined.
This holds beyond one Mac, because duplication comes from long, recent sessions with a lot of screenshots. Compaction only runs when a conversation gets long enough to need it, and it re-embeds images from that same session. Old conversations were short, mostly text, or both. A cleanup that starts from "what haven't you touched in a week" misses almost everything worth reclaiming. Drag the slider to seven days, press the button, get 151 MB back, and the tool has told you there was nothing to clean, while 5.7 GB sat at the other end of the slider.
Finding 3: what each cleanup would free
Once every byte has a fingerprint and an age, you can work out what each cleanup strategy would free before running any of them. For this store:
Deleting conversations untouched for five days would free 16.02 GB. It's the only strategy that touches text, and the only one that throws away things you might want back: the reasoning, the diffs, the record of why a decision was made.
In-conversation de-duplication, the first thing we shipped, frees 5.71 GB across the whole store, and only 2.73 GB of that 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 the agent knows nothing about, plus an undo path that only works as long as that store survives. We measured it and didn't build it.
Taking every picture out and keeping the text frees up to about 10.3 GB from the archived conversations alone. The 49,597 screenshots in those files add up to 10.31 GB, and each one leaves a placeholder of about 240 bytes in its place. Shrinking them to small previews instead, which is what we shipped first, would have kept roughly 0.6 GB of pictures and freed about 9.7 GB.
That ordering surprised us. The clever strategy came out smallest, and the plain one, taking the pictures out, came second only to deleting everything.
Finding 4: a conversation can depend on another one's bytes
The census turned up one more thing, because it read the file headers as well as the payloads.
Agents let you fork a conversation, so you can branch off from turn 30 and continue somewhere else. The fork doesn't copy the first thirty turns. It records something like "my history is the first 117,348,378 bytes of that other conversation": a byte offset into a file it doesn't own.
Shrink the base in any way that moves a byte (de-duplicating it, taking its pictures out) and the offset points past the end of the file. The agent then refuses to open the fork, with the error cutoff byte offset is past the source rollout.
On this machine, 22 of the 1,231 conversations are forks, and 16 of them were fine. Three had been broken by our own earlier de-duplication, which shortened two base conversations without knowing other conversations depended on them. Another three had been broken by the agent itself, which had shortened its own bases.
We restored the two bases byte-for-byte, which only worked because the first version was reversible, and the forks opened again. The tool now refuses to change any conversation that another one is based on, and it checks that before reading a single payload.
This goes beyond agents. A file can look self-contained and still have something else depending on it, and the cheapest safety check is to ask the program that owns the format whether it can still read what you wrote. While building this, we checked our rewrites that way with the agent's own reader. In the app, Mint only rewrites lines that are complete records, and if a rewritten line doesn't hold the same number of media items as before, it leaves the whole file alone.
What we shipped
We started from what the user wants. Nobody keeps an agent conversation for its screenshots. Those are the agent looking at a terminal, a failing test or a page it was fixing; they're part of the process. The work itself ends up in the repository, the pull request and the deploy. When people go back to a conversation, they're looking for the text: what was tried, what was decided, and why.
Remove media takes the pictures out and leaves the text. It's a separate action from today's Optimize, which keeps the pictures Codex reads when you continue a supported conversation and can be undone as long as the originals and history it needs are still there. The numbers that follow are for Remove media, not Optimize. Every screenshot, and any other media, becomes a tiny placeholder, and the text isn't touched. The conversation opens in the agent the same as before, with a placeholder where each picture was. On this machine the archived conversations alone give back roughly 10 GB of the 22. It works on active conversations too, as long as no program has the file open. It's permanent, and Mint says so before it runs: the text stays, and the pictures don't come back.
We didn't ship that first. When this post went up on September 3, each screenshot became a small preview, 256 pixels on its longest side. We first ran that on the 14.84 GB conversation from the last post, and it came out at 907 MB, with 15,354 screenshots turned into previews. Afterwards the agent's own reader returned the same 68 turns and 3,895 items, and the text was byte-for-byte unchanged. A batch of 275 conversations (3 GB of files) took about twenty seconds.
Update, September 23, 2026. Mint no longer makes previews. A 256 pixel preview of a screenshot is too small to read, and keeping it cost about 6% of the space (0.6 of the 10.31 GB). A picture you care about is worth keeping as it was, and one you don't can go completely, so a preview served neither case. Now a picture is either left alone or taken out.
Next to Remove media is Delete permanently, for conversations you're done with. The whole conversation goes through the agent's own delete path, and all of its space comes back. After the census, we think the choice between these two, keeping the words or letting the whole conversation go, is most of what a storage tool has to explain.
De-duplication didn't go away, but it got much narrower. Optimize now replaces a repeated screenshot only where the agent won't read it again: inside an older summary that a later summary replaced, and only when an intact copy of the same picture sits further down the file. When you continue the conversation the agent sees the same pictures, and Undo puts every replaced copy back. Optimize also stores PNG screenshots as lossless WebP, with the same pixels. It frees less than taking the pictures out, and it can be undone.
Beyond Codex: the other agents
We ran the same census over the other tools on the machine.
- Claude Code keeps its sessions as plain files under its projects folder: 610 sessions, 1.75 GB, and 526 MB (30%) of that is embedded images (175 MB repeated inside a session, 66 MB across sessions). It's the same pattern at a smaller scale, and Mint takes the pictures out of Claude Code sessions the same way, keeping the text.
- 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. So there's no conversation file to rewrite there. Mint lists those images as ordinary files instead.
- 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. That's a different problem for a different post.
Scope of this analysis
- Built around an AI-heavy workflow. We measured a Mac where coding agents run every day, the setup this research is for. A Mac used mostly for design, video or school holds different files in different proportions, and the numbers move with it.
- Conservative by design. A picture counts as a repeat only when its bytes match exactly, so the repeat figures are a floor. Near-duplicates would only add to them.
- A snapshot of September 2026. Codex can change how it stores conversations from one version to the next. Mint doesn't rely on these numbers: it reads the files on your own Mac as they are today.
- Next. We're running the same census on other workflows. If your Mac looks different, send us a note, and it may shape the next one.
Conclusion
The sample told us agents store a lot of duplicate pictures. The census told us where they are (mostly in conversations people are still using) and how much each fix would free, before we built any of them, and that changed our roadmap. The obvious fix was the smallest, and sorting by age pointed the wrong way. Taking the pictures out, keeping the text and saying plainly that it's permanent freed nearly four times as much as de-duplicating the archived conversations.
It also showed that a conversation file can depend on bytes in another file. A cleaner that doesn't check for that can break conversations it never touched.
A folder listing shows none of this. Mint found it by reading every file, fingerprinting every image, and then asking the agent 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.
Find the right next step for your tool
If your large folder belongs to Codex, the Codex storage guide explains how Optimize differs from removing media for good. A large claudevm.bundle is a different case: the Claude Desktop guide covers local tasks, cloud sessions and what to keep. Start with the AI-tool storage overview if you don't know yet which tool owns the data.