LoRA Load ⚡

LoRA Load (display name "LoRA Load ⚡") is FEnodes' take on the multi-LoRA loader, and if you've used rgthree's Power Lora Loader you already know the shape of it: one node, a custom browser UI, add as many LoRAs as you like, toggle each on and off, and dial strengths per row. The difference here is it ships inside a pack aimed at VFX video pipelines, it's wired to a dedicated apply node, and it does a couple of clever things under the hood that the simpler loaders don't bother with.

If you only ever load one LoRA at a time, this node is overkill. If you're stacking a style LoRA, a character LoRA and a quality LoRA and tuning them against each other, having all the sliders and toggles in one place beats chaining six LoraLoader nodes down the line - the stack is also dramatically easier to turn on and off for A/B comparison.

How it works

The node itself has essentially no Python-side inputs - there's a hidden loras_json STRING widget, and a custom JavaScript widget (from the pack's web/js/fe_power_lora.js) does the real work. It renders a searchable folder-tree browser of your models/loras directory, and every time you add a row, toggle it, or move a slider, it serialises the whole list - enabled, file path, strength_model, strength_clip - back into that JSON widget. Nothing happens at the graph level until you hit Run.

The interesting internals are in the caching. FEnodes computes a SHA-256 of each LoRA file, but it only re-hashes when the file's mtime changes, so a big LoRA isn't re-read on every graph evaluation - that's what keeps IS_CHANGED cheap. The loaded weights are cached at module level, so if the same LoRA appears in two tile streams or two nodes, the file is read from disk once, not twice. There's also a CivitAI lookup keyed off that SHA-256: it fetches the model name, base model, trained trigger words, and preview images, and caches the result in a .fe-info.json sidecar next to the LoRA. That's the same trick that makes rgthree's Power Lora Loader popular - you never lose the trigger words when a model page vanishes.

The input and output that matter

Honestly, there's one of each.

• loras_json - hidden STRING, the serialised stack from the JS widget. You don't set this by hand; the browser UI does.
• lora_stack (output, type FE_LORA_STACK) - a list of {enabled, path, strength_model, strength_clip} entries. This is a custom type, so it only plugs into the pack's own Apply LoRA ⚡ node (or LoRA Trigger Analysis 🔍). It won't feed a stock LoraLoader.

One tip from the UI: right-click the node for a "separate CLIP strength" toggle. When it's off, the CLIP strength mirrors the model strength automatically - which is what you want for most LoRAs. Flip it on and you get an independent CLIP slider per row, useful when a LoRA was trained with a strong text-encoder component and you want to turn that down without weakening the model influence.

Installing it

The whole pack installs the same way - ComfyUI Manager (search "ComfyUI-FEnodes"), or:

cd ComfyUI/custom_nodes
git clone https://github.com/FugitiveExpert01/ComfyUI-FEnodes.git

Then restart ComfyUI. No extra Python dependencies for this node; it runs on what ComfyUI already has. Note this is a young, niche pack (Apache 2.0, VFX-flavoured) - if you care about the trigger-word lookup working, you need network access to CivitAI from the machine running ComfyUI.

Common issues

• The custom UI doesn't show. The folder-tree browser is a JS widget, so if you have the legacy canvas or a very old ComfyUI build, custom widgets can fail to render. Updating ComfyUI usually fixes it.
• CivitAI lookup returns nothing. Either the LoRA is offline-only (not uploaded to CivitAI), the network is blocked, or the SHA-256 has no match on the site. The node still works fine for loading - the lookup is a convenience, not a requirement.
• No lora_stack output that fits anything. Remember the custom type. If your workflow expects a stock LoRA input, this loader won't connect - it's built to pair with FEApplyLora.