MonarchRT Worker (status / unload)

ComfyUI's usual contract is that your VRAM is yours between runs - unload the model, do something else. The MonarchRT pack can break that contract on purpose. In persistent mode a separate warm process keeps the model and the tuned Monarch kernels loaded on the GPU between queue jobs, and it will happily sit there after your video is saved. That's the point: warm jobs run in about 10-12 s instead of ~195 s. It's also how you end up with a card that looks "full" while ComfyUI's own model manager swears nothing is loaded.

This node is the light switch.

What it is

MonarchRT Worker takes one input, action, with two values:

status - report on the persistent worker. If none is running you get "worker": null; if one is alive you get its worker_id, runtime_id, alive, how many jobs it has served, how long ago it started, and its startup info (pid, process group, startup seconds, model load seconds), plus a tail of manager events.
unload - stop the worker now and free its GPU and RAM. The tooltip says exactly that, and it's the honest description.

Output is a single report STRING of JSON, and the node is an output node, so queueing it just runs it. The short version is also shown in the node's UI text area: either no worker, or the worker id with alive=true/false and its job count. A ready-made workflow, workflows/monarchrt_worker_status.json, wires this plus Preview Any.

Why it exists at all

The worker's lifetime is otherwise controlled by things that aren't in front of you: the runtime's worker_idle_seconds (default 300, i.e. five idle minutes), a change to the runtime or to the pack's code, or ComfyUI exiting or crashing. That's a lot of implicit state. On the reference machine an idle worker holds roughly 18 GB of GPU memory and 14-16 GiB of RAM - mostly memory-mapped model files - which is very noticeable if you want to go back to image generation, or run a game, or experiment with a 14B video model.

Note the identity detail, because it explains surprises: a worker is keyed to the runtime plus the pack's code digest, not to the attention profile. Switch a warm worker from monarch_h2 to monarch_h1 and you don't get a new worker - you get a pause while Triton autotunes the new kernel shapes (~150 s on the 5090), then warm speed again. Switch it to dense and you're running flash-attn in the same process. Outputs stay byte-identical across all of it, including after an unload or a crash.

How to use it in practice

Queue status when you want to know whether the last generation actually cost you what you think it did, and queue unload when you're done iterating.

There's a plumbing trick worth knowing here - the same one that applies to any state-carrying utility node in ComfyUI. Because the report is a STRING output, you can wire it into a Preview Any (or a text display node) and glance at it after every run instead of queueing a separate diagnostic. The node re-evaluates each time it's queued rather than being cached, so the report you see is current rather than a stale cached value.

Install

Nothing separate from the rest of the pack:

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

or search MonarchRT in ComfyUI Manager. No Python dependencies are added to ComfyUI - the worker process lives in the separate WSL2/Linux runtime you set up per docs/SETUP.md, and this node just talks to the manager that owns it. You'll want a runtime registered in ComfyUI/user/monarchrt.runtimes.json regardless, since the pack's nodes read runtimes from there and never from the workflow.

Where people get burned

"My GPU is still at 18 GB after the job finished." Expected in persistent mode. Either queue unload, or set the Runtime node's backend to one-shot for one-off runs and accept the cold-start cost of roughly three minutes per job.

unload says no worker was running. Either the idle timeout already got it, you were on one-shot all along, or ComfyUI restarted. Not an error.

Don't queue unload mid-job - it stops the process the job is running in. Cancel first, then unload. status is safe to queue whenever, but a persistent worker serialises jobs, so a status request lands between them rather than inside one.

Two ComfyUI instances sharing one GPU is untested territory in this pack. If you run a second install, expect a worker you forgot about to be holding the memory.