🏷️ LoRA Loader Prompt Tags

A1111 users have had <lora:MyLora:0.8> in the prompt box for years. ComfyUI never did - LoRAs mean a loader node per LoRA, chained model and clip wires, a pile of widget values, and a graph that reorganises itself every time you add one. This node (forked from badjeff's original tag loader, with a much better name-matching system bolted on) gives you the prompt syntax back: type the tag, wire MODEL and CLIP through the node, done.

It's the node I'd reach for when I'm iterating on what a LoRA does rather than building a fixed pipeline. Add a tag, hit queue, remove it, queue again - versus disconnecting and reconnecting two sockets every time.

How it works

The node regex-scans the incoming string for anything in angle brackets, keeps only the tags whose first field is lora, and applies each one in turn to the model and clip that came in the front. Everything else in the string is passed along untouched.

Tag syntax: <lora:name>, <lora:name:weight>, or <lora:name:model_weight:clip_weight> for the four-part version when you want the CLIP side weaker than the UNet side. Two quirks straight from the source: a strength of literally 0 is treated as 1.0, and a non-numeric strength is also treated as 1.0 (with a console warning). If you genuinely need a LoRA off, remove the tag rather than setting zero.

Name matching is the good part. Exact filename wins; numbered versions are handled sensibly (myLora-2 prefers that file, and falls back to other versions or the bare name); then prefix match, then "contains", with a mild preference for files nearer the root of your LoRA folders. So <lora:detail> finds add_detail_v3.safetensors without you typing the whole thing.

Inputs and outputs

Inputs are just MODEL, CLIP and STRING - the prompt. Wire your checkpoint loader's outputs into the first two and your prompt text into the third, then send the node's outputs on to the sampler's model input and the CLIP Text Encode.

Outputs are MODEL, CLIP and STRING. That third one matters: it's your prompt with the tags stripped out, which is what you want to feed the text encoder, because <lora:...> is not something CLIP should ever see. It also means the sampler never sees your LoRA syntax, so if you want the tags in the saved metadata, keep the original string as a separate branch.

Install

ComfyUI Manager → search "ComfyUI-mnemic-nodes" → install → restart. Manual:

cd ComfyUI/custom_nodes
git clone https://github.com/MNeMoNiCuZ/ComfyUI-mnemic-nodes

No downloads, no API keys. The pack's dependencies come along for the ride; this node itself mostly needs ComfyUI's own LoRA machinery.

Common issues

"Applying LoRA" in the console but the image doesn't change. Check the strength - a 0 in the tag gets coerced to 1.0, and a typo'd strength does the same. If nothing at all is logged, the name didn't match a file. The pack has settings for LoRA console logging and fuzzy search; turn both on while debugging.

A LoRA loads but does nothing. Wrong architecture is the usual cause - an SDXL LoRA against a Z-Image or Qwen model won't error loudly, it just gets ignored. This is the same class of silent failure the community's been bitten by with embeddings on LLM-encoded models: no message, no effect, and you blame your prompt.

Wrong file wins the match. contains matching is broad. Use a longer fragment of the filename, or the exact stem, and it'll stop surprising you.

You want one LoRA to stay permanent. Put it in a normal LoRA Loader node upstream and use this for the per-prompt ones. Chaining both is fine.