KSampler XY 🍌

This is a normal KSampler with one difference that matters a lot: instead of taking a plain MODEL, it takes an XY_MODEL - the packaged model-plus-LoRA-strength-list produced by LoraLoaderModelOnlyXY. Everything else about it is exactly the KSampler you already know: seed, steps, cfg, sampler, scheduler, positive/negative conditioning, denoise. The difference is entirely in what happens under the hood - it samples once per strength in the list it was handed, instead of once total.

Why it exists

Testing "what LoRA strength should I use" the normal way means cloning your LoRA loader and KSampler N times, one per strength, and manually organizing the outputs. This pair of nodes collapses that into two nodes: load the sweep, sample the sweep. If you haven't read the article for LoraLoaderModelOnlyXY, start there - this node is useless without it.

Inputs and outputs that matter

• model_xy - the XY_MODEL from LoraLoaderModelOnlyXY, not a regular MODEL. This is the one input that makes this node different from a stock KSampler.
• seed, steps (default 20), cfg (default 8), sampler_name, scheduler, denoise (default 1) - identical in meaning to the standard KSampler's fields.
• positive / negative - normal conditioning, applied the same way across every strength in the sweep.
• latent_image - your starting latent, same as always.
• Output: LATENT - a batch, one entry per strength value from the XY loader.

Installing it

ComfyUI Manager → search cgem156-ComfyUI🍌 → install → restart. Or:

cd ComfyUI/custom_nodes
git clone https://github.com/laksjdjf/cgem156-ComfyUI

then restart. No extra dependencies for this node.

Common issues & troubleshooting

Won't accept a plain model. By design - model_xy only takes the XY_MODEL type. If you just want a normal single-strength sample, use a regular LoRA loader and a regular KSampler; don't reach for this pair unless you actually want a sweep.

Run takes much longer than expected. Each entry in your strength list is a full sampling pass at your configured steps/cfg, run back to back. A ten-value sweep at 20 steps is roughly ten times the compute of one sample - budget for that, especially on a slower GPU or a higher step count.

Output batch is hard to tell apart. The LATENT output is just a batch - decode it and save it through a normal VAEDecode → SaveImage pair, and pair it with SaveImageBatch and a matching seed if you want the filenames to reflect the sweep order. Nothing in this node itself labels which image came from which strength, so keep track of your strength_list order when you're comparing the grid afterward.

Same seed, wildly different results across the batch. That's expected and is the whole point - you're holding the seed fixed and varying LoRA strength, so any difference in the batch is attributable to the LoRA, not to random variation.