SD Lora Loader
The LoraLoader that remembers — so your Civitai hashes come out right
- model
- clip
- last_lora
- MODEL
- CLIP
- NEXT_LORA
On the surface, SD Lora Loader looks like a reskin of ComfyUI's built-in LoraLoader - and functionally, it is. You feed it model, clip, and lora_name, set strength_model and strength_clip, and get a patched MODEL and CLIP out. The extra bit is the NEXT_LORA output, and that bit is the whole reason this node exists in the SD Prompt Reader pack.
Why the extra output matters
The pack's SD Prompt Saver writes real LoRA hashes into your image metadata, which is what makes Civitai auto-detect which LoRA you used. But the saver can't see into the built-in LoraLoader - that node applies the LoRA and forgets its name. SD LoraLoader records it. When you connect its NEXT_LORA output to the saver's lora_name input, the saver knows exactly which LoRA files went into the image and hashes them into the metadata.
Multiple LoRAs work by chaining. Connect one loader's NEXT_LORA into the next one's last_lora input, head to tail, and feed the final chain into the saver. Each node appends its name to the list, so the metadata ends up with every LoRA in the stack. It's a little more wiring than the built-in loader, but it's mechanical and it's the difference between Civitai showing your LoRA stack and Civitai showing nothing.
One nice detail in the source: if you set both strengths to 0, the node skips the actual model patching entirely and just passes the model and clip through while still recording the LoRA name. That's a real edge case (why load a LoRA at zero strength?), but it means the chain bookkeeping never breaks your model.
The inputs that matter
model, clip, and lora_name are required and obvious. lora_name is a dropdown of your models/loras folder. strength_model and strength_clip default to 1.0 and range from -20 to 20, same as everywhere. The one input that isn't obvious is last_lora - it's a wildcard, and it's what you use to chain loaders together. You don't set it on the first node in the chain.
Outputs are MODEL, CLIP, and NEXT_LORA. If you don't care about metadata hashes, just use the built-in LoraLoader - this node buys you nothing except the recording, and it adds a link to the graph. If you're building a pack-style workflow that ends in SD Prompt Saver, it's worth the extra wire.
Installing it
Same as the rest of the pack - ComfyUI Manager (search "SD Prompt Reader") or manually, with the recursive clone:
cd ComfyUI/custom_nodes
git clone --recursive https://github.com/receyuki/comfyui-prompt-reader-node.git
cd comfyui-prompt-reader-node
pip install -r requirements.txt
Restart afterwards. No model downloads, no extra dependencies beyond the pack's single piexif.
When to reach for the selector instead
If you're already using a different LoraLoader - a custom one, or a stack node you like - you don't have to swap it out. The pack also ships SD Lora Selector, which does nothing but record a LoRA name into the same NEXT_LORA chain. Feed its LORA_NAME output into whatever loader you're actually using, and connect the selector's NEXT_LORA to the saver. Same hash result, zero disruption to your existing model-loading graph. SD LoraLoader is for when you want the all-in-one; the selector is for when you don't want to touch what already works.
Inputs (6)
| Name | Type | Default | Description |
|---|---|---|---|
| model | MODEL | — | |
| clip | CLIP | — | |
| lora_name | COMBO | 0 options: | |
| strength_model | FLOAT | 1.00-20–20 | — |
| strength_clip | FLOAT | 1.00-20–20 | — |
| last_loraopt | * | — |
Outputs (3)
| Name | Type | Description |
|---|---|---|
| MODEL | MODEL | — |
| CLIP | CLIP | — |
| NEXT_LORA | * | — |