CMK LoRA Stack Builder

Two text boxes in, a real LORA_STACK out. CMK LoRA Stack Builder parses the familiar <lora:name:strength> syntax into the tuple structure ComfyUI loaders expect, and hands you the stack plus the active LoRA names. It's the dependency-free half of CMK's LoRA story: you can drive LoRAs from a text field without installing a LoRA manager.

Inputs and outputs

• lora_syntax - multiline, default empty. Format: <lora:name:strength> or <lora:name:model_strength:clip_strength>.
• trigger_words - multiline, passed through as-is.
• lora_stack - optional, an incoming stack to extend.

Out: lora_stack (LORA_STACK), trigger_words (the same text, trimmed), active_loras (comma-joined names of what got parsed).

How the parsing behaves

The regex matches <lora:...>, so <lora:myChar_v3:0.8> becomes the triple ("myChar_v3", 0.8, 0.8). The three-argument form gives model and clip strengths separately, which matters more than people expect: turning the clip strength down on a character LoRA while keeping the model strength up is often what stops a LoRA from hijacking your prompt vocabulary.

Robustness details, straight from the source:

• A missing or unparseable model strength falls back to 1.0 instead of throwing.
• A missing clip strength defaults to the model strength - so the two-argument form is not the same as "clip = 1".
• An incoming lora_stack is kept and the text-parsed entries are appended after it. Order changes the result when LoRAs overlap, so "stack first, syntax second" is a rule, not an accident.
• active_loras is the names joined with , , and it's a report, not a filter - the node doesn't verify the files exist.

That last point is the important division of labour: this node deals in names and strengths. Resolving a name to an actual file on disk happens later, in the loader. Point it at a LoRA you don't have and nothing complains until the model load fails.

Why stacking still matters

Identity adapters were supposed to make character LoRAs obsolete and didn't, for reasons the KB's note on the End of LoRas soon? threads spells out: a face is not a character, and LoRAs capture everything around the face too. The mechanical reason is stacking. Compared to newer adapter flavours, plain LoRAs compose - you can pile a likeness, a style and a detail LoRA onto one checkpoint, dial each independently, and the failure mode is a weak image rather than an unloadable model. That composability is exactly what a stack is, and it's why this unglamorous little text parser keeps being load-bearing.

Wiring it

Typical: CMK LoRA Stack Builder → CMK LoRA Text Loader (which actually applies them) or → CMK LoRA SDXL Pack -Pipe- (which bundles the stack for the CMK flow). Trigger words come back out so you can concatenate them into your prompt.

Install

cd ComfyUI
git clone https://github.com/CMKFlow/cmk_nodes.git custom_nodes/cmk_nodes
python3 custom_nodes/cmk_nodes/scripts/install_cmk_requirements.py

Or ComfyUI Manager → CMK Flow (registry cmk-flow) → install → restart. This node is dependency-free - no torch, no models - but it lives in a pack whose requirements (insightface, onnxruntime, ultralytics, segment-anything, nudenet==3.4.2, opencv-python) come along regardless, and only the installer script puts them in the Python environment ComfyUI is actually using.

One counterpart worth knowing: the pack's optional LoRA subgraphs (LoRA Stack · SDXL, LoRA Stack · ZIT, LoRA Stack · Combined) require willmiao's ComfyUI Lora Manager. This node is what you use when you'd rather not install that.