LoRA from Folder (LoRA Control)

You know the pile. Fifty style LoRAs named style-something-v3-final, and no intent to pick between them by hand. LoRA from Folder treats a folder as the thing you're choosing between: point it at styles/ink, queue a batch, get one style per render.

This is the node for the sweep. It pairs naturally with a fixed seed and a single prompt - the community's oldest diagnostic habit, and the same instinct that produced a 62-sampler grid sweep on Z-Image Turbo - except instead of samplers you're sweeping LoRAs you didn't feel like ranking.

How it works

folder is a dropdown built from your models/loras directory, not from a typed string. It lists every folder that holds a LoRA, plus every folder above one - so a folder that only contains subfolders still appears, and can be selected as a container with include_subfolders on. (root) means the top level of models/loras itself. With include_subfolders off, only LoRAs sitting directly in the chosen folder count.

Everything else works exactly like its sibling, LoRA by Name. mode is random (seeded - the same seed always picks the same file, so old workflows still reproduce their image) or sequence (matches in name order, one per queue, wrapping at the end, with the seed acting as the position in the list). The bundled frontend script nudges the seed's control-after-generate to randomize for random mode and increment for sequence mode, so a queued batch steps through the folder without any further input from you. strength is one value applied to both the model and the text-encoder half of the LoRA when a CLIP is connected downstream.

Folder-relative paths are normalised to /, so on Windows a nested pick reads the way you'd write it - the folder list is already the source of truth for the nesting you actually have. Matching and ordering are case-insensitive, which matters more than you'd think: Style-Ink and style-ink sort together instead of clumping by capitalisation.

It also honours the same anti-collision rule as the name picker. In random mode it looks at the lora_stack arriving on its optional input and won't choose a LoRA that's already in it, so a folder picker and a name picker chained together won't land on the same file. In sequence mode it doesn't skip, because skipping would break the order you're stepping through.

Inputs and outputs

• enabled - off passes the incoming stack straight through. Both pickers in the pack's example workflow ship switched off.
• folder, include_subfolders - pick the container, decide whether it means the folder or everything under it.
• strength, mode, seed - same as the name picker. Default strength 1.0 is rarely where you want to leave a style LoRA; 0.6-0.8 is the usual landing spot, and style LoRAs at full strength are how you get the "why does everything look like this LoRA" output.
• lora_stack (optional) - chain in front of it; those LoRAs stay first.

Out comes lora_stack, ready for Apply LoRA Stack, and lora, a string naming the file this run picked. Route it to a PreviewAny: a batch of folder picks with no record of which file produced which frame is a batch you have to throw away.

Install

# ComfyUI Manager: Custom Nodes Manager → search "LoRA Control"
comfy node install comfyui-lora-control
cd ComfyUI/custom_nodes && git clone https://github.com/nzkritik/comfyui-lora-control

Restart afterwards. No Python dependencies at all, but it requires ComfyUI 0.3.48 or newer (it's written against the V3 node API). The pack downloads no models.

Common issues

A folder you just created isn't in the dropdown. The list is built when the node's schema is defined - at ComfyUI startup - so new files inside an existing folder show up straight away, but a brand new folder needs a node-definitions refresh or a restart before it can be selected. Same behaviour you get from any LoRA dropdown.

"LoRA Control: no LoRA in styles/ink" stops the run instead of rendering without your LoRA. That's intentional - the pack's line is that failing loudly beats a silent no-op - but it means an empty folder or a folder whose LoRAs were all already used upstream will block the queue rather than degrade quietly.

Checkpoints don't filter the folder. Nothing here knows whether your LoRAs match the model you loaded; an SDXL style folder picked on a Z-Image run gives you key-mismatch noise and mush. Sort your folders by architecture and this problem disappears.

And be realistic about one-per-run. Half the value here is variety, and variety is exactly what a distilled Turbo model doesn't give you - Z-Image Turbo is known for near-identical output across seeds, and for quality collapse when several LoRAs stack at once. A folder picker plus a character LoRA is two LoRAs, which on that model is already the risky combination. Reduce strengths before you blame the picker.