LoraLoaderExtended

This is the stock LoraLoader you already know, with a second job: it keeps a running list of every LoRA it applied, in the exact format A1111 and CivitAI understand. Same MODEL in, patched MODEL out, same lora_name dropdown, same strength sliders. But instead of forgetting what it did, it hands you a string that says <lora:princess_xl_v2:0.25> and a matching hash, ready to be embedded into your image's metadata.

LoRAs are how you get a specific character or style without switching checkpoints - a small adapter file that patches the model's cross-attention layers. The pack's whole point is uploading images to CivitAI with metadata that actually resolves: the site matches LoRAs by hash, and if your metadata doesn't say which ones you used (with hashes), the image looks like an unsolved mystery. LoraLoaderExtended is the part of that pipeline that stops the mystery from starting.

How it works

It loads the LoRA with comfy.sd.load_lora_for_models - the same path the core loader uses, so no magic in the model math. The work is in the two strings it maintains:

• lora_list - appended as <lora:filename_without_extension:strength_model>, the A1111 prompt syntax.
• lora_hash_list - appended as name: hash. For .safetensors files it computes the kohya-ss hash, which is clever: it reads the 8-byte header length, then hashes only the tensor data after it - fast, and it's the hash A1111's metadata uses. For .pt files it falls back to a full-file SHA-256. Both truncated to 12 hex chars, both cached per file.

The chaining is the intended pattern: run three of these in a row and pass each one's lora_list into the next node's optional lora_list input. They accumulate - by the last one you have all three <lora:...> tags in a single string you can drop into Save Image w/Metadata. Two nice touches: if you set both strengths to 0 it passes the model through untouched (but still returns the strings), and it keeps the last-loaded LoRA in memory so switching between two files doesn't reload from disk every run.

Inputs and outputs

The ones you'll actually touch:

• lora_name - dropdown of everything in ComfyUI/models/loras.
• strength_model and strength_clip - both default 1.0, range −100 to 100. LoRA lore says 0.5–0.8 is often better than the default 1.0; the wide range just means you can overdo it on purpose.
• model and clip - from your checkpoint loader.

Optional: lora_list and lora_hash_list (multiline strings) - this is where the chain connects.

Outputs: MODEL, CLIP, plus STRING (the accumulated lora_list) and STRING (the accumulated hash list).

Install and gotchas

ComfyUI Manager, search "ComfyUI_PRNodes", or:

cd ComfyUI/custom_nodes
git clone https://github.com/pikenrover/ComfyUI_PRNodes

Restart. No pip deps, no model downloads - the LoRAs are yours.

The honest caveat: this node is only useful if you care about CivitAI-compatible metadata. If you never upload, the stock LoraLoader does the same model math with less fuss. And when you're diagnosing "why does my image look off," remember the hash list only records what this node applied - if you silently have a LoRA baked into your checkpoint or loaded by another node, it won't be on the receipt.