Multi LoRA Loader

What it is, and the thing it's clearly copying

One node that stacks any number of LoRAs onto a model and a text encoder, applied top to bottom, each entry separately toggleable, one strength per entry covering both MODEL and CLIP. The list is stored as a single JSON blob saved with your workflow, so it's still there after a reload or a ComfyUI restart.

If that description sounds familiar, it should. This is the Power Lora Loader pattern - rgthree's node is the one that actually travelled, named in the README as the inspiration and sitting in the KB with hundreds of corpus threads behind it. The author is upfront: an independent implementation of the same idea, with a few deliberate differences. The list living in one workflow-persisted config, one strength for both MODEL and CLIP, and a custom strength dialog are the differences claimed. What it is not is parity - rgthree's version also reads trigger words off a LoRA file or fetches them from CivitAI and keeps them locally, which is genuinely useful when a LoRA does nothing because you forgot its trigger word. This node doesn't do that.

How it works

Under the hood there is exactly one real widget: lora_config, a STRING defaulting to "[]". The web extension turns that into the multi-row editor you actually see - toggles, filename pickers, − / + strength steppers and the ＋ Add LoRA button. Keeping one serializable widget is what makes the stack survive a reload: there's no hidden per-row state to lose, just a JSON string in the workflow.

At execution the node parses that JSON, skips anything disabled and anything with a strength of exactly 0, checks each remaining name against ComfyUI's LoRA folder list, then calls ComfyUI's own load_lora_for_models with the same strength for both model and clip. Loaded files are cached per path, so a stack that reuses a file across runs doesn't re-read it every time.

Two failure modes are loud and specific, which is a good thing. A name that isn't installed raises LoRA not found: <name>. Malformed JSON raises LoRA configuration is not valid JSON. Neither fails silently, and neither produces a mystery image.

Inputs and outputs

• model (MODEL) - the base model output, not a checkpoint output. Wire it from CheckpointLoaderSimple's MODEL, or from a previous loader if you're chaining.
• clip (CLIP) - the matching CLIP from the same loader. It's a required input here, which is the price of the single-strength design: LoRA training often bakes text-encoder changes, and this node applies your strength to both halves of that.
• lora_config (STRING) - the JSON the UI manages. Leave it alone unless you're hand-editing; if you ever do, the strength key is strength.
• Outputs: model (MODEL) and clip (CLIP). Both go into the sampler and the text-encode path respectively.

The trade-off against core's LoraLoader is small but real: core gives you separate strength_model and strength_clip, this gives you one number. Most people set them equal anyway; the ones who don't are usually pushing a style LoRA hard on the UNet while keeping the text encoder gentle, and they should stay on core's node.

Install

Same pack, no requirements.txt, no model downloads.

cd ComfyUI/custom_nodes
git clone https://github.com/D33MO/ComfyUI-Prompt-Warehouse.git

Or search Prompt Warehouse in ComfyUI Manager, then restart. The node appears as Multi LoRA Loader under the Prompt Warehouse category - the class name is PromptWarehouseMultiLoraLoader, which is why searching for "Multi LoRA" alone can feel like it's missing.

Common issues

The stack came back, the results didn't. The LoRA file never lives in the workflow, only its name. If you share the workflow, the recipient needs the same files installed or the node stops on LoRA not found with the exact name it wanted. That error is the pack doing you a favour - a silently-skipped LoRA is much worse to debug.

A LoRA loads and does nothing. Almost always not the loader. The usual causes: the architecture doesn't match (a Flux LoRA on an SDXL base still appears in the picker), the strength is too high - 1.0 is often too much, try 0.5–0.8 - or the trigger word is missing from your prompt. Check the model page or rgthree's info dialog for the trigger; this node won't tell you.

Strength 0 is not "very weak." It's skipped entirely, no LoRA applied. If you want a hair of something, use 0.05.

Order matters, top to bottom. Two LoRAs fighting over the same concept resolve differently depending on which is applied last - reorder rows with a right-click and note what you settled on, because the workflow records the order and nothing explains it later.