Model Only LoRA Stack

The first thing you notice about the Model Only LoRA Stack is what's missing: there's no CLIP input, and it doesn't want one. That's not an oversight. Since the Flux generation of models, LoRAs are trained with the text encoder frozen - nobody patches a 4–8GB T5/Qwen3 encoder anymore, because there are no text-encoder weights in the file to apply. Stock ComfyUI's LoraLoader still takes a clip socket because that's the SD 1.5/SDXL contract this whole ecosystem grew up on. This node implements the modern contract instead: LoRA weights onto the diffusion model, nothing else, full stop.

That makes it the right default for the architectures people actually run in 2026 - Krea 2, Z-Image, FLUX. On any of those, running a LoRA through a CLIP-patching path is usually a no-op and occasionally quietly harmful. The node's own release thread puts it well: "model-only is the right default for anything with a t5 text encoder... most stack nodes don't even give you the choice."

What it does

It's a dynamic LoRA stack. You get a + Add LoRA button, per-row enable/disable toggles, a strength slider per row, up/down reordering, and a searchable LoRA browser that shows previews and trigger text in a separate panel. Rows apply sequentially, top to bottom. Strength runs from -1.00 to 2.00 - 1.0 is full nominal strength, and the negative end genuinely works: run a style LoRA at negative weight to push away from that style. Strength 0.0 keeps the row in the stack but skips applying it.

Under the hood it's honest plumbing: each enabled row calls ComfyUI's load_lora_for_models with the CLIP slot passed as None - the entire "model only" behavior in one argument. Files are cached (it keeps recently loaded LoRAs in memory keyed by file mtime/size), and there's a global stack bypass that hands back your unmodified model plus an empty trigger string.

The inputs and outputs that matter

• model (MODEL) - wire this from your UNETLoader / Load Diffusion Model. It's the only socket you really touch.
• lora_stack_json (STRING) - ignore it. It's the UI's serialized state; the buttons in the node body manage it. Don't hand-edit JSON.

Outputs:

• model (MODEL) - the patched model; goes to your sampler/guider.
• triggers (STRING) - the combined trigger text from every enabled LoRA, duplicates removed case-insensitively. This is the nice part: the node resolves each LoRA's triggers for you, then hands you one clean string. Wire it into the sibling Trigger + Prompt Concat and you never type trigger words again.

Trigger resolution order: a same-name companion .txt file beats safetensors header metadata (including kohya's ss_tag_frequency) beats your manual override. A small indicator shows where each row's text came from - TXT, Metadata, Manual, or None.

Install

No model downloads, no heavy dependencies - the README is explicit that it needs nothing beyond ComfyUI's standard environment. Either:

cd ComfyUI/custom_nodes && git clone https://github.com/orion4d/Orion4D_ModelOnlyLoRA

then restart ComfyUI (and refresh the browser), or search Orion4D_ModelOnlyLoRA in ComfyUI Manager and let it do the same thing. The node lives under Orion4D_Utils → LoRA in the menu. The fancy browser UI is a web extension, and while the pack is tested on ComfyUI Nodes 2.0, the README says the legacy interface works too.

Where people get burned

• Missing preview or trigger text. The companion file must share the exact basename: MyStyle.safetensors pairs with MyStyle.png and MyStyle.txt. MyStyle_preview.png silently does nothing.
• The auto-detected trigger is useless. This is the real gotcha: kohya metadata is frequency-ranked, and the top entry is often the class token rather than your trained word. Trust the source indicator, then edit the row's trigger field - your manual text is saved in the workflow and never modifies the LoRA or its TXT file.
• "LoRA not found" at queue time. The node validates against your loras folder, so a renamed or moved file errors loudly instead of silently no-op'ing. That's a feature.
• It applies but fails on execute. Architecture lock-in is real - a Krea 2 LoRA will happily appear in the list and then refuse to apply to a Z-Image model. Also, if a LoRA genuinely bundles text-encoder weights, they won't be applied here. That's the model-only trade-off, by design.