Fast Empty Latent Image

RunningHub is the cloud-ComfyUI play: instead of installing the workflow, hunting 40GB of models and untangling someone's broken node pack, you pick a workflow on their site, hit run, and pay cents for the render. The catch is the one you hit two minutes in - the workflow isn't yours. Its Empty Latent Image is locked at whatever the uploader liked, and you're staring at a 1024×1024 output when you wanted portrait.

This node is the door back in. Fast Empty Latent Image overrides the width, height and batch_size of an Empty Latent Image node inside the remote RunningHub workflow, from your local canvas. That's the whole job. It does not make a latent locally, it doesn't touch your GPU, and if you wire it into a local VAE Decode expecting pixels you'll get nothing.

What it actually does

The official RunningHub nodes talk to your workflow through a nodeInfoList - a list of {nodeId, fieldName, fieldValue} records. Each one means "on the remote graph, set this field on this node to this value before you run it." The official pack makes you hand-author that list. Fast Empty Latent Image builds yours for you.

It emits three records - width, height, batch_size - all pointed at the remote node you name, and pushes them out of its single nodeInfoList output, which goes into the RH Execute Workflow node's nodeInfoList input.

The mechanism worth internalising: values go over the wire as strings (fieldValue is always a string), and everything is validated on your side before it's sent. The node refuses to build if nodeId isn't 1–999999, if width or height isn't a multiple of 8 between 16 and 16384, or if batch_size is outside 1–4096. So a typo fails in your console instantly rather than as a mystery error from a server.

The inputs that matter

nodeId is the one everybody gets wrong first. It is not a local node number - it's the ID of the Empty Latent Image inside the remote workflow. Open the workflow on RunningHub, click that node, read the ID off the panel. There's no way to look it up from your end; it's whatever their graph says.

width and height default to 1024 and 1920. That portrait default is a little tell about the author's own taste, and it's a sane starting point for anything modern and vertical. If you'd rather not do arithmetic, the frontend adds a Preset / Custom mode switch with a list of width × height pairs - 1024 × 1024, 832 × 1216, 1216 × 832, up to 1920 × 1024 - plus a Swap Width / Height ↔ button. Preset and Custom each remember their own numbers, so flipping back and forth doesn't wipe what you typed.

batch_size - being able to batch four images from a hosted workflow is genuinely useful for a seed sweep, and it's also the fastest way to spend four times what you meant to. Remote runs are metered.

There's also an optional previousNodeInfoList input. Ignore it unless you're using more than one Fast-RH parameter node; then you chain them, wiring the upstream node's output here, and the merged list travels on to the executor. It's the pack's convention across all four parameter nodes.

Install

One pack, five nodes - install it once, from ComfyUI Manager (search the Git URL or "ComfyUI Fast-RH") or:

cd ComfyUI/custom_nodes
git clone https://github.com/mikolls/ComfyUI-Fast-RH

Restart ComfyUI and hard-refresh the browser tab, because the pack ships a web/ directory with frontend JS and a cached frontend will show you a node with no preset dropdown.

The dependency list is aiohttp>=3.8. That's it - no pinned torch, no ancient numpy. Worth saying out loud because the official RunningHub packs have a history of force-installing old numpy/transformers wheels and breaking unrelated nodes in the same install. Fast-RH is a companion to those nodes, not a replacement: you still need ComfyUI_RH_APICall installed, since that's the thing that consumes nodeInfoList.

Where it goes wrong

Wrong nodeId lands silently. If the number points at a node with no width field, RunningHub just doesn't apply it and runs the workflow at its original size. No error, no warning, an image that isn't the shape you asked for.

Node IDs are not stable across edits. Anyone editing that remote workflow - including you, in their web editor - can renumber nodes. If you've been happily resizing for weeks and it suddenly stops working, re-check the ID before you reinstall anything.

Not every size is sane for the workflow you're driving. The node's limits (multiples of 8, 16–16384) are ComfyUI's own rules, not advice about the model behind the workflow. Feeding 16384 to a Flux or SDXL workflow that expects 1024 gets you a garbage image, or a VRAM error on their end rather than yours.