MultipleLoraLoader5 🍌

Same idea as its sibling MultipleLoraLoader3, just with two more slots - five LoRAs, one node. If you're the kind of person who stacks a character LoRA, a style LoRA, a lighting LoRA, and a couple of concept LoRAs on top, this is the one you want: five LoraLoader chains' worth of wiring folded into a single box with a model in and MODEL/CLIP out.

It ships in cgem156-ComfyUI, developer laksjdjf's grab-bag pack of mostly-unrelated ComfyUI tools - the same repo that gave the community attention_couple, its widely-used but famously fiddly regional-prompting node (fiddly enough that simpler forks got built around it). The pack overall trades polish for utility; this loader is one of its more self-explanatory pieces once you know the shape.

The five-LoRA problem, and the switch that fixes it

Each of the five slots is identical: lora_name_N picks the file from models/loras, strength_model_N sets its weight (-20 to 20, though realistically you'll live between 0 and 1.5), and apply_N is a checkbox to disable that slot without unplugging or deleting anything - handy for A/B testing which LoRA is actually responsible for a look you like.

Notice there's no separate CLIP strength per slot - only strength_model_N. This node patches the diffusion model's weights, not the text encoder. The optional clip_optional input is there so your CLIP can travel through the same node cleanly rather than needing its own reroute; it isn't being modified here.

Here's where five slots actually matters more than three: stacking risk goes up with every LoRA you add. LoRA interactions are genuinely unpredictable - enough that the community's working advice is to add them one at a time on a fixed seed and watch what breaks, and to reorder with the heavier LoRAs first if you hit black images or NaN garbage. Five LoRAs at strength 1.0 each is an easy way to end up with 5.0 worth of combined influence fighting your base model. That's exactly what normalize and normalize_sum exist for: flip normalize on and the node rescales whatever's currently enabled down to sum to normalize_sum (default 1), so adding a fifth LoRA doesn't quietly double how "loud" everything else got.

Slot count (3 vs. 5) comes from the pack's own config.txt - these two node names are the built-in variants. If five still isn't enough, that file is where more would come from, though at that point you're well past what most workflows need.

Installing it

Via ComfyUI Manager: search cgem156-ComfyUI, install, restart. Or by hand:

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

Restart ComfyUI afterward. No model downloads or extra Python dependencies for this specific node - it's pure LoRA-file wiring, nothing to fetch.

Common issues

Everything looks muddy or over-processed with all five active. This is the normalize use case - turn it on before you start manually pulling individual strengths down.

One slot does nothing at all. Check base-model compatibility first (an SDXL LoRA loaded against a Flux checkpoint is a silent no-op, not an error), then check for a required trigger word in the prompt.

Results change unpredictably when you toggle one apply_N off. That's expected - LoRA stacking interactions aren't linear, so removing one can shift how the others read even if their strengths didn't change. This is the reason apply_N exists as a toggle instead of forcing you to set strength to 0 and back.

Five LoRAs plus a heavy checkpoint feels slow. Applying LoRAs is real compute, especially on quantized checkpoints where each patched layer has to be dequantized and requantized - five in one pass costs more than one, there's no way around that.