Conditional LoRA Loader

Here's the problem this node solves: you have a character LoRA, a style LoRA, a wardrobe LoRA, and you're sick of manually wiring the right one in every time you change the prompt. HYBS_ConditionalLoRALoader automates that - you define rules in a TOML file ("when the prompt mentions a red dress, apply this LoRA"), and the node looks at your positive prompt, applies every matching LoRA, and hands you the modified model and CLIP.

It's the LoRA equivalent of prompt-triggered behavior, and it's a genuinely different workflow from stacking LoRAs manually. Where the KB notes that LoRA stacking is "the property people actually buy," this node is the opposite philosophy: conditional application, where each LoRA only joins the stack when its trigger phrase shows up.

How it works

Inputs are the usual model and clip, plus two that do the thinking:

• positive - your prompt (multiline string). This is matched, not the negative.
• config_toml - a dropdown of .toml files in the pack's config/ folder.

Each TOML holds an array of [[lora]] entries with four fields: trigger (a regex), name (path relative to models/loras), strength_model, and strength_clip. The node runs Python re.search of each trigger against the positive prompt; every entry that matches is applied, in file order, on top of the previous one. Outputs are model, clip, and applied loras - a space-separated string of <lora:name:strength:strength> tokens for everything that fired.

Here's the config shape, straight from the pack's example:

[[lora]]
trigger = "(?i)red\\s+dress"
name = "characters/wardrobe/red_dress_lora.safetensors"
strength_model = 1.0
strength_clip  = 1.0

Note the double backslashes - this is the trap. In TOML, \s inside a string needs to be written \\s, or the file won't parse and the node falls back to pass-through. The example config in config/lora_condition.toml.example shows regexes for alternation (nurse|white coat), whole-word matches (\bwizard\b), and even negative lookahead (short hair but not short hair cut).

A few design details worth knowing: the node's execution fingerprint includes the TOML file's modification time, so editing the config re-triggers the node on the next run. If no LoRA matches, the model and CLIP pass through untouched and applied loras is empty. And the toml package in the pack's requirements.txt is exactly for this node - Python 3.11+ uses the built-in tomllib, but on older Python the node falls back to the pip-installed toml.

Installation

cd path/to/ComfyUI/custom_nodes
git clone https://github.com/hybskgks28275/ComfyUI-hybs-nodes.git
pip install -r ComfyUI-hybs-nodes/requirements.txt

Or "ComfyUI-hybs-nodes" in ComfyUI Manager, restart, and you're done. The toml dependency is the only pip requirement, and it's small.

Where this shines: one workflow that serves many prompts, character-wardrobe systems where the prompt itself decides the outfit, or any pipeline where the LoRA must be a function of the text rather than a manual choice. It's niche - if you swap LoRAs once per workflow, skip it. But if you've ever caught yourself loading the same LoRA in four subgraphs, this is the automation you were rebuilding by hand.