🛠AGSoft KSampler options_lora

🛠AGSoft KSampler options_lora answers a question every LoRA raises and almost nobody tests properly: what strength should this thing actually be? The community consensus - 1.0 is usually too strong, 0.5–0.8 is the working range - is the starting point, not the answer. Different LoRAs fold differently, and the one that flatters your style at 0.7 might be welding a second nose onto every portrait at 0.9.

This node gives you a column of strengths, one image each, in a single queue run.

Why it's built the way it is

The whole design turns on the fact that patching a LoRA into a model isn't free but is cheap, so the series can live inside one execution. Here's the split, straight from the source:

In series mode the model you pass in goes to AGSoft KSampler unpatched. This node instead hands over a list of overrides - lora_name, strength_model, and strength_clip if clip is connected - and the KSampler patches a model clone per item before sampling. Same seed, same everything else, one clone per strength. That's the experiment you want: any difference in the batch is attributable to the strength and nothing else.

clip is genuinely optional, not decoratively optional. If you don't connect it, no clip keys exist anywhere in the pipeline and the clip output passes nothing. If you do connect it, current mode patches your CLIP at the current pair on the spot - but in series mode the clip strengths only ride along in the options and in the captions, because the conditioning gets encoded once further up the graph. Read that as: sweeping clip strength alone needs current mode. Sweeping model strength is what series mode is for.

The controls

Five inputs matter. model - the model you're testing. lora_name - picked from your models/loras folder. output_mode - series (one run, batched images) or current (one pair per run via a server-side counter, so bring Auto-Queue). And then two values per row: strength_m_N for MODEL and strength_c_N for CLIP.

Up to thirty rows, each with an enabled_N toggle, and clearing strength_m_N skips that row. The strengths ship as string fields with a horizontal stepper in the node UI: ◄/► steps by 0.05, Shift-click by 0.01. That's a nicer way to walk from 0.4 to 1.0 than typing decimals.

Outputs: model (unpatched in series - wire it into the KSampler), clip (only meaningful if you connected one), options (into the KSampler's options input), current_str - lines like lora = myStyle_v3, model = 0.75, clip = 0.75 - and status. Feed current_str into Contact Sheet and you have a captioned strength ladder in one image, which is the fastest way I know to pick a number.

Install

cd ComfyUI/custom_nodes
git clone https://github.com/Art-xmaster/comfyui-AGSoft
# restart ComfyUI

Manager → search comfyui-AGSoft. Nothing extra to download; the node reads your existing LoRA list.

Gotchas

lora_name shows only __none__. That's the fallback when the node finds no files in models/loras at load time. Either you have no LoRAs installed in the right folder, or the list was empty when ComfyUI started. With __none__ selected the node returns an empty options dict and no patching happens - nothing errors, you just get base-model images.

Architecture mismatch. A LoRA trained for one family generally won't behave on another, and the dropdown doesn't police that. If the ladder looks like noise at every strength, suspect the LoRA/checkpoint pairing before the node.

Trigger words still matter. A strength sweep on a character LoRA whose trigger word is missing from your prompt is testing the wrong thing.

Keep the seed fixed. Series mode re-samples the same latent at each strength, which is precisely the disciplined comparison the debugging guides ask for: change one variable, hold the rest. If you were relying on the KSampler's seed being randomized per run, you're about to lose that comparison - set it to fixed first.