Memory Cleanup

Queue a dozen jobs in ComfyUI and VRAM has a way of creeping upward - one run's cached activations lingering into the next until suddenly the fifth job OOMs on a model that ran fine at the start. Memory Cleanup is a small utility node that asks ComfyUI to release its execution cache (and optionally unload models) after the current task finishes. It's the "flush between jobs" button, automated.

Let's be honest about what it is and isn't. It will not save you from an OOM that happens mid-sampler - nothing at the graph level can do that once the model is loaded and mid-run. What it reliably does is clean house between executions so memory doesn't accumulate across a long queue. That's a real, common failure mode, and it's worth a node.

How it works

The node runs at the end of the workflow (it's an output node, so ComfyUI guarantees ordering). On execution it does three things:

1. Calls gc.collect() to sweep Python garbage.
2. Calls ComfyUI's model_management.soft_empty_cache() to release cached PyTorch memory back to the driver.
3. Sets flags on the prompt queue: free_memory (release execution cache), and - if you enable unload_model - unload_models, which actually unloads loaded models from VRAM.

The inputs are almost trivial:

• unload_model - default false. On, it unloads models after the task (bigger VRAM savings, but the next run has to reload them, so single-run time goes up).
• anything - a wildcard passthrough. The trick: chain a wire from an earlier heavy node into this port so execution order forces the cleanup to run after that node.

Output is output - just the passthrough value, useful for keeping the graph wired.

Install

Part of ComfyUI-1hewNodes:

cd ComfyUI/custom_nodes
git clone https://github.com/1hew/ComfyUI-1hewNodes

Restart ComfyUI. No models, no downloads.

Where it fits

The pattern that actually works: stick it at the end of the workflow, connect anything from your sampler output, leave unload_model off for day-to-day queueing, and turn it on when you're about to switch to a different model family (SDXL → Flux, say) so the old weights don't sit around. Between-run cleanup is the intended use; end-of-session cleanup is the bonus.

Common issues

• "It didn't fix my OOM" - if the OOM is inside a single run (too big a batch, too many LoRAs), no cleanup node helps. This only addresses cross-run accumulation.
• Next run is suddenly slower - you have unload_model on. That's the tradeoff working as designed; flip it off if reload cost bothers you.
• It's not a RAM solver - soft_empty_cache targets GPU cache; system RAM pressure needs a different approach (and honestly, a bigger machine).

My take: it's the rare "memory" node that's honest about its scope. It doesn't promise miracles, it just sweeps between runs - and for long queue sessions, that's exactly what you need.