CMK LoRA SDXL Pack -Pipe-

A three-in, one-out adapter. It takes a LORA_STACK, a string of active LoRA names, and a string of trigger words, and packs them into a single CMK_LORA_SDXL_PIPE - the bundle the CMK loaders expect to see on the LoRA slot of the flow.

The category is the tell: CMK/Internal. This is a glue node for the pack's shipped subgraphs, not a node you're meant to be choosing off a menu. You'll meet it inside LoRA Stack · SDXL and the reference workflows that use it, sitting between the LoRA Manager pieces and the CMK loader.

Inputs and outputs

| | name | type | |---|---|---| | in | lora_stack | LORA_STACK (forced input) | | in | active_loras | STRING (forced input) | | in | trigger_words | STRING (forced input) | | out | LoRA SDXL | CMK_LORA_SDXL_PIPE |

All three inputs are forceInput, so they're sockets rather than typed-in widgets. All three come from wherever your LoRA stack was assembled - typically the pack's CMK LoRA Stack Builder for the syntax side, or a LoRA Manager node if you're using the subgraph that depends on it.

The output is a dict with four keys: family (hardcoded to sdxl), lora_stack, active_loras, and trigger_words. Both strings are stripped; nothing is validated beyond that. The naming and the family tag are the whole product - they let the downstream loader know these are SDXL LoRAs and not, say, Z-Image Turbo ones. The pack ships a ZIT sibling with identical inputs and a different family tag, which is exactly how you'd expect a pipeline that keeps three generation families apart to handle this.

Why a bundle instead of two wires

Three wires into a loader is manageable. The reason this exists is consistency: CMK puts everything a stage needs into one typed object, so a graph can pass "the LoRA configuration" around as a single link instead of three that can be rewired independently and half-broken. It also makes the family explicit in the data rather than in the wire position, which is what stops an SDXL LoRA from being loaded onto a Turbo pass.

The trade is the usual one with bundle-and-pipe designs: when something downstream looks wrong, the wire is always connected and you have to look inside the bundle to find the problem. A stack with an empty active_loras string and a populated stack isn't contradictory - it just means whoever built the stack knew about two LoRAs and reported neither as active.

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

Manager route: CMK Flow (registry cmk-flow, publisher CMKFlow) → install → restart. Manual clone means running the installer yourself; the pack's requirements include insightface, onnxruntime, ultralytics, segment-anything, nudenet==3.4.2 and opencv-python.

One install note specific to LoRAs: the pack's optional LoRA subgraphs (LoRA Stack · SDXL, LoRA Stack · ZIT, LoRA Stack · Combined) require willmiao's ComfyUI Lora Manager. It's the pack's only deliberate custom-node dependency, and the README credits it as the inspiration for CMK's own browser. Without it, everything else in CMK still works - those subgraphs don't.

Do you need to touch it?

Only if you're rebuilding a LoRA subgraph from scratch. If you're using the flow as shipped, this node is already wired and you'll never click on it. If you are building your own, the pattern is: stack builder → this pack node → CMK loader, with trigger words from whatever metadata source you actually have. Note that the loader on the other end may well ignore the trigger words - see CMK LoRA Text Loader, whose trigger-word output is intentionally empty.