KSamplerSelect

This is the entire sampler dropdown from KSampler, turned into its own little node. You pick a sampler_name, and out pops a SAMPLER object - a fully-configured denoising algorithm ready to hand to SamplerCustomAdvanced. On its own it does exactly nothing. Its only job is to be the "sampler" piece of the custom-sampler graph.

It's one of the oldest nodes in ComfyUI's custom-sampler system, shipping in core (comfy_extras.nodes_custom_sampler) since September 2023. Nothing to install.

How it works

The dropdown exposes the same sampler list you'd see on KSampler - euler, euler_ancestral, heun, dpmpp_2m, dpmpp_sde, ddim, and friends, over forty of them. Selecting one resolves it to a sampler object with its default parameters, and that object flows into SamplerCustomAdvanced's sampler input.

The split between "select a sampler by name" and "tune a sampler" matters more than it looks. KSamplerSelect is the dumb path: no knobs beyond the name. If you want a sampler whose behavior you can actually tune - eta for stochastic strength, s_noise for noise magnitude, solver order - you use one of the dedicated sampler nodes instead: SamplerER_SDE, SamplerEulerAncestralCFG++, and the other Sampler* nodes in the same menu. Those produce the same SAMPLER type, so you can swap them into the same socket.

When to reach for it

Almost always. It's the workhorse of the custom-sampler graph: you keep a KSamplerSelect around because it's the one place you change samplers without touching anything else, and it's what makes sampler sweeps fast - swap the dropdown, hit run, compare.

Pair it with a scheduler node like BasicScheduler and the classic pair gets fed to SamplerCustomAdvanced together.

Where people get tripped up

• It doesn't hold settings. If you've tuned a sampler's eta and s_noise somewhere, that tuning lives on the dedicated sampler node, not here. KSamplerSelect always gives you the named sampler at its stock parameters.
• The dropdown is not the whole story. The same name appears in both KSampler and KSamplerSelect, but in a custom-sampler workflow the scheduler is doing half the work. People blame the sampler for a bad schedule - check what scheduler is feeding the sigmas first. On flow-matching models specifically, "any scheduler but karras or exponential" is the rule, regardless of which sampler you selected.
• Distilled models. Some samplers are trained-in requirements, not taste: distilled checkpoints want Euler on sgm_uniform/trailing, LCM wants its own sampler. The dropdown can't rescue you from picking the wrong one.

If you need one of the samplers with parameters, skip this node and grab the dedicated one - same output type, same socket, more knobs.

One habit worth stealing from the sampler-sweep crowd: keep a KSamplerSelect around even when a model wants a tuned sampler, because the dropdown is the fastest way to establish a baseline. Run your model's recommended pair, then swap the KSamplerSelect for a tuned node and compare on a fixed seed - that's the whole "change one variable at a time" discipline from the troubleshooting playbook, and it's why this tiny node stays in serious workflows despite doing so little on its own.