Int To Number

ComfyUI has more than one "it's a number" type, and they don't always connect to each other on the canvas. INT is what most counters, seeds, and step counts use; NUMBER shows up on nodes that were built to accept either an int or a float generically. When you've got an INT-typed output and the node you want to feed expects NUMBER, ComfyUI won't just let you drag the wire and move on - you need something in between to bridge the two. IntToNumber is that something: it takes an INT and hands back a NUMBER carrying the same value.

There's no logic to it beyond the type conversion itself, which is exactly why it's worth having as a dedicated node rather than something you'd expect a bigger node to handle internally - ComfyUI's type system is strict about this distinction even when, to a person, an integer obviously is a number.

It's part of comfyui-easyapi-nodes, lldacing's collection of small utility nodes, most of which exist for the same reason this one does: ComfyUI's graph makes you explicit about types in places a general-purpose scripting language wouldn't bother you.

The inputs and outputs that matter

• INT (required) - the integer value to convert. That's the entire input.
• Output: NUMBER - the same value, now typed as NUMBER, ready to wire into anything that specifically wants that type.

How to install it

Through ComfyUI Manager, searching comfyui-easyapi-nodes. Or by hand:

cd ComfyUI/custom_nodes
git clone https://github.com/lldacing/comfyui-easyapi-nodes.git
cd comfyui-easyapi-nodes
pip install -r requirements.txt

Restart ComfyUI afterward. Nothing else to install for this node - no models, no extra Python dependencies beyond what the pack as a whole needs for its image-handling nodes.

Common issues & troubleshooting

The wire won't connect even after adding this node. Double-check the direction - IntToNumber only converts INT into NUMBER, not the other way. If you need to go from NUMBER back to INT, you'll want a different conversion (or check whether the consuming node actually needs a NUMBER at all - sometimes it's easier to trace back and use an INT-native source instead of converting).

Not sure why my graph needs this at all. It usually shows up when you're mixing nodes from different packs - one pack's counter or math node outputs INT, another pack's node (built to be flexible about int-vs-float) expects NUMBER. If everything in your graph is from the same source and things were connecting fine before, you probably don't need this node; it earns its place specifically at those cross-pack seams.

Precision or value looks off after conversion. It shouldn't - this is a straight type re-tag, not a math operation, so the numeric value itself doesn't change. If something looks wrong downstream, the bug is more likely elsewhere in the graph than in this conversion step.