Ryan Galloway

AI coding agents are usually discussed as compute workloads: tokens, context windows, model latency, tool calls, CPU, GPU.

But increasingly, they are also filesystem workloads.

That sounds obvious until an agent quietly writes tens or hundreds of gigabytes of local state.

A recent Codex user reported that ~/.codex/sessions had grown past 100 GB in less than a week on a new laptop, along with roughly 5 TB of reported writes. Their local analysis found that much of the space was not unique conversation state at all. It was repeated screenshots, inherited parent history, and compacted checkpoints serialized again and again.

That is not an isolated shape of failure. An open Codex issue describes a long-running session with about 100 subagent spawns producing roughly 30 GB of rollout data in a day, measured at about 97% duplicated bytes. Another image-heavy multi-agent report documents repeated inherited image context, large rollout files, heavy swap growth, and substantial network traffic.

The bug itself can be fixed. The broader pattern is more interesting.

The agent is no longer ephemeral

The simple mental model for an AI coding tool is:

prompt -> model -> tool calls -> code

That is not really what modern agent runtimes do.

They persist:

Once agents fork into subagents, the storage model matters even more.

Suppose a parent session grows over time and each child receives a serialized copy of the parent’s current history. If each successive child inherits a larger history than the previous one, total stored history is no longer proportional to the useful work performed. It starts looking like:

H1 + H2 + H3 + ... + Hn

If H itself grows roughly with n, storage growth approaches quadratic behavior.

Add inline images, repeated checkpoints, and append-only logs, and a perfectly normal agent workflow can become a surprisingly aggressive storage generator.

“How big is this directory?” is not enough

Traditional disk-usage tools are useful when the question is:

What is using my disk?

Agent workloads introduce harder questions:

Why did it grow?

When did it start growing?

How much of the data is actually unique?

Which process or workflow produced it?

Are these files independent, or repeated copies of the same content?

What can be safely removed?

A directory being 100 GB is one fact.

A directory growing from 2 GB to 100 GB in four days, with 96 GB of repeated content generated by one family of agent sessions, is a much more useful fact.

That distinction is why I think filesystem monitoring is going to become part of agent observability.

Content identity matters

Filesystem accounting normally treats two 500 MB files as 1 GB of data.

Operationally, that is correct: they occupy space.

But if the files contain identical bytes, there is another important number:

logical size:       1.0 GB
unique content:     0.5 GB
duplicate content:  0.5 GB

For workloads that repeatedly serialize history or embed the same binary data, the difference can become enormous.

This is where hashing and content identity stop being niche deduplication tricks and start becoming observability primitives.

A useful storage system should be able to tell you both:

Those are different questions.

Compression is helpful, but references are better

Highly repetitive JSONL usually compresses extremely well. The Codex issue above reports 10–20x compression on the affected rollout data.

Compression is a good mitigation, but it does not fix the underlying data model.

If 40 child sessions all need the same 100 MB of parent state, storing that state once and referencing it is fundamentally different from writing 4 GB and compressing it later.

The same applies to screenshots and generated images.

A content-addressed blob store is an obvious pattern:

sha256(content) -> blob

Session records can then reference the blob rather than embedding another copy.

That buys more than disk savings. It also gives the runtime a stable identity for content, which makes retention, provenance, caching, and garbage collection much easier.

Agent storage needs retention policy

Databases have vacuuming.

Log systems have rotation.

Object stores have lifecycle policies.

Build systems have cache eviction.

Agent runtimes will need the same maturity.

At minimum, I would expect serious agent infrastructure to eventually support:

The key word there is safe.

“Delete duplicate files” is easy to say and dangerous to automate. The useful system should understand enough context to explain why something is considered redundant and what references still depend on it.

This is changing how I think about SnapFS

I’ve been building SnapFS around persistent filesystem intelligence: indexing files, tracking change over time, and understanding where storage is going.

I originally thought about deduplication mostly as a storage-analysis feature.

I’m increasingly convinced it should be a first-class part of the model.

The interesting problem is not merely:

Find duplicate files.

It is:

Show me where duplicate content is accumulating, when it appeared, what produced it, which copy is canonical, and what I could reclaim without breaking anything.

Agent workloads make that problem unusually visible because they can generate large amounts of machine-produced state very quickly.

A useful filesystem intelligence layer should be able to notice that a directory suddenly gained 80 GB overnight and then tell you that only 3 GB of it represents new content.

That is a very different kind of alert from “disk is 90% full.”

Storage is part of the agent runtime now

AI agents are becoming long-running, stateful systems.

They fork.

They retry.

They checkpoint.

They consume and generate media.

They preserve history.

They operate continuously.

Once that happens, storage behavior is no longer an implementation detail.

It is part of the runtime architecture.

We already monitor agents for token usage, latency, failures, and cost. I think we will increasingly monitor them for filesystem growth, write amplification, duplication, retention, and provenance too.

The agent may be writing code.

But it is also writing a lot of files.