Lora Syntax Processor (Mikey)

Wiring up a LoraLoader node for every single LoRA in a stack gets old fast - one node per LoRA, each with its own model/clip in-and-out sockets to chain correctly. This node collapses that entirely: write your LoRAs directly in a text block using A1111-style tag syntax, and it applies all of them in one pass.

The syntax, straight from the pack's own README

Mikey Nodes introduced this tag format at the top of its documentation, for its Prompt With Style node originally, but it's the same syntax this standalone processor reads: <lora:lora_name> for default weight, or <lora:lora_name:0.8> to specify a weight of 0.8 explicitly. Write as many tags as you want anywhere in the text block and the node finds and applies every one of them.

What it does mechanically

Feed it model, clip, and a text block containing your LoRA tags (default placeholder: <lora:filename:weight>), plus a seed - and it scans the text for every <lora:...> tag, loads and applies each matching LoRA to both the model and the CLIP, strips the tags back out of the text, and hands everything back. You get four outputs: the patched model, the patched clip, the cleaned text (with the LoRA tags removed, ready for a CLIP Text Encode node), and unprocessed_text - the original input, untouched, useful for logging or debugging what you actually typed before the node modified anything.

This is functionally the text-syntax equivalent of what rgthree's Power Lora Loader does with a stacked-node UI: both let you apply multiple LoRAs without daisy-chaining a separate loader node for each one. The difference is purely interface - rgthree gives you a visual stack with toggles, this node gives you a single text field where you can type (or paste, or generate via an LLM node) the whole stack at once.

The inputs that matter

• model, clip - your base checkpoint's outputs, same as you'd feed any LoraLoader.
• text - where your <lora:...> tags live, alongside whatever regular prompt text you want. Only the tags get parsed and stripped; the rest of the text passes through into the cleaned output.
• seed - likely relevant if any of the LoRA tags you use resolve through a wildcard or random-selection mechanism elsewhere in your text; for a plain fixed LoRA tag it shouldn't change anything.

A trigger-word reminder worth keeping in mind

Many LoRAs need a specific trigger word in the prompt to actually activate their trained concept - it's a standing item on the community's LoRA-not-working checklist, alongside base-model mismatch and weight set too high. This node handles the <lora:> syntax and weight application for you, but it doesn't know or add trigger words automatically - those still need to be typed into your prompt text separately, same as always.

Installing

Bundled with the full pack. ComfyUI Manager: search "Mikey Nodes," install, restart. Manual: cd ComfyUI/custom_nodes && git clone https://github.com/bash-j/mikey_nodes, restart ComfyUI. No extra downloads beyond the LoRA files themselves, which need to sit in your normal ComfyUI/models/loras folder for the tag names to resolve.

Where it goes wrong

• Typo in the LoRA filename inside the tag. The tag has to match the actual filename in your loras folder (usually without the extension); a mismatch typically fails silently or throws an error depending on the pack's error handling - double-check the exact filename if a tag doesn't seem to be applying.
• Weight set too aggressively. Same rule as any LoRA loader: weight 1.0 can overpower the base prompt for some LoRAs, especially style LoRAs; 0.5-0.8 is the community's usual starting range before dialing up.
• Stacking order mattering more than expected. When stacking several LoRAs in one text block, some users report better results reordering them (larger/stronger LoRAs first) if you're seeing odd artifacts or washed-out results with multiple LoRAs active at once.