GU Lora Randomizer

GU Lora Randomizer does exactly what the name promises: it loads random LoRAs from a folder, at random strengths, and spits out the patched model and the trigger tags so your prompt can keep up. It's the node for "surprise me" explorations - style roulette, character roulette, "I have 40 LoRAs in this folder and no idea which combination I actually like."

The killer feature isn't the randomness. It's that the node knows each LoRA's trigger words and hands them to you, so the random pick doesn't break your prompt.

How it works

• model and clip - the incoming model pair from your checkpoint loader.
• lora_subfolder - pick a subfolder inside your LoRA directory. Only that exact folder is scanned; child subfolders are ignored, so organize accordingly.
• loras_max - how many to load, 1 to 6 (capped at however many the folder actually holds).
• strength_min / strength_max, clip_min / clip_max - LoRA and CLIP strength ranges, both −100 to 100 (in practice you live around 0–1). A range of 1.0 to 1.0 means "always 1.0"; widen it to get variety.
• pos_prompt and append_tags - pass in your base positive prompt, and optionally have the chosen LoRAs' trigger tags appended to its tail.

Outputs: the patched model and clip, plus lora_tags (trigger words for everything loaded), lora_list (a formatted string like <lora:name:0.8:1.0> for each - great for filename suffixes or info files), and ready_prompt (your base prompt plus the appended tags, if you asked for that).

Where the tags come from - the mechanism worth knowing

Each LoRA file gets hashed (SHA-256, cached by file modification time so it doesn't re-hash every run), and the hash is looked up against Civitai's by-hash API to pull the model's trainedWords. If Civitai doesn't know the file, it falls back to tags embedded in the LoRA metadata itself. Two practical consequences: this node makes network calls to Civitai, so tag lookup silently degrades to embedded-tags-only if you're offline; and a LoRA that exists nowhere on Civitai and carries no embedded tags contributes empty tags. The random selection itself uses unique sampling - no duplicate LoRAs in one roll - and weights are drawn uniformly from your ranges.

The node always executes when the Queue runs (the NaN IS_CHANGED trick), because a randomizer that cached its previous result would be useless. That also means each Queue press re-rolls - press Run to get a new combination, every time.

Install

ComfyUI Manager → search "GU Nodepack" → install → restart, or:

cd ComfyUI/custom_nodes
git clone https://github.com/alexguryev/ComfyUI-GU_Nodepack
cd ComfyUI-GU_Nodepack
pip install -r requirements.txt

No model downloads - the pack reads your existing models/loras. Deps: psutil, requests, gu-funclib>=1.9.0. Windows-tested, single-user design.

The honest catches

First, the LoRA file list is refreshed when a browser tab connects (via the pack's prestartup_script.py websocket hook) - drop a new LoRA in and refresh the page to see it in the subfolder list. Second, randomness without reproducibility is a workflow hazard: when you hit gold, the seed of your KSampler is not the seed of your LoRA roll, so recreate it by noting the lora_list output before you clear the queue. And third - the LoRA subfolder scanning is shallow by design. The README underlines it: only that folder itself, no children. Nest your LoRAs flat and you'll never wonder why a sub-subfolder never gets picked.