JoyAI Unload

What it's for

JoyAI Video Edit runs inside a persistent worker in a WSL2 distro, and that worker does not politely disappear when your queue finishes. It stays loaded, holding roughly 62 GiB of Windows commit charge at load and up to ~27.9 GB of a 32 GB card while it works. JoyAI Unload is the off switch.

Reach for it when you're done with a JoyAI session and want the machine back - before launching something VRAM-hungry, before leaving the box running overnight, or when a second ComfyUI complains the runtime is in use (though that fix has to happen in the other process; a node can only unload its own process's worker).

Why it looks like an output node

The node has no required inputs, accepts an optional runtime, and has a trigger socket that swallows literally anything. The trigger isn't data, it's ordering - its tooltip says so: "any output, only to order this node after it". ComfyUI executes a graph by walking backwards from output nodes, so a node with no consumer would otherwise never run.

The source confirms the rest: is_output_node=True, not_idempotent=True, and fingerprint_inputs returns math.nan. That's the standard always-rerun idiom - NaN never equals NaN, so the engine can never decide the node is unchanged and skip it. Every queue run fires the unload, which is exactly what you want from a cleanup node and would be terrible for a sampler.

So: wire Video Edit's report (or its images) into trigger and Unload runs after the edit. Leave it dangling and it still runs, just with no ordering guarantee.

Inputs and outputs

runtime (optional, type JOYAI_RUNTIME) is worth connecting if the graph has one, since it keeps the wiring legible and guarantees the loader has already been evaluated. It genuinely is optional - hit queue with the sockets empty and the node just stops whatever worker the manager is holding, answering {"unloaded": false, "reason": "no worker running"} when there's nothing to stop.

trigger (optional, *) is the ordering wire described above.

status is a single STRING output: JSON with whether it unloaded, the worker id, the final state, the worker's stop report, and commit_gib_before / commit_gib_after / commit_limit_gib snapshots of Windows commit charge. That last part is genuinely useful - it's the fastest way to see what the model was actually costing you. The same text also lands in the node's UI and in /history, so a Preview Any is optional.

Don't expect the memory back instantly

This is what makes people think the node is broken. When the worker stops, the WSL2 VM keeps 25–30 GiB committed for a while before it lets go - typically 30–80 seconds in the tested setup. Queue another JoyAI run right after an Unload and the Runtime node sits on "Waiting for WSL memory release" until the commit charge is back; starting a load on residual memory is never attempted, by design.

So the honest flow is: Unload, watch commit drop partway, let the VM catch up. Or skip the node entirely if you're coming back in ten minutes - idle_unload_minutes on the Runtime node (default 30, 0 disables it) does the same job on a timer.

Installing

It ships in the same pack as the other two JoyAI nodes, so there's nothing separate:

cd ComfyUI/custom_nodes
git clone https://github.com/hiroki-abe-58/ComfyUI-JoyAI-Video-Edit

Restart ComfyUI, or install "ComfyUI-JoyAI-Video-Edit" through ComfyUI Manager. No Python dependencies, no downloads - but the node is useless without the WSL2 runtime and the ~50 GB of weights that the pack documents in docs/SETUP.md, because there has to be a worker before there's anything to unload.

Troubleshooting

no worker running is the most common output and it isn't an error - you queued twice, or idle unload already fired.

If memory is still ~25 GiB committed a minute later, that's the WSL2 VM holding its own allocation. Wait, and read the loader's status string rather than Task Manager, which makes commit charge easy to misread.

You usually don't need this node for a clean shutdown: the pack registers an exit handler, so Ctrl+C closes the worker, and if ComfyUI crashes the worker dies with it (Windows Job Object plus stdin EOF). Unload is for the middle of a session - a pipeline switch, a VRAM-hungry detour, an idle timer you don't trust.

And it is not a general "free my VRAM" node. It stops the JoyAI worker and nothing else; your loaded checkpoints don't move.