π·οΈ LoRA Loader Prompt Tags
LoRA Loader Prompt Tags β ComfyUI Node Guide
- MODEL
- CLIP
- MODEL
- CLIP
- STRING
If you've ever used Automatic1111, you already know the <lora:MyLoRA:1> syntax - type the tag straight into your prompt and the LoRA just loads, no separate node, no wiring. This node brings that exact trick into ComfyUI. Drop it between your checkpoint and your CLIP Text Encode, feed it a string with one or more <lora:name:strength> tags in it, and it applies every one of them to the model and CLIP before handing you back a cleaned string with the tags stripped out - ready to encode without <lora:...> literally showing up as text in your generation.
Why bother when ComfyUI already ships a normal LoRA Loader node? Because that one is static - you pick a LoRA, once, by hand, in a dropdown. This one reads the LoRA choice from text, which means it can come from anywhere text can come from: a wildcard file, an LLM-generated prompt, a spreadsheet row piped through a batch script, or a randomizer elsewhere in your graph. It's the same underlying problem rgthree's popular Power Lora Loader solves with a GUI - stack LoRAs, toggle them, done - solved the opposite way: no dedicated widget, no clicking, just tags living inside the prompt itself. If your workflow already resolves prompts as strings, this slots straight into that pipeline; if you just want to manually pick two or three LoRAs and adjust sliders by hand, rgthree's version is genuinely less fiddly for that specific job.
It isn't the only node in this pack that speaks this dialect, either. The Batch Wildcard Upscale Sampler parses the identical <lora:name:strength> tags inline as part of resolving per-image wildcard prompts, and Prompt Property Extractor recognizes the same tag as one of a dozen it understands. This node is the standalone version - useful when all you want is the LoRA-loading behavior without the rest of either of those nodes' machinery.
Inputs that matter: MODEL and CLIP come from your checkpoint loader as usual. STRING is your prompt text containing the tags - it's the only input you're actually typing into. There's no separate strength widget because the strength lives in the tag itself: <lora:mylora:0.8> for 80% strength, exactly as the tooltip describes.
Outputs: MODEL and CLIP come back patched with every LoRA found in your string, ready to route into your sampler and encoder as normal. The third output, STRING, is your original text with every <lora:...> tag surgically removed - wire this into CLIP Text Encode, not your original raw string, or you'll end up prompting the model with literal tag syntax it has no idea what to do with.
Installing it: search "ComfyUI-mnemic-nodes" in ComfyUI Manager and install, or the manual route - cd ComfyUI/custom_nodes && git clone https://github.com/MNeMoNiCuZ/ComfyUI-mnemic-nodes - then restart ComfyUI. No models to download, no API keys, no heavy dependencies; it's pure Python string parsing plus ComfyUI's own LoRA-loading machinery underneath, so if your checkpoint loads fine, this node will work fine.
Where it trips people up: the LoRA name in the tag is fuzzy-matched against your installed LoRA files, so a typo or a name that doesn't closely resemble any file on disk just fails to load silently rather than throwing an obvious error - if a LoRA isn't taking effect, check your filename spelling first. Base-model mismatches are the other classic culprit that has nothing to do with this node specifically: a Flux LoRA won't do anything useful loaded against an SDXL checkpoint, and Pony/Illustrious/SDXL LoRAs, despite sharing an architecture, aren't reliably cross-compatible either. And if you forget to route the cleaned STRING output downstream and encode your original text instead, you'll get exactly what you typed - tags and all - baked into your positive conditioning, which is a confusing way to discover the wiring mistake.
Inputs (3)
| Name | Type | Default | Description |
|---|---|---|---|
| MODEL | MODEL | The model (checkpoint) to apply the LoRA to | |
| CLIP | CLIP | The CLIP model being used | |
| STRING | STRING | Input text containing LoRA tags to be processed. Tags should be enclosed in angle brackets, e.g., <lora:loraName:1> |
Outputs (3)
| Name | Type | Description |
|---|---|---|
| MODEL | MODEL | The model output after the LoRA was loaded |
| CLIP | CLIP | The CLIP output after the LoRA was loaded |
| STRING | STRING | The input text cleaned up with the LoRA tags removed |