LoRA Apply (MRLN)

Normal LoRA loading in ComfyUI is "pick a file, set a strength." LoRA Apply (MRLN) is a different shape: it loads the LoRAs a Prompt Template node drew, at the strengths the item author set, and it sits in the graph where a LoRA loader would. The trigger words stay in the prompt - they were written into the library item - and the loading stays out of it. If no LoRA blocks were drawn, model and clip pass through unchanged, so it's safe to have permanently wired into a workflow.

The reason you'd reach for it over the core LoraLoader is the part that loads intelligently. ComfyUI will happily apply a FLUX LoRA to an SDXL checkpoint, and it errors nowhere - the image just quietly degrades. That silent degradation is the failure mode this node exists to catch, and it's worth wiring this node into the graph for that alone.

How it works

The loras input is a JSON list of blocks - {lora, strength_model, strength_clip, air, base} - produced by the Prompt Template's loras output. LoRA Apply parses that, looks each file up in your loras folder, and applies them in order through the same loader core ComfyUI uses, one model/clip pair out the other side. Two safety nets ride along:

• on_mismatch - reads the connected model's architecture, compares it to the base family the LoRA item declares, and warns / skips / errors / ignores when they disagree. Default is warn, which logs and applies anyway. Only items that declare a family (via data.base or the ecosystem segment of their Civitai AIR) can be checked - anything un-mapped skips the check rather than crying wolf.
• on_missing - what to do when a drawn LoRA file isn't on this machine. error (the default) stops the run and names the file; skip renders without it (trigger words stay in the prompt, so the image just loses that LoRA's influence); download fetches it from Civitai by the item's AIR urn, SHA256-verified, and blocks the run for the download duration. download is the one you want for shared workflows that should heal themselves.

The inputs and outputs that matter

Required: model, clip, and loras (the Prompt Template's loras output, which is force-input so you can't leave it dangling). Optional: on_missing and on_mismatch, both with sensible defaults - leave them alone until you hit the situation.

Outputs: model and clip with every drawn LoRA applied at authored strengths, and report - a plain string of what actually happened, line by line: each LoRA applied with its strengths, plus any mismatch, missing file, skip or download. Wire report into a Show Text node and you can see the whole stack in the graph, which is the honest way to confirm a LoRA didn't silently fail.

How to install it

Same pack as the other MRLN nodes, and ComfyUI Manager can't find it yet - the registry flagged v0.1.1 on six severity: info pattern matches, so it's absent from Manager's search. That's a review hiccup, not a broken node. Manual install works today:

cd ComfyUI/custom_nodes
git clone https://github.com/master-merlin/comfyui-mrln-nodes ComfyUI-MRLN-Nodes

Restart ComfyUI. No extra Python dependencies - requirements.txt is deliberately empty, and the Civitai download path only activates when you use it.

Common issues

• LoRA 'x' not found in your loras folder - the file genuinely isn't there, and the error names it. Install it, or set on_missing to download if the item carries an AIR.
• ⚠ MISMATCH in the report - you're applying a LoRA to the wrong base family. warn applies it anyway; flip to skip or error if you'd rather it never touch that model.
• The queue hangs - on_missing: download blocks the run while it fetches. That's by design; it's the cost of a self-healing shared workflow.

The one honest caveat: this node is only useful when the LoRA stack comes from the library's drawn output. If you hand-pick LoRAs per render, the core LoraLoader is simpler. The payoff here is workflows that reproduce - same seed, same library, same LoRA stack, every time.