Y7 Float

Tuning anything by hand looks like this: denoise at 0.30, queue, look, drag to 0.35, queue, look, drag to 0.40. Y7 Float is the native Float node with a seed-style stepper bolted onto it. Set the value once, flip control_after_generate to increment, set step to 0.05, queue ten prompts, go make coffee. Each queued prompt gets the next number in the line.

Why a node for one number

Nearly every workflow is mostly plumbing - a node that holds a number, a fan-out point, a switch. Those nodes exist because the alternative is typing the same value into five widgets and forgetting one of them. If you want one denoise feeding an img2img pass, a save-image filename and a note to yourself, you want it on a wire, coming from one place.

The other half of the story is the thing every ComfyUI user gets bitten by once: the control_after_generate dropdown on the seed. fixed, increment, decrement, randomize - and the default firing after the run, so the number in the box is the one that will be used next, not the one that just made the image on your screen. That mechanic is exactly what Y7 Float borrows, with one change that makes it useful: the amount moved is a widget you set, not the value field's own 0.01 step.

How it actually works

The stepping is browser code, not Python. The pack ships web/js/float.js, which hooks the value widget's own beforeQueued / afterQueued callbacks and adds step to the value - clamped to the widget's min and max, with the float drift trimmed off (0.1 + 0.2 is 0.30000000000000004 in JS, and that error compounds over a long run). The Python side just returns whatever value currently is:

@classmethod
def execute(cls, value, control_after_generate="fixed", step=0.1) -> io.NodeOutput:
    return io.NodeOutput(value)

Which tells you two things up front. First, whether the number moves before or after the prompt is sent follows ComfyUI's own Widget Control Mode setting, the same one that decides when a seed gets stepped. Second, because the whole mechanism is frontend JavaScript, a prompt posted straight to the /prompt API by a script never steps anything - there's no browser there to do it.

Inputs and outputs

• value (FLOAT, default 0) - the number on the output, shown to two decimals, because the field itself steps by 0.01 when you drag or type.
• control_after_generate (default fixed) - fixed leaves it alone; increment / decrement move it by step each time a prompt is queued.
• step (FLOAT, default 0.1) - how far. Ignored when the mode is fixed.

One output: value (FLOAT). Convert value to an input and wire something into it and the stepping switches off, because the incoming link owns the number now - that's a clean way to disable a sweep without deleting it.

With a batch count of ten, the value moves once per prompt, so all ten runs are different.

Install

Manager is the sane route: Custom Nodes Manager → search Y7 → install → restart ComfyUI. Manually:

cd /path/to/ComfyUI/custom_nodes
git clone https://github.com/yushan777/ComfyUI-Y7Nodes
# activate your venv, then:
pip install -r requirements.txt

That requirements.txt is one line, color-matcher>=0.5.0, and it's for the pack's Color Match node, not this one - Y7 Float needs nothing beyond stock ComfyUI. Look under the Y7Nodes/Utils category, or search for the display name.

Where people get burned

The trap is the same one as the seed, and it's a one-time fix: go to ComfyUI's settings and set Widget Control Mode to before. On the default (after) setting, the number displayed on the node is the number that will be used next - so you queue a run at 0.30, see 0.35 on the node afterwards, and if you then stick that 0.35 in a prompt log you've written down the wrong run's value.

Two smaller ones. A step finer than 0.01 works arithmetically, but the number displayed rounds to two decimals - so the display isn't a record of what ran. If you care, print it into the filename instead (Y7 Save Image's %Node.widget% with a :N suffix reads the real value). And once a batch is queued, every prompt in it already has its number; editing the widget mid-queue doesn't fix the ones behind you.

Should you use it

It walks a line, not a grid. If you want denoise × CFG crossed into a matrix, this is not that node and you'll be happier with a proper batch/sequence pack. But for the very common case - one prompt, one knob, ten values, queued and walked away from - it's the smallest possible thing that does the job, and it costs nothing to leave in a workflow at fixed for the ninety percent of the time you don't need a sweep.