MultiLoRA Cycle

You just trained a checkpoint, or you're comparing five character LoRAs, and you want to see each one at 0.5, 0.75, 1.0 and 1.25. The normal way is an hour of clicking Queue, nudging a strength slider, clicking again. MultiLoRA Cycle automates that loop so you can go make tea and come back to a folder of labeled test images.

It's a companion node to the Multi LoRA Loader in the same pack, not a loader itself. You set a list of strengths, connect its load_options output to the loader's load_options input, turn on auto-queue, and every queue run the pair advances one step: LoRA 1 at 0.5, LoRA 1 at 0.75, LoRA 1 at 1.0, LoRA 2 at 0.5, and so on. This is the exact batch-testing workflow the README describes for LoRA training checkpoints, and it answers a very real itch - people build entire custom node suites for precisely this ("tired of guessing which model/prompt/sampler/LoRA/step combo works best" is a recurring +200-score thread). This node is that, but purpose-built for LoRAs.

How it works

The neat part: the Python side is nearly a no-op. The real work happens in the JS frontend, in a beforeQueued hook that fires before ComfyUI serializes the graph for a run. The cycle node walks the graph, finds the connected loader, and rewrites its lora_data to the current LoRA × strength combination. By the time Python executes, the loader just sees the correct data for this iteration - no fragile state passing between two Python nodes.

Two details worth knowing. First, the node returns float("NaN") from its IS_CHANGED method - the standard always-rerun trick - because the whole point is that its state changes every queue, and ComfyUI's cache would otherwise skip it. Second, its load_options output carries a "cycling" flag so the loader knows to let zero-strength values through (0 is a legitimate test strength; normally a zero LoRA is skipped).

The inputs that matter

• strengths - the comma-separated list to test, default 0.5,0.75,1.0. Negative and zero values are valid, which is handy if you want to prove a LoRA actually hurts.
• mode - increment auto-advances every run; fixed holds the current indices. If you forget to set increment, the node won't cycle and you'll just re-render the same image.
• loop - wrap back to the start when every combination is exhausted.

lora_index and strength_index are 1-based position trackers, not things you normally type. But they're your resume point: stop auto-queue, and they stay exactly where they were. Manually bump strength_index to skip a value you've already seen.

Output

One output: load_options, which wires straight into the Multi LoRA Loader's load_options input. The node shows a status line under the widgets - something like my_training-000800 (3/7) | STR: 0.75 (2/4) - telling you LoRA 3 of 7 is active at strength 2 of 4. That display is your sanity check before you queue fifty runs.

Install and gotchas

It ships inside phazei/ComfyUI-MultiLoraLoader, so install is the same as any node pack: search "Multi LoRA Loader" in ComfyUI Manager, or

cd ComfyUI/custom_nodes
git clone https://github.com/phazei/ComfyUI-MultiLoraLoader

Then restart ComfyUI. The pack has zero Python dependencies beyond ComfyUI itself - it's a JS frontend plus a thin loader, no model downloads, nothing to configure.

A few traps the README spells out:

• The first queue run doesn't increment. It uses the current indices as-is, so your run #1 is LoRA 1 at the first strength.
• Saved metadata locks the mode to fixed. When you open a workflow from an output file, the cycle node won't start auto-advancing - you see exactly the LoRA and strength that produced that image. Good default, but it surprises people.
• Wrong wiring does nothing silently. load_options must go to the loader's load_options input; anywhere else and the cycle node has nothing to mutate. Watch for the red-link connection to catch it.

For most people this node replaces the "sit there and queue" phase of LoRA testing entirely. Set it up once, let it run, and pick your winners from the output filenames.