Download All

New pod, or a fresh install, and the workflow you want needs three files. So you go node by node, pasting repo IDs and clicking Download model three times, hoping you didn't fat-finger a filename. Download All is the conductor: one button, and every Model's Download node attached to it starts in sequence, with progress in the node.

No inputs, one output, and the output is a lie

info_schema for this one is nearly empty. It has no inputs at all, and exactly one output: download_models, typed ORELS_DOWNLOAD_CONTROL. That socket carries essentially nothing - the Python control() method returns False. The cable isn't data, it's a declaration of scope: these are the model nodes this button owns.

All the real configuration stays on the model nodes. Version 0.5 actively refuses to let you expose repo_id, filename or category as graph inputs - try it and you get "Keep model settings inside Model's Download; expose only download_control." That's the right call. A repo ID fed in over a wire is a workflow someone can break from the far end of the graph, and the whole point of this node is that a shared workflow provisions itself predictably.

What happens when you click

The frontend walks the cable. Starting from the output socket it follows links - through Reroute nodes and through native Subgraph input slots - until it lands on OrelsModelDownload nodes, reads their three widget values, and POSTs the list to /orels-nodes/models/batch. Nodes that are muted or bypassed are skipped. Then the server validates every destination before it starts anything, and works the list one at a time, holding at most two transfers in flight, while the node's Batch status display refreshes every two seconds ("Model 2/3: flux2-vae.safetensors"). Failures accumulate instead of aborting the run, so one dead repo doesn't kill the other two.

The limits, from the source: between 1 and 64 connected model nodes, and a second batch is refused while one is running. Queue/Run does absolutely nothing here - the button is the trigger.

The nicest trick is the Subgraph one. Bury your three model nodes inside a native Subgraph so they're not cluttering the canvas, run a single control cable from outside into a Subgraph input, and fan it out internally to all three. The pack ships examples/subgraph-download-control.json doing exactly that, which is worth loading once just to see the wiring. Keep the controller itself outside the subgraph - the traversal bails with "Keep the controllers outside the model subgraph" if you don't.

Install

cd ComfyUI/custom_nodes
git clone https://github.com/DarkOrel/Orels-Nodes orels-nodes
python -m pip install -r orels-nodes/requirements.txt

Manager users: search Orel's Nodes under the Orel's Nodes / Models category. The only dependencies are huggingface_hub and filelock. Restart and hard-refresh afterwards, and clear out any older Orels_Nodes / orels-nodesv2 copies - 0.5's unified node IDs mean the batch controller won't recognise model nodes from a stale duplicate.

Gotchas worth knowing before you file a bug

• "Connect at least one active Model's Download." Almost always a controller wired to something that isn't download_control, a controller parked inside the model subgraph, or model nodes still in the model list that haven't been replaced with 0.5 versions.
• Nothing happens on Run. By design. If you want downloads to be part of a queued job, this pack isn't that - it's the opposite, deliberately.
• A batch in flight blocks the next one. Finish or wait; the server state is per-server, not per-tab, so don't be surprised if a second browser window can't start one.

Where it earns its place is template and pod provisioning: one click on a cold box instead of three browser tabs. If your models are already local and cached, the individual button on each model node is the same number of clicks, and this node is furniture.