JLC Stage Boundary VRAM Cleanup

First, the honest framing, because the author says it in every doc this node has: it's experimental. JLC Stage Boundary VRAM Cleanup is a latent passthrough that triggers a cleanup pass at a deliberate point in your graph - the moment when stage one is done with its heavy models and stage two is about to load different ones. It is not a magic "make the OOM go away" button, and it is not a guaranteed VRAM reset. Think of it as a politely worded request to ComfyUI's model manager, made at exactly the right time.

When you'd reach for it

Multi-stage Flux workflows are the designed case. Stage one loads a big base model, an inpaint model, or a JLC ControlNet stack and produces a latent. Then stage two wants to run a different model family - maybe a partial denoise pass - and your VRAM is still holding stage one's residency. ComfyUI normally manages model swapping itself, but when the boundary is explicit and you know nothing upstream is needed anymore, you can ask it to unload before the next stage. That's this node.

Notably, the pack's README is blunt that forcing ComfyUI with --lowvram wrecked their Flux + multi-ControlNet benchmarks (unload/reload thrash, massive slowdowns). This node is the designed alternative for that scenario: keep normal VRAM behavior, and clean up at the boundary you actually control.

How it works

It receives a latent, does its cleanup side effects, and passes the same latent back out. It forces execution every time it's on an active path - cleanup is a side effect, so it shouldn't be skipped just because the latent is cached.

What it can clean, in roughly increasing aggression:

• unload_connected_model (default on) - tries to unload the optional model input and its clones/additional models via ComfyUI's model management.
• evict_jlc_controlnet_cache - drops JLC-managed ControlNet resident cache entries.
• unload_all_comfy_models and evict_all_jlc_model_cache - the hammers: unload everything ComfyUI or the JLC cache is holding.
• clear_cuda_allocator (default on) - gc.collect, a soft cache empty, and a defensive CUDA allocator pass.

Supporting toggles: safe_cleanup, all_devices (unload across devices when ComfyUI supports it), and verbose (prints what it did and how long it took - useful while designing).

Inputs and outputs, briefly

latent is the trigger and passthrough. The optional model input is what unload_connected_model targets. The one output is latent, unchanged. The doc's own guidance: start narrow - unload_connected_model plus clear_cuda_allocator - and only add the broad options when the narrow ones aren't enough.

Where people get burned

Three ways, all documented. Broad cleanup options make later nodes reload models, which can slow the run - you're trading peak VRAM for wall time. Placement matters: if the graph still needs those models downstream, you'll cause reload churn or weird behavior, so only put the node where upstream objects are truly finished. And ComfyUI remains the authority over its own model lifecycle - if ComfyUI's internals change, this node's behavior changes with them. That experimental label is doing real work.

If you genuinely need a hard, guaranteed memory reset, the pack's own docs say it plainly: restart ComfyUI. This node is a best-effort helper, not a reset.

Install

It ships in jlc-comfyui-nodes (Damkohler), on the ComfyUI Registry and in ComfyUI Manager:

# ComfyUI Manager:  Install Custom Nodes → search "JLC ComfyUI Nodes"
# or manually:
cd ComfyUI/custom_nodes
git clone https://github.com/Damkohler/jlc-comfyui-nodes.git

Restart after installing. No extra Python packages, no model downloads. And yes, the pack's own docs pair it with the JLC Seed Generator in the canonical multi-stage flow - same seed feeding stage one and stage two's partial denoise, with this cleanup node sitting on the boundary between them.