Fast-RH Random Seed

The smallest node in the pack, and the one you'll reach for most often. It changes the seed of a node in a remote RunningHub workflow and nothing else - no steps, no CFG, no sampler. If Fast KSampler is the sledgehammer for retuning somebody's hosted workflow, this is the single screwdriver for "same settings, different roll."

That distinction is the whole reason it exists. Fast KSampler overrides six sampler fields whether you want them overridden or not - set it up for a seed reroll and you've also frozen steps, CFG, denoise, sampler and scheduler at your values, quietly overriding tuning you probably liked. Fast-RH Random Seed sends exactly one thing.

What it sends

RunningHub's official nodes take overrides as a nodeInfoList: a list of {nodeId, fieldName, fieldValue} records, each meaning "on the remote graph, set this field on this node." This node appends one record - nodeId, "seed", your seed as a string - and pushes the array out of its nodeInfoList output. Wire that into RH Execute Workflow → nodeInfoList. The optional previousNodeInfoList input lets you chain it after another Fast-RH parameter node so both overrides travel to the executor as one list.

That's the entire mechanism. It's a two-widget node: nodeId (the ID of the target node in the remote workflow - read it off RunningHub's editor, it's nothing local) and seed (0 up to 2⁶⁴−1, with ComfyUI's standard control_after_generate dropdown attached).

Set control_after_generate to randomize and every queued run sends a fresh seed; set it to fixed and the entered seed is used every time. That dropdown is the point of the node on a metered platform - you can run the same hosted workflow over and over, changing only the roll, which is how you shop for a good composition before you commit to the settings that make a run expensive.

The seed range is validated before sending. The nodeId is not, which brings us to the trap.

The trap, which is source-level and specific

Unlike Fast KSampler and Fast Empty Latent Image, this node does not check its nodeId at build time - the code validates the seed and then sends whatever node ID you gave it, including the default 0. So it will queue happily with nodeId untouched and hand the executor an override aimed at node 0.

Some remote executors error on that, some ignore the record entirely, and either way the symptom is the same: your seed didn't change and nothing told you why. If a randomize run gives you an identical image, check nodeId first, before you go blaming the workflow.

The second one is universal to this pack: node IDs are only stable while the remote workflow isn't being edited. Anyone moving nodes around in RunningHub's editor can renumber yours.

Install

ComfyUI Manager (search "ComfyUI Fast-RH") or:

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

Then restart ComfyUI. There's no frontend trickery on this node and no model download, so a plain restart is enough. Dependencies are aiohttp>=3.8 and nothing more - no torch pinning, no ancient numpy wheel, which is worth a moment's appreciation given that the official RunningHub packs have a history of force-installing stale numpy/transformers versions and breaking unrelated custom nodes on the way in. You still need ComfyUI_RH_APICall installed, since the executor is theirs.

One thing that is per-node here, though: a seed you like is ephemeral. With control_after_generate on randomize the value rolls after the run, so the seed shown is the next one, not the one behind the image on your screen. ComfyUI's global "widget control mode" setting can be flipped to Before if that keeps biting you; otherwise, when you find a good roll, set the dropdown to fixed before you queue the next run, or the number's gone.