Universal LoRA Analyzer

Everyone who's used ComfyUI for more than a few months has a loras folder full of files named things like flux_v3_final_REAL.safetensors with zero memory of what base model they're for or what trigger word makes them work. This node exists for exactly that folder. It doesn't touch your generation pipeline at all - it doesn't even connect to a MODEL or CLIP - it just reads a LoRA file and tells you what it found, as a set of string outputs you can drop into a Preview text node or log somewhere.

Point it at a file with lora_name (a dropdown pulled from your LoRA folder), or override that with manual_path if the file lives somewhere the dropdown doesn't reach - say a subfolder your ComfyUI install isn't indexing, or a file you're testing before organizing it properly. show_training_info (default on) controls whether it surfaces training-specific metadata when the file has it; auto_discover (default off) is worth flipping on if you're not sure the exact filename and want the node to search more broadly rather than requiring an exact dropdown match.

What comes back: model_type and sub_type tell you the architecture family and variant this LoRA was trained against - the single most useful pair of fields here, since loading a LoRA on the wrong base is the number one reason a LoRA "does nothing." base_model names the specific checkpoint it was trained on. trigger_words pulls out whatever activation phrase the file's metadata carries, if it carries one - a huge number of LoRA failures in the wild trace back to a missing trigger word rather than a bad weight or wrong strength, and this is the same instinct behind rgthree's Power Lora Loader shipping a trigger-word lookup as its most-used feature elsewhere in the ecosystem. analysis_result and lora_info give you a fuller human-readable summary and structured detail respectively. civitai_url and hf_url reconstruct links back to the model's likely source page, when the metadata has enough to build one.

That last pair is worth taking seriously rather than treating as a nice-to-have. CivitAI has gone through repeated purges and policy-driven takedowns over the past couple of years - entire categories of models pulled with little notice, sometimes ahead of a platform-side deadline the community only found out about months later. If a LoRA's only surviving trace is the file sitting in your folder, whatever metadata is embedded in it (including a source URL, if the trainer bothered to include one) may genuinely be the only record left of where it came from and what it needed. Running this node once on a file you care about and saving the output somewhere costs nothing and buys you insurance against exactly that.

Note this node has no image, model, or CLIP output - it's read-only inspection, not something that patches your graph. Route the strings anywhere you'd route text: a Preview Any / Show Text node, a log file, or a note you keep alongside your LoRA collection.

Installing it: bundled with the whole pack - through ComfyUI Manager, search "ComfyUI-NunchakuFluxLoraStacker," or:

cd ComfyUI/custom_nodes
git clone https://github.com/ussoewwin/ComfyUI-NunchakuFluxLoraStacker.git

Restart ComfyUI, find it under LoRA Tools.

Where it falls short, honestly: analysis quality depends entirely on what metadata the trainer actually embedded in the file. A LoRA trained and exported with a careless or minimal pipeline may come back with blank or generic fields for trigger_words or base_model - that's a gap in the source file, not a bug in this node, and no analyzer can extract information that was never written into the safetensors header in the first place.