LoRA Batch Loader
Test every LoRA in a folder without rebuilding the graph
- model
- clip
- model
- clip
- filename
If you've ever downloaded twenty LoRAs for the same character and wanted to A/B test them all, you know the grind: swap the LoRA in the loader, queue, swap, queue. LoRA Batch Loader is the fix. It watches a folder, applies one LoRA per queue run, and advances to the next one every execution - so you set up the graph once, queue twenty times, and walk away. Same idea as its image-sibling loader, but it operates on the MODEL and CLIP objects instead of pixels.
It ships in Zar4X/ComfyUI-Batch-Process, alongside the image and text batch nodes. It's the node in the pack that most directly earns its keep for people who test a lot of LoRAs.
How it works
Feed it your base model and clip from a checkpoint loader, plus directory. It scans the folder for .safetensors, .ckpt, .pt, and .bin files, filters by name, and on each execution loads the next LoRA using ComfyUI's own comfy.lora machinery - the same loader the built-in LoraLoader uses, just pointed at a folder instead of a single file. It even suppresses ComfyUI's chatty LoRA-loading logs so your console isn't a wall of key-map spam.
mode is incremental (walk the folder in order, cycling) or random (seeded). There's no "single" mode here - if you want a fixed LoRA, use the regular LoraLoader. strength_model and strength_clip default to 1.0 and range from -20 to 20; negative strength is a legit trick for suppressing a LoRA's influence, though the built-in loader lets you go there too.
Outputs and the trick that makes it usable
Three outputs: the patched model and clip (wire them into your sampler exactly like a normal LoraLoader), plus filename - the LoRA's name with the extension stripped. That third output is the one that makes batch testing legible: run it into a text display node (or this pack's saver via contents) so you can see which LoRA the current render used. Otherwise you'll stare at twenty outputs and have no idea which was which.
Pair it with the LoRA folder structure you already keep: a base checkpoint, a folder of candidate LoRAs, and you've got a poor man's LoRA comparison rig. Just remember the LoRA must be compatible with the base checkpoint family you feed in - an Illustrious LoRA on a Flux base will silently misbehave rather than politely refuse, because loaders like this don't always warn you.
Installing it
Manager search ComfyUI-Batch-Process, or:
cd ComfyUI/custom_nodes
git clone https://github.com/Zar4X/ComfyUI-Batch-Process
Restart. No models to download; dependencies are just Pillow and torch.
Troubleshooting
If the folder is empty or nothing matches, the node returns your model and clip unchanged with filename of "no_loras_found" - no crash, just silently no-op, so check the console for "No matching LoRA files found." The random mode only randomizes which LoRA each run picks, not the seed of the sampler itself, so set your sampler seed separately if you want a fair comparison. And because the node cycles, a long queue will loop back to the first LoRA after the last one - usually the point, occasionally a surprise.
Inputs (10)
| Name | Type | Default | Description |
|---|---|---|---|
| model | MODEL | — | |
| clip | CLIP | — | |
| directory | STRING | — | |
| search_title | STRING | — | |
| delimiter | STRING | — | |
| mode | COMBO | incremental | 2 options: incremental, random |
| seed | INT | 00–18446744073709550000 | — |
| filename_option | COMBO | 5 options: filename, prefix, suffix, prefix & suffix, prefix nor suffix | |
| strength_model | FLOAT | 1.00-20–20 | — |
| strength_clip | FLOAT | 1.00-20–20 | — |
Outputs (3)
| Name | Type | Description |
|---|---|---|
| model | MODEL | — |
| clip | CLIP | — |
| filename | STRING | — |