LeapTalk Worker (status / unload)

The node for one specific problem

If you read "persistent worker" and thought that's the good part, this is the node that pays for it. LeapTalk Runtime with backend = persistent keeps the model loaded between queue jobs so you skip about 20 s of imports and weight loading per run - but a loaded worker keeps roughly 4 GiB of GPU memory and 8.4–8.8 GiB of Windows commit charge while it sits there doing nothing. If you want to render video with something else, or you're on a card where that's the difference between working and not, you need a way to look at it and a way to kill it.

That's LeapTalk Worker, and nothing else. Two actions, one output.

status vs unload

status reports the worker without starting one and without extending its idle timer. That second half is the important half: checking on the worker doesn't reset the clock, so you can't accidentally keep it alive by poking it. If nothing is loaded you get a report saying so and no process is spawned.

unload stops the worker and frees its GPU and system memory. It waits for a running job rather than cutting one off - if a job is in flight you get unload: busy with a note to run it again afterwards or cancel the job in ComfyUI. Nothing is ever silently killed mid-generation by this node.

The output, status, is a JSON string; a one-line summary also lands in the node's text panel. What's in it: the worker's worker_instance_id, its state, the decoder it loaded, how many jobs_done it has served, idle time remaining before it unloads itself, plus a host memory snapshot and a short history of worker events. That history is worth a look when a job quietly got slow - it records why a worker was started or replaced.

Practical habit: when a job suddenly takes 40 s again, run status. It tells you whether the worker is gone (startup is being paid again) or still there.

The optional after input

There's one optional input, after, a string that takes a linked input rather than a typed value - you connect the report output from LeapTalk Generate into it. Its purpose is ordering: it makes this node run after that job. Without it, unload queued in the same run has no reason to wait for the generation, and you'd be asking to free memory that's about to be used. If you're building the "generate, then free everything" workflow the pack ships as leaptalk_worker_unload.json, that's the wire that makes it correct.

When the worker goes away on its own

You don't strictly need this node; the worker also dies from natural causes, and knowing them saves confusion:

• Idle timeout - worker_idle_seconds (default 120 s) counted from the end of the last job.
• ComfyUI exiting - the worker goes with it.
• Any job error - a failed job ends the worker and the next job starts and loads a fresh one. Expect that next job to be slow; it's normal.
• Identity change - different decoder, different runtime settings, or edited runtime files, and the worker is replaced rather than reused, with the reason recorded in the history.
• Memory pressure - the memory guard stops an idle worker when the system commit charge stays at or above its stop threshold.

Also worth knowing: one-shot jobs and a loaded worker don't coexist. Asking for a one-shot job unloads the idle worker first, so only one LeapTalk model is on the GPU at a time.

Installing

The node comes with the pack; there's nothing extra for it.

cd ComfyUI/custom_nodes
git clone https://github.com/hiroki-abe-58/ComfyUI-LeapTalk

It only does anything if a persistent worker exists, which means the whole runtime setup - separate venv, pinned LeapTalk checkout, pinned weights, ComfyUI/user/leaptalk.runtimes.json, restart - and backend = persistent set on LeapTalk Runtime (or backend: "persistent" as the runtime's configured default). Set that up with LeapTalk Doctor before you trust a green light here.

Gotchas

• unload: busy - a job is running. It waits; it doesn't interrupt. Run it again, or cancel the job in ComfyUI and re-queue the node.
• status: no worker loaded - either you're on one-shot, or the worker idled out, or a previous job failed and took it with it.
• You unloaded and the next job took ages - that's the deal you signed. Persistent is a fast loop, one-shot is a clean slate.
• Multiple ComfyUI processes can't share one worker. Not in this release, and neither is multi-GPU or a WSL2 runtime.
• This node is not a model unloader for anything else. It knows about the LeapTalk worker and nothing about the rest of your ComfyUI models.