Conditional LoRA Applier (World Weaver)

World Weaver is a text-first character system, but even its author admits you'll want LoRAs for some things - clothing, a style, a creature. This node is the part that decides which LoRA to apply, and it does it by reading your prompt. Type a rule that says "keywords: path, strength" and it routes the right adapter into the model automatically. If you run several characters or several scenes through one workflow, this is what keeps the wrong LoRA from leaking into the wrong image.

Honestly, it's the most reusable node in the pack. You don't need any of World Weaver's character philosophy to get value out of a prompt-driven LoRA router - it works in any Flux or SDXL graph that wants one workflow to behave differently depending on what it's asked to draw.

How it works

You pass in your model and clip (it returns a modified MODEL and CLIP, so it slots exactly where a LoraLoader would go), plus the prompt you're about to encode. Then you write rules in lora_definitions, one per line, in this format:

keyword_phrase_1, keyword_phrase_2 : lora/path/relative/to/loras, model_strength, clip_strength

The parsing is simple and predictable. If any of the comma-separated keyword phrases appears in the prompt, that LoRA gets applied. Strengths are optional - leave them out and both default to 1.0, or trim clip strength if the LoRA is model-only. Rules starting with # are comments; lines without a colon are skipped with a console warning. Paths are relative to your loras folder, use forward slashes, and the pack scans subfolders recursively, so Flux/Details/amateur_photo_v1.safetensors works.

Two controls tune the matching. case_sensitive (default off) is self-explanatory - leave it off unless your keywords genuinely collide with common words. And there's the fallback: default_lora_name, default_lora_strength, default_clip_strength. When no rule matches, the default LoRA (if you picked one) is applied instead. That's the behavior worth understanding: it's if/else, not and. Matched rules win, no match falls back, and if nothing at all fires you get your original model back unchanged. The dropdown for default_lora_name is built by scanning your whole loras directory at load time.

Installing it

Standard pack install - ComfyUI Manager, search "world weaver", install, restart. Or the manual route:

cd ComfyUI/custom_nodes
git clone https://github.com/Creepybits/World_weaver

Restart and let it install its pip requirements (google-genai, opencv-python, numpy, requests, sounddevice - the usual crowd). No models to download; this node needs your existing LoRA collection.

Where people get burned

• Paths are relative to your loras folder. If a rule points at a file that doesn't exist, the node prints a warning and skips it - your image still generates, just without that LoRA. Silent-ish failure, so read the console.
• Rule format errors are warnings, not crashes. A missing colon, a bad strength, a typo - all logged, all skipped. When a LoRA mysteriously doesn't show up, look at the terminal output before you blame the sampler.
• The "any keyword" logic can surprise you. Two characters with overlapping descriptions can both match a rule. Keep keywords specific enough that they can't accidentally collide.
• Strengths are capped at ±2.0. Fine for normal use, but don't expect to crank a LoRA to 3.0 here.
• Restart after adding LoRAs if you want them in the default_lora_name dropdown - like most pack dropdowns, it's populated at startup.

One thing to know going in: this is a text-keyword matcher, so it's only as smart as your rules. It can't see the image, only the prompt. That's fine for the workflow it's built for - where the prompt is itself the character "DNA" - but don't expect semantic understanding. If a keyword's a substring of a word it didn't intend, case_sensitive off just means it matches harder.