XBHH Multi Lora Loader 🎨
The multi-LoRA loader that stacks a dozen adapters without a mountain of nodes
- model
- clip
- MODEL
- CLIP
This is the flagship of the XBHH kit: one node that loads as many LoRAs as you want from a single interface. Stock ComfyUI gives you a LoraLoader that handles exactly one adapter per node - run four LoRAs and you've got four chained nodes plus a mess of wires. The XBHH Multi Lora Loader folds all of that into a single node with an "➕ Add Lora" button, a folder-tree picker, per-LoRA strength sliders, hover previews, and a trigger-word database. If you stack adapters constantly, this is the reason to install the pack at all.
LoRAs are the currency of every model ecosystem - small low-rank patches that change a checkpoint's behavior without retraining it. Stacking is the standard move (a character LoRA plus a style LoRA plus a VAE-fix), but every adapter you add is another chained node. This node replaces the chain.
How it works
The backend (lora_loader.py) uses the same flexible-input trick rgthree-comfy made famous: the node accepts a variable number of dynamic LoRA inputs, each carrying a name plus model/clip strengths. On execution it loops through every enabled slot and calls ComfyUI's own LoraLoader under the hood for each one, in order. Slots marked off are skipped; zero-strength entries are skipped; a missing file logs a warning instead of killing the run.
The frontend is where the real work lives. Each added slot gives you a searchable folder-tree dropdown of everything in ComfyUI/models/loras, two strength fields, and a trigger word. Hover a LoRA in the list and it fetches a preview image via the pack's own API routes - which look for a same-named PNG or JPG sitting next to the .safetensors (so drop mylora.png beside mylora.safetensors and previews just appear, the CivitAI convention). Every selection also gets logged into a local SQLite database, used by the trigger-word features and a "most used" sort.
The inputs that matter
- model / clip (optional) - feed the checkpoint's MODEL and CLIP in, get patched versions out. The two outputs,
MODELandCLIP, wire straight into the sampler. - Every
LORA_*slot you add - these don't show in a static schema because they're created dynamically. Each has on/off, LoRA name, and model/clip strength.
Strength is the dial you'll actually touch. The old SDXL wisdom of 0.5–0.8 is stale advice on modern bases where people run 1.0 and above; the point is that stacking several adapters compounds, so with five LoRAs at full strength you can end up oversaturated. Start each slot low and layer up.
Installing it
cd ComfyUI/custom_nodes
git clone https://github.com/xbhh123456/Comfyui-xbhh-main.git
cd Comfyui-xbhh-main
pip install -r requirements.txt
Or search xbhh-lora in ComfyUI Manager, then restart. No model downloads - the node reads your existing models/loras folder.
Common issues
- Preview images missing - most LoRAs don't ship a same-name image. Either download the preview from the CivitAI page or ignore it; the loader still works.
- A LoRA silently does nothing - check architecture. A Flux LoRA will not run on SDXL, period; the node can't save you from loading an incompatible adapter, it'll just apply it to nothing useful.
- Trigger words not showing - the SQLite trigger-word database fills as you use LoRAs, so early on the field is empty. You can type one in manually and it persists per LoRA name.
One more thing: this pack's category is XBHH/loaders and the Plus variant (XBHHMultiLoraLoaderPlus) is the same node plus preset import/export - if you keep reusing the same LoRA combos, that's the one you actually want. This base version is the right call when you just want stacking without the preset bookkeeping.
Inputs (2)
| Name | Type | Default | Description |
|---|---|---|---|
| modelopt | MODEL | — | |
| clipopt | CLIP | — |
Outputs (2)
| Name | Type | Description |
|---|---|---|
| MODEL | MODEL | — |
| CLIP | CLIP | — |