LoraName ♾️Mixlab

Notice where this one lives in the node menu: Mixlab/Experiment. That's not a throwaway category - it's the author's own signal that this node is less polished and more likely to change than the flagship stuff, so go in with slightly lower expectations than you would for, say, PromptSlide.

What it actually does is straightforward once you see the pattern. Normally, comparing five different LoRAs means swapping the LoRA name in a LoraLoader node five separate times and running five separate queues - tedious, and easy to lose track of which output came from which LoRA. LoraName flips that: you type your LoRA filenames into a single multiline text box, one per line, and the node turns that block of text into a list you can feed into a loop or batch-comparison setup, so one queue run touches all of them. It's the same pattern the README shows off elsewhere with a sibling node, CkptNames, described as a way to "compare the effects of different models" - LoraName is that idea applied to LoRAs specifically instead of checkpoints.

The inputs and outputs are minimal. lora_names is the one required field: a multiline STRING, empty by default, where you paste your list. Two outputs come back, both lists: lora_names itself (typed as the wildcard *, which is what lets it plug into a LoraLoader-style dropdown-driven input downstream) and a separate prompt output (a STRING list). The node's own schema doesn't spell out exactly what format prompt produces beyond "a list of strings," so don't assume it's auto-generating trigger-word syntax for you - check what actually comes out for your specific LoRA names before wiring it somewhere that expects a particular format, and treat it as a convenience output to inspect rather than something to trust blind.

One thing worth knowing before you build a comparison workflow around this: LoRA weight matters as much as which LoRA you pick. A LoRA's default strength of 1.0 is often too strong, and 0.5–0.8 is the more common sweet spot in practice - so if you're batch-comparing LoRAs through this node and getting overcooked results across the board, that's more likely a weight problem than a LoRA-quality problem. Also worth remembering: LoRAs are tied to their base checkpoint architecture. A LoRA trained for one checkpoint family won't behave the same - or work at all - on a different one, so a batch list mixing LoRAs meant for different base models isn't a fair comparison to begin with.

Install is the same across the whole pack. Through ComfyUI Manager: search "comfyui-mixlab-nodes," install, restart. Manually:

cd ComfyUI/custom_nodes
git clone https://github.com/shadowcz007/comfyui-mixlab-nodes.git
cd comfyui-mixlab-nodes
install.bat

or pip3 install -r requirements.txt in a venv, or the embedded-python pip call on a portable build. No model download needed for this node specifically - it just manipulates text into a list, so if it's not showing up after install, that's a pack-wide load issue (check the ComfyUI console for an import error), not something this node does on its own.