Float (for Interactive)

InteractiveFloat is the float sibling of InteractiveInteger - a single number in a widget, output as a FLOAT, nothing more complicated than that. It exists for the same reason: the pack ships its own small set of literal nodes (string, integer, float) specifically framed by the author as values meant to travel cleanly through an interactive workflow's pause-and-click execution, rather than assuming you'll reach for ComfyUI's generic float primitive everywhere.

Where you'll actually reach for it is feeding an InteractiveSelectorWithParameters node's parameter_float input - one InteractiveFloat per candidate branch, each set to a different value (a different denoise strength, a different CFG, a different LoRA weight), so that whichever branch a person clicks, its specific float rides along and comes back out of the matching InteractiveSwitchWithParameters.

How it works

No logic beyond "hold this number, output it." Set the value in the widget; it comes out unchanged every execution. All the actual interactivity lives in the selector and switch nodes it usually feeds - this node's job is just to be a clean, reliable source of a decimal value for those to carry.

The inputs and outputs that matter

• float (required, FLOAT, default 0) - the value, set directly on the widget.
• float (output, FLOAT) - wire it into a parameter_float on an InteractiveSelectorWithParameters, or anywhere else that takes a float, like a denoise or CFG input.

One input, one output, same name both sides - there's nothing else on this node to learn.

How to install it

Comes bundled with the whole pack. Via ComfyUI Manager: search "ComfyUI-Interactive" and install. Manually:

cd ComfyUI/custom_nodes
git clone https://github.com/lquesada/ComfyUI-Interactive

Restart after either method. No requirements.txt, no models.

Common issues & troubleshooting

Why use this instead of the built-in float primitive? For a plain non-interactive part of your graph, there's no real difference. Inside a section of the workflow that pauses on an InteractiveSelector/InteractiveSwitch pair, use the pack's own version - it's the one the author built and tested against that pause/re-execute behavior, and it keeps the whole interactive section using consistently-named, consistently-behaving nodes.

Value seems stuck on an old number. As with everything else in this pack, interactive workflows need auto-enqueue off and an empty queue. A change to the widget can look like it "didn't take" if you edited it mid-run rather than while the queue was genuinely idle.

I have several branches and want each to carry a different float. That's the intended pattern - one InteractiveFloat per branch, each with its own value, rather than one shared node feeding every branch the same number. Sharing a single instance across branches just means every choice ends up with the same float, which defeats the point of tying a value to a specific candidate.