Somebody posted this morning that they had just deleted 3.2 TB of models collected over four years. They ran out of space on their ComfyUI drive, thought about moving it all to a spare hard disk for about five seconds, and then deleted ninety percent of it instead.

We read that with some sympathy, because the same problem took our own publishing offline three days earlier and we did not spot it until it had already broken something else.

What it looked like on our side

Our automated pipeline publishes a video every morning without anyone watching. Three mornings ago it stopped, and the error said the YouTube credential file contained no valid JSON.

That is a login problem, so we started looking at logins. It was not a login problem. The credential file was zero bytes because a scheduled token refresh had opened it for writing at half past five in the morning and then been unable to write anything, because the disk was full. One thousand and seven gigabytes, of which nine hundred and fifty seven were used.

The failure surfaced two hops from its cause. Nothing said “disk”. It said the login was corrupt, and a reasonable person spends an hour on the wrong problem.

The folder we did not know we had

When we actually looked, the largest single consumer was not models. It was a cache: 591.5 GB across 795 directories, holding derived per shot preparation data for every episode we have ever made. Every one of those directories was created legitimately, by a tool doing exactly its job, and none of them were ever cleaned up because nothing was ever told to clean them up.

Our ComfyUI models folder is a further 719 GB on the Windows side. That one we at least knew about.

We are down to 426 GB used now with 531 free, and the cache is 65 GB. Nothing was lost that mattered. But the honest summary is that we were running a studio on a full disk without knowing it, and the first symptom was an unrelated system failing to log in.

Why this keeps happening to people

Everybody plans VRAM. It is the number in every guide, it decides which models you can run at all, and it is the first thing anyone asks about. We are as guilty as anyone here, because our own calculator leads with VRAM and treats storage as a footnote.

Storage is different in three ways that make it easy to miss. It fills gradually rather than failing at a threshold, so there is no moment where you notice. Much of what fills it is derived rather than downloaded, so it does not feel like something you chose to keep. And when it finally runs out, the thing that breaks is usually not the thing that filled it.

Today’s poster had 3.2 TB of models. We had 591 GB of a cache we had never opened. Neither of those is unusual once you have been doing this for a while.

What we would actually suggest

Check it now rather than later. On Linux or WSL, df -h / takes a second, and du -sh * inside a directory will tell you which child is eating everything. The equivalent on Windows is whatever disk usage tool you already have. The point is to look before something else breaks.

Know the difference between what you downloaded and what your tools generated. A checkpoint you can download again is not the same as a render you cannot reproduce, and the two often sit in adjacent folders. We have a standing rule that we never delete generated outputs, which is why our cleanup went after caches and not results.

Add a free space check to anything that runs unattended. We are adding one to our morning pipeline, because a job that publishes without supervision should refuse to start rather than fail halfway and leave a zero byte file behind.

And if you are the person who just deleted 3.2 TB, that is a defensible choice. Most of those models are still downloadable, most of them you were never going to load again, and the newer ones are genuinely better than what they replaced. The ones worth keeping are the ones that are gone from the internet, or the ones you trained yourself.

A daily note from our news radar. The week gets the full treatment in the DIY AI Brief every Monday.