KSampler Multi Run

You know the drill: you want to compare three CFG values and three seeds, so you build nine KSampler copies, wire every one to the same checkpoint and conditioning, and keep them straight by squinting at a grid. KSampler Multi Run replaces that pile of nodes with a single KSampler that runs up to 25 samplings across two axes and hands you the results as one latent batch, plus the text you need to label every output.

It's the engine of the ComfyUI-StatusBarOverlay pack, and honestly the reason the pack exists - the other three nodes exist to label and grid its results. No model files, no extra installs beyond the pack itself (the only requirement is Pillow, which ComfyUI already has). For a systematic sweep it replaces the manual "N samplers, one variable at a time" ritual that the community has been posting about since the KSampler era began.

How it works

Pick an x_axis and a y_axis from seed, steps, cfg, and denoise. For each axis you give a count (1–5) and a min/max range. The node builds a value list for each axis, then calls ComfyUI's own built-in sampler (common_ksampler) once per combination - x is the horizontal axis, y is vertical. Every run starts from the same model, conditioning, and latent_image; only the two axis values change. The latents get concatenated into a single batch, so one VAEDecode downstream turns the whole sweep into one image batch.

Two things worth knowing about how axis values are generated. For seed, the node uses a deterministic generator seeded by seed_generator_seed, so the same generator seed plus the same range and count always produces the same seed list - that's how you get reproducible sweeps. For steps, cfg, and denoise it's a plain evenly-spaced range. Only want one axis? Set the other's count to 1.

The inputs that matter

Everything you'd set on a normal KSampler is here - model, seed, steps, cfg, sampler_name, scheduler, positive, negative, latent_image, denoise - and they act as the base values used whenever that parameter isn't on an axis. The node-specific ones:

• x_axis / y_axis (default seed / cfg) - the two parameters to sweep. They must differ, or the node refuses to run.
• x_count / y_count (max 5 each) and x_min/x_max/y_min/y_max - the sweep itself. The hard cap is 5×5 = 25 runs, enforced with an error rather than a silent truncation.
• seed_generator_seed - makes seed sweeps reproducible.

The outputs that matter

samples is a LATENT batch - wire it to VAEDecode. status_list is the per-image caption text ("seed=…, steps=…, cfg=…, denoise=…, sampler=…, scheduler=…") meant for the pack's Batch Status Bar Overlay, and columns/rows tell Batch Image Grid how to lay the grid out. run_info is a human-readable log of every run, handy to save alongside the results. changed_values_list is a slimmer variant with just the two axis values per image.

Install

cd ComfyUI/custom_nodes
git clone https://github.com/muskccat/ComfyUI-StatusBarOverlay

then restart ComfyUI - or search "StatusBarOverlay" in ComfyUI Manager and let it handle it.

Troubleshooting

The errors this node throws are loud and specific: same axis twice, a count above 5, or min > max all abort with a clear message. The subtler trap is VRAM. Twenty-five runs of high-res sampling with CFG above 1 is 25 full double-prediction passes sharing one GPU - a 5×5 sweep of 1024×1024 SDXL is a real chunk of time and memory. And remember every run starts from the same latent_image: that's expected for img2img denoise sweeps, but it means a seed sweep on img2img is really "same starting image, 25 different seeds."

Is it the fanciest sweep node on the block? No, and the pack has zero community footprint - nobody's making threads about it. But if you want one node that turns "compare a few CFGs and seeds" into a labeled grid without building it by hand, this does exactly that, plainly.