A1111 LoRA Syntax (Umbra Lab)

If you came over from A1111 or Forge, you probably have muscle memory for writing <lora:my_lora:0.8> right inside the prompt. ComfyUI doesn't speak that language - it wants a dedicated LoraLoader node with its own dropdowns and strength sliders. A1111 LoRA Syntax (Umbra Lab) is the translation layer: it parses those tags out of your prompt text, applies the LoRAs to the model and CLIP, strips the tags from the text, and hands you back a cleaned prompt plus the patched model. You get to keep the habit.

How it works

It scans prompt_text for A1111-style tags - <lora:name:model_strength:clip_strength> (the clip strength is optional and defaults to the model strength). For each tag it resolves the LoRA file from your models/loras folder and applies it via ComfyUI's own load_lora_for_models, so this is real LoRA patching, not a stub. Then:

• strip_lora_tags_from_text (default on) - removes the tags from the output prompt_text, so the CLIP encoder never sees them. Turn it off if you want the raw text preserved.
• strict_mode - off by default, which means a missing LoRA file logs a warning and keeps going. Flip it on and a missing LoRA raises an error instead, which is what you want when you're shipping a workflow and need to know immediately if a file's gone.
• positive output - here's a subtle piece worth knowing: if you wire in positive_in (upstream conditioning), it passes that through untouched. That's deliberate - SDXL-style conditioning carries pooled metadata, and replacing it with a fresh encode can leave clip_pooled as None and break the sampler. If you don't wire it, it encodes the cleaned text with the LoRA-patched CLIP, matching ComfyUI's native encode path.

The lora_name, lora_strength_model, and lora_strength_clip widget inputs exist for tooling compatibility, but here's the thing: the tags in the prompt are the source of truth. The node explicitly ignores the widget values in favor of what's written in prompt_text, to avoid stale state. So don't fight it - put the strength in the tag, not the widget.

The inputs that matter

• model, clip - the unpatched model/CLIP from your checkpoint loader.
• prompt_text - your prompt with the <lora:...> tags inline.
• strip_lora_tags_from_text, strict_mode - the two toggles worth touching.

Outputs: model, clip (LoRA-patched), prompt_text (cleaned), positive (conditioning).

Installing it

Part of Umbra-Nodes, the ComfyUI companion pack for Umbra Studio (NocturneLabs' open-source local AI suite). ComfyUI Manager → search "Umbra Nodes", or:

cd ComfyUI/custom_nodes
git clone https://github.com/Nocturne-Ai-Labs/Umbra-Nodes

Restart ComfyUI. No pip deps. You need your LoRAs in ComfyUI/models/loras/ as usual, and the tag's name must match the filename (subfolders are fine).

Gotchas

Tag/name mismatches are the top failure: the tag name must resolve to an actual file, and by default a miss is only a console warning - so check the log if your LoRA "isn't working," or flip strict_mode on. Also, because the node re-encodes conditioning when no positive_in is wired, models with unusual text encoders can misbehave - that's what wiring in your existing positive conditioning is for. And remember this node only understands <lora:...> syntax; if your prompt uses wildcard-style {lora:...} or another syntax, it won't match, which is exactly what strict_mode exists to surface.