Selector In (INT)

SelInInt ("Selector In (INT)") is the integer sibling of the pack's SelInFloat: eight INT inputs, one model_type selector, one INT output. Same architecture, different data type - and the natural home for the two integers every workflow cares about: steps and seed.

Steps is the poster child for per-model values, because the right number is wildly model-dependent. A classic SDXL fine-tune wants 20–30 steps to settle. A guidance-distilled model wants closer to 8 - step count is one of the things distillation trains away. If you run both in one graph, a single "steps" widget is actively wrong half the time. Port 1 holds 25, port 3 holds 8, and the model_type broadcast from a RecourseCkpt decides which one the KSampler sees. Seed works the same way if you want per-model seed pools or a "stay fixed on this family" behavior.

How it works

Pack standard all the way down: model_type (1–8, required) selects int<number>, and the winner flows out the single INT output. Inputs are lazy, though for plain integers that's not doing heavy lifting - unlike the MODEL or LATENT variants, there's no expensive object sitting behind a port. The real value is organizational: one numeric value per model family, selected automatically, no rewiring.

Inputs & outputs that matter

• model_type (INT, required) - the selector, normally fed by RecourseCkpt.
• int1 … int8 (INT, optional) - your per-model values. Steps, seed, batch size, clip skip (careful - that one's usually negative), whatever your graph needs as an integer.
• INT output - the winner, wired into a KSampler's steps/seed, an Empty Latent's batch_size, or a detailer's iteration count.

Installing it

The pack standard, which is genuinely trivial. ComfyUI Manager → search comfyui-selector → install → restart, or:

cd ComfyUI/custom_nodes
git clone https://github.com/exdysa/comfyui-selector

Restart and it's under Selector_Recourse/In. No requirements.txt, no model files, no network access.

Gotchas

• Unwired ports return None, not a default. The model_type number must point at a connected port or the output is dead and downstream won't run - check that number first when a workflow silently stops.
• No labels on the ports, so if you park four different "step count" values in one node, annotate them or you'll forget which family owns which. That's the #1 real-world failure with this family of nodes.
• It's a switcher, not a tuner - the values are only as right as the numbers you type. And like the whole pack (single-author, GPL-3.0, quiet since early 2025), it's a small convenience layer, not infrastructure. For a one-model workflow, a plain Int node is all you need.