Load Condition From Loras

Of the three nodes in this pack, this is the one that'll trip you up, because its name oversells it. LoadConditionFromLoras looks like it should load a condition from a LoRA. It doesn't. It's a LoadCondition whose dropdown is populated from your LoRA folder - and the disconnect is exactly where people get burned.

What it actually does

Look at the source and the story is clear: this node lists files from ComfyUI/models/loras to build its dropdown, but when you pick one it goes looking in ComfyUI/models/conditions for a file named after your selection with .ckpt appended. So selecting a LoRA named mylora.safetensors in the dropdown makes it hunt for mylora.ckpt in the conditions folder. Same load path, same sanitization, same empty-CONDITIONING-on-failure fallback as plain LoadCondition - just a different source for the filename list.

In other words, it's a pairing trick: if you've used SaveCondition to write a condition named to match a LoRA you're also using, this node lets you pick it by the name you recognize. Save a condition called mylora and it shows up in the dropdown alongside your actual LoRA files. Pick it, get the conditioning back.

Inputs and outputs

• filename - one dropdown, listing your LoRA filenames (extensions stripped). Choose the one whose matching condition you saved.
• Output: a single CONDITIONING socket, wiring straight into a KSampler's positive or negative input, or into a conditioning modifier.

That's it. Nothing else to configure.

The trap

If you select a LoRA that has no matching .ckpt saved in models/conditions, the file won't be found, the node prints an error, and it returns an empty conditioning list - which will then break whatever sampler it feeds, not silently render a blank image. The other footgun is mental: it's easy to assume this node is doing something to your LoRA or loading the LoRA itself. It is not. Your mylora.safetensors stays untouched; only a condition you manually saved as mylora gets loaded. No LoRA is ever applied here.

There's also the usual snapshot caveat: the dropdown is generated when the node is created, so a condition you save mid-session won't appear until you refresh the node or reload the workflow.

Should you use it?

Honestly, most people should just use the pack's plain LoadCondition - it gives you a dropdown of exactly the conditions that exist, so you can't pick something that isn't there. LoadConditionFromLoras only earns its keep if you actively maintain the convention of naming saved conditions after LoRAs, so the pairing is visible in one dropdown. If that's your habit, it's a convenience. If it's not, it's a confusing way to get a file-not-found error.

Installation

Same as the rest of the pack - it's all one repo:

cd ComfyUI/custom_nodes
git clone https://github.com/lrzjason/Comfyui-Condition-Utils

Restart ComfyUI, and it appears under conditioning/utils. ComfyUI Manager will also find it as "Comfyui-Condition-Utils". No dependencies, no downloads. Small, quirky, and once you know the pairing trick, occasionally useful.