Force Cleanup After Prompt

You know the feeling: you're ten images into a batch, or you've swapped from SDXL to Flux and back a few times, and suddenly the next run crawls - or outright dies with an OOM. Restarting ComfyUI fixes it, but that nukes your queue. Force Cleanup After Prompt is a single node from the ComfyUI-Force-Cleanup pack that tells ComfyUI to run its native memory cleanup the moment the current generation finishes. No wires, no API, no third-party dependencies - you just drop it into a workflow and queue.

Why empty_cache() alone rarely works

The honest version of the problem: torch.cuda.empty_cache() only hands back the blocks the PyTorch allocator already knows are orphaned. It can't touch memory that still has a reference - and ComfyUI holds plenty: loaded models in its model list, the previous run's node outputs in the execution cache, plus whatever third-party nodes keep around. That's exactly why a bare empty_cache() call often shows you nothing move on the VRAM meter. The pack's README is upfront about it, and the fix isn't to clean harder - it's to clean later, after the whole prompt finishes and references drop.

How it works

The node is an output node with no outputs. It just needs to exist in your workflow (or be connected to nothing at all). When it runs, it sets a flag on ComfyUI's prompt queue - free_memory for the full level, unload_models for the lighter one - and ComfyUI's own worker performs the cleanup after execution completes. Under the hood, that's unload_all_models() → executor.reset() → gc.collect() → soft_empty_cache(). Nothing is yanked mid-run, and nothing internal is poked; it uses ComfyUI's public queue behavior, which is why the author can ship it with zero dependencies and why it survives ComfyUI updates.

There's one subtle trick worth knowing: the node returns float("nan") from its IS_CHANGED method so ComfyUI's execution cache never "remembers" it and skips it on the next queue. That's the standard always-rerun idiom - if the node didn't do this, ComfyUI would be smart enough to skip it, and you'd never get your cleanup.

The one input that matters

Everything hangs on a single enum, cleanup_level, with two choices:

• full: models + execution cache + allocator (default) - unloads models, clears the execution cache, runs Python GC, and releases the PyTorch allocator cache on CUDA, XPU, and MPS. Frees the most memory, but the next run has to reload models and recompute everything, so it costs you time on the very next generation.
• models: unload models + allocator - unloads models and empties the allocator but keeps ComfyUI's reusable execution cache. Next run is snappier; the main-memory drop just isn't as dramatic.

The author recommends starting with full. If you're only chasing VRAM (not system RAM) and don't want to eat the reload cost every time, the models level is a reasonable everyday setting. The node has no outputs - its only "result" is a message in the UI log telling you what got scheduled.

Installing it

Two real options, both fast:

• ComfyUI Manager: search "ComfyUI Force Cleanup" and hit Install.
• Manual: cd ComfyUI/custom_nodes && git clone https://github.com/3289004205/ComfyUI-Force-Cleanup, then fully restart ComfyUI.

That's it. No pip install, no model downloads, no heavy dependency tree - the whole pack is one small file. Find it in the node menu under utils/memory as "Force Cleanup After Prompt".

Gotchas and when to suspect something else

First, expectations: Windows Task Manager's GPU number rarely drops to zero while the process lives - it includes driver context, shared GPU memory, and a CUDA context that only dies with the process. Judge success by comparing a settled before/after value, not by hunting for zero.

If memory is still high after cleanup, the node probably isn't the problem. Update ComfyUI and all custom nodes, then disable custom_nodes one at a time to find the extension holding global model or tensor references. Still stuck? Try launching with --lowvram (or --novram on tiny cards, at a real speed cost). If what's ballooning is system RAM rather than VRAM, look at huge image/video nodes, preview frames, big batch sizes, and third-party caches. And one honest limit the README states plainly: only closing ComfyUI releases the CUDA context completely - no plugin can safely zero a running process. This node just gets you back to baseline between runs, which is usually all you needed.