LoRA Lab · Identity / Baseline Loader

Every LoRA comparison has a dirty secret: most of them aren't comparisons at all. People eyeball a few lucky generations, forget what the base model does on its own, and credit the LoRA for something the checkpoint was going to do anyway. This node exists to stop that. LoRALabIdentityLoader is the internal adapter that ComfyUI-LoRA-Lens' dashboard uses to give every test run a control - a row generated with the exact same prompt, seed, resolution, and sampler, but no LoRA applied. It's the "so what did the base model give us" node, and it's why the whole pack works.

You'll rarely add it by hand. The LoRA Lab dashboard injects it into the workflow it builds for each run. But you'll hit it in two places where it matters: the dashboard's Import any API workflow path explicitly tells you to replace your candidate LoRA loader with this node, and if an imported workflow is rejected, the pack's troubleshooting names it - an imported graph must contain at least one LoRALabIdentityLoader.

How it works. Two behaviors, both boring on purpose. Pick __LORALAB_BASELINE__ in lora_name (or set strength_model to 0) and the node returns your model completely untouched - a true no-LoRA passthrough, not a zero-strength patch that still touches weights. Otherwise it loads the .safetensors from ComfyUI/models/loras and applies it model-only via comfy.sd.load_lora_for_models(model, None, ...). That None is the CLIP slot, and it's deliberately empty: no text-encoder patch. Modern identity LoRAs on Krea 2, Z-Image, and FLUX are trained that way (the KB's lora-training.md notes text-encoder training basically died with the post-Flux architectures), so "model-only" is a feature, not a limitation.

The loader caches by file path and modification time, so re-running a test doesn't reload a multi-hundred-MB file from disk every time.

Inputs that matter:

• lora_name - a dropdown of the baseline plus every LoRA found in models/loras. (If you ever see just __LORALAB_BASELINE__ in the list, you have no LoRAs in the folder - the enum is scanned live.)
• strength_model - default 1.0, range −4 to 4. Negative values invert the LoRA's influence, which is occasionally useful for diagnosing what it's adding.
• model - your checkpoint's model, straight in.

Output: a single model, wired onward to your sampler chain. That's it.

Installation. It ships in the ComfyUI-LoRA-Lens pack. ComfyUI Manager (search "ComfyUI LoRA Lens"), or:

cd ComfyUI/custom_nodes
git clone https://github.com/astropuzzo/ComfyUI-LoRA-Lens.git

Then install the requirements with ComfyUI's Python (this pack's requirements.txt pulls insightface, onnxruntime-gpu, timm, and friends - the heavy, CUDA-sensitive ones), and restart. The first analyser setup downloads several gigabytes of face-recognition weights in the background, non-blocking.

Where people get burned: the lora_name dropdown is a live scan, so a LoRA you just dropped into models/loras may not show up until the node is recreated or ComfyUI restarts. And the pack installs its dependencies into whatever environment you tell it to - pip-install into system Python instead of ComfyUI's venv or python_embeded and you get import errors at startup (the classic custom-node pain documented in the ecosystem KB).