Power LTX LoRA Loader Extra (Deprecated)

If you downloaded a workflow saved before the rename and see Power LTX LoRA Loader Extra (Deprecated) sitting in the graph, you're not missing a node - you're looking at the old name of the Multi LoRA Loader. The pack got renamed, and this node is now a shell that exists so older workflows don't hard-crash on load. It does nothing, on purpose, and the plan is to get your LoRA config out of it and into the new node.

What it actually does now

Nothing. Literally: its execution function is a no-op that returns an empty dict. It's flagged as an output node with a single input, lora_data - a multiline STRING defaulting to [] - and no outputs at all. When you load an old workflow, this node appears with a "Node Renamed" notice and your LoRA configuration sitting in that text box, preserved but inert. It won't apply a single LoRA. The job of the node now is to hold your data in one place long enough for you to migrate it, which the notice spells out.

Why the name made sense, once

"Power" because the pack is built on rgthree's Power Lora Loader concept - the same stacked-LoRAs-with-per-entry-toggles and right-click info dialog idea that made rgthree's node a staple. "LTX" because the pack pioneered per-layer strength control for LTX-2, the Lightricks video model that generates synchronized audio and video in one pass, with separate attention groups for video, video-to-audio, audio, and audio-to-video. And "Extra" because it's phazei's extension of that concept. The rename to "Multi LoRA Loader" happened because the node outgrew the LTX-specific framing - it became a general multi-LoRA manager, and the old name undersold it.

Migrating, step by step

The README's migration path is short and exact:

1. Copy the JSON out of the deprecated node's text box.
2. Add a new Multi LoRA Loader node.
3. Click its cog button (⚙) and paste the data in.
4. If your workflow used LTX layer-specific strengths, enable the LTX checkbox on the new node.
5. Delete the old node.

That's it - the JSON format is shared between the two nodes, so it's a copy-paste migration, not a rebuild. The new node even shows a red strikethrough on any LoRA it can't find on disk, which is a nice bonus check that your paths still resolve.

How to tell if you're stuck

The deprecated node is hidden from the add-node palette - you won't find it when searching for new nodes, and you shouldn't. So if you're still seeing it, it's from one of two places: an old workflow you loaded (migrate as above), or an old install of the pack still on disk. In the second case, update the pack through ComfyUI Manager or re-clone:

cd ComfyUI/custom_nodes
git clone https://github.com/phazei/ComfyUI-MultiLoraLoader

then restart ComfyUI. The pack has no Python dependencies beyond ComfyUI itself, so there's nothing else to chase - this is one of the rare custom node installs with no requirements file at all.

Should you care?

If you're starting fresh, no - you'll never touch this node. But if you're the kind of person who collects shared workflows, you will hit it, and it's worth knowing that a scary-looking "Deprecated" node in a stranger's workflow is a five-step fix, not a missing-model disaster. The data is intact; the node just stopped being a loader. Copy the JSON, paste it into the new one, and move on with your day.