KSampler (WAS)

It's the standard ComfyUI KSampler with one deliberate change: the seed is an input socket instead of a widget baked onto the node. That's the entire pitch, straight from the pack - "a sampler that accepts a seed as a node input." Sounds minor. It quietly unlocks a bunch of workflows that the stock KSampler makes awkward.

The stock KSampler keeps its seed as a number field you set on the node itself. That's fine until you want the same seed to drive several things at once - the sampler, a filename token, a second sampler in an upscale pass, a logic branch. With the seed trapped inside the node, you can't share it. KSampler (WAS) exposes it as a wire, so one Seed node (or a Random Number node, or any number source) can feed the sampler and be read everywhere else too.

Why you'd reach for it

Reproducibility and coordination. A few concrete cases:

• Bake the seed into the filename so every saved image records exactly what made it. Feed one seed to the sampler and to a Save Image token.
• Two-pass / hires workflows where the base pass and the refine pass should share a seed for consistency - one source, two consumers.
• Randomize deliberately: pipe a Random Number node into the seed so you get controlled randomness you can also log, rather than the sampler's internal randomize-on-run that you can't see until after.

If none of that applies to you, the plain KSampler is fine - this is a convenience for people wiring seeds around, not an upgrade to sampling quality. The math is identical.

The inputs and outputs that matter

Everything a normal KSampler has - model, positive and negative conditioning, a latent to denoise - plus the standard sampling controls, with the seed pulled out as its own input:

• seed (as an input) - the headline feature. Plug a Seed or Number node in here.
• steps - how many denoising iterations. 20–30 is the usual band; more isn't automatically better.
• cfg - how hard the model chases your prompt. This is the one beginners crank too high. Community-sane ranges: 5–9 for SD 1.5/SDXL, 4–6 for Pony/Illustrious, and near 1–2 for distilled/Turbo/Lightning models. Push CFG to 12+ and you get oversaturated, "deep-fried," face-melting output; the first fix for a burned image is always to lower CFG.
• sampler_name / scheduler - the sampling algorithm and its noise schedule.
• denoise - 1.0 for a fresh generation, lower (0.3–0.5) for an img2img or hires second pass.

The output is a LATENT, exactly like the stock sampler - send it to a VAE Decode.

Installing it

Ships in WAS Node Suite. ComfyUI Manager: search WAS Node Suite, install, restart. Or:

cd ComfyUI/custom_nodes
git clone https://github.com/WASasquatch/was-node-suite-comfyui

install requirements.txt against your ComfyUI Python, restart.

Common issues

Image looks burned / oversaturated / faces deform. Not the node - that's CFG too high for your step count. Drop CFG to ~7 (or far lower on a distilled model) and give it 25–30 steps. Change one variable at a time with a fixed seed so you can actually see what each change did; that's the whole reason seed control is handy here.

"Same seed, different result" between the WAS sampler and the core one. Seed handling and any internal quirks can differ subtly between implementations; if you're chasing exact reproducibility, keep the same sampler node throughout the pipeline rather than mixing core and WAS samplers.

The node vanished after updating ComfyUI. Pack-level, not node-level. WAS Node Suite is retired and its pinned dependencies collide with ComfyUI updates, throwing "Import Failed" that removes every WAS node at once. Reinstall the pack's requirements against the correct ComfyUI venv (or run the bundled install.bat) to restore them.

If you want the fancier loop version - HR upscale passes with an upscale model and step-based upscaling - the pack also ships KSampler Cycle. This node is the plain, seed-as-input variant.