Remote Float (GeN13)

Denoise is the value people quietly get wrong in two-pass workflows. Pass one at 0.6, pass two at 0.35, except you tuned the second one three sessions ago and now the two numbers live in widgets on opposite sides of the canvas, and one of them isn't even the same parameter you think it is.

Remote Float (GeN13) is the same clone trick as Remote Int, for decimals: put one wherever the value is needed, name the channel, and every clone with that name holds the same number. Change one, they all change.

What's on the node

Two widgets, one output.

• channel - the group name. Same type and same name means same group; a Remote Float on channel res is a different group from a Remote Int on res, which is the right call because a width of 1024 pixels and a 1.024 scale factor shouldn't collapse into one another.
• value - a decimal from -1e9 to 1e9, stepping by 0.01 in the widget and rounded internally to four decimal places. That precision ceiling is deliberate and it's fine for its job: denoise, CFG, megapixels, scale factors, film-grain amounts. If you need six decimals you're doing something numerically fussy that probably wants a Number node or an expression node instead.

Output: FLOAT, the shared value. Wire it anywhere a float socket exists - the denoise input of a KSampler, CFG, an upscale factor, Remote Video's megapixels, Resize's megapixels.

Why the clone part matters for floats specifically

Integers are easy to eyeball. Floats aren't: 0.55 and 0.5500001 look identical in a widget and behave identically, but 0.55 vs 0.5 is a visibly different image and you will not spot it across a room. The failure mode of scattered float widgets is a graph that's almost doing what you designed.

With a channel, there's one number. Bypass is shared too - bypass any clone and the group goes with it, including clones inside subgraphs. That's the sort of thing you only appreciate when you've spent an evening toggling a node you couldn't find.

Unlike Remote Int, there's no control_after_generate here. Floats don't randomize per queue by design; that's what Remote Int is for. If you want a per-run floating value, generate the INT and do the maths downstream.

The patterns

Two-pass denoise. One clone next to each sampler, same channel, one number. Then you can A/B the pair by editing a single field, which is what "two-pass" is supposed to feel like.

Resolution across branches. Megapixels threaded through a latent size node, a video remote, and a preview. When you change the target size you change it once and everything is consistent - no half your graph rendering at 0.4 MP and half at 1.0.

Reference strength. The IP-Adapter / reference-conditioning weight that three nodes all want, defined once, next to the one you're actually tuning.

Installing

Manager → search GeN13 → install → restart. Or manual:

cd ComfyUI/custom_nodes
git clone https://github.com/heigen13/ComfyUI-GeN13
pip install -r ComfyUI-GeN13/requirements.txt

The requirements file is a single line, nvidia-ml-py, for the pack's monitor strip beside the Run button - nothing to do with the remotes, which are a small Python class plus the pack's JavaScript. No model downloads. Portable build: use ComfyUI's own pip, python_embeded\python.exe -m pip.

Caveats worth knowing before you convert everything

Channel names are your namespace and there's no namespace above them. Two different workflows are separate files so they don't collide, but inside one workflow, the default remote on six unrelated nodes will bite you.

The sync is frontend work: the Python side only echoes the value it received. That's fine for normal use and for API-queued runs, but it does mean the "one true copy" of your number lives in the graph file, not in a server-side store.

And the general objection to this whole family of nodes applies: hiding a wire makes a graph shorter and slightly harder to audit. In a forty-node workflow that's a good trade. In a six-node one, use a Primitive and move on.