INT

A whole number, with a widget to set it - as plain as node briefs get. It exists as its own node, rather than you just using ComfyUI's built-in INT, because it belongs to the same family as JNComfy's other Primitive, Process, and Conversion nodes, all built around the pack's own generic-typing and multi-input patches. Feed it into JN_MathOperationArray, JN_FirstActive, or any of the To* conversion nodes in the same pack and it slots in cleanly, because that's what it's designed for.

It's part of JNComfy (jn-jairo/jn_comfyui), a one-person pack with a genuinely wide spread - audio TTS, voice conversion, face restoration, sampling extensions - and essentially zero presence in the wider community. It's a personal toolkit that happens to be public rather than a project with an audience, so the README and the node's own schema are the full picture here.

How it works

Set value and it outputs the same number as an INT. It defaults to 0, and the allowed range is enormous - roughly ±1.8 × 10¹⁹ - which in practice means unbounded for anything you'd realistically dial in by hand.

The reason to reach for a standalone integer node at all, rather than typing the number straight into whatever consumes it, is fan-out: set a batch size or a step count once here and wire it to two or three places that need to agree, instead of typing the same number into each one and having them quietly drift apart the next time you tweak it.

The inputs and outputs that matter

• value (required, INT, default 0) - the number.
• Output: INT - passed straight out.

Installing it

ComfyUI Manager: search "JNComfy". Manual:

cd ComfyUI/custom_nodes
git clone https://github.com/jn-jairo/jn_comfyui

Restart ComfyUI. No models, no dependencies.

Common issues & troubleshooting

Steps count, seed, or some other downstream field rejects the value. This node itself doesn't clamp to any sensible range for a specific purpose - whatever node actually consumes the number (a KSampler's steps input, say) enforces its own bounds on its side. If you get an error or a clipped value downstream, that's the receiving node validating, not this one.

Wondering whether to reach for this over ComfyUI's own INT primitive. For a bare number in isolation, there's no real functional difference. The reason to use JNComfy's own version specifically is staying inside one consistent family when the rest of your graph is already using JN's array and math nodes - not some hidden extra behavior in the widget.

Negative numbers where you didn't expect them. There's no floor at zero - the min bound is a huge negative number, not 0. If a node downstream (like an array length or a step count) expects only non-negative values, this node won't stop you from wiring in something negative; that validation is on the other end.