Get LoRA Metadata & Keys

LoRA files carry more useful information in their header than most people realize. If it was trained with Kohya's tooling (still one of the dominant trainers, alongside ai-toolkit and OneTrainer), the safetensors metadata frequently includes the ss_* fields - network dim, network alpha, base model, sometimes the dataset config - the exact training vocabulary Kohya put into common use across the whole ecosystem. This node loads a LoRA and hands you both that header and the full list of its internal tensor names, straight up, no interpretation.

What it does

One input, lora_name, a dropdown of whatever LoRAs you have installed. Two string outputs: metadata (the file's header, verbatim, whatever training tool wrote there) and keys (every tensor name in the file). Feed either into a Show Text node to actually read them.

Why this matters more for LoRAs than it might sound like

A LoRA you downloaded with no description, no obvious source, and a filename that tells you nothing is a genuinely common situation on CivitAI and elsewhere. This node is the fastest way to actually find out what it is - network dim and alpha (if the trainer wrote them) tell you the rank it was trained at, which matters if you're about to feed it into LoRAMultiMerge and want to know whether you're combining a rank-16 LoRA with a rank-64 one. The base model field, when present, settles the "will this even work with what I'm running" question before you waste a generation finding out the hard way.

It's also the direct prerequisite for LoRARenameKeys in this same pack - that node needs you to type the exact old key names you want changed, and the only reliable way to get those exactly right is to pull them from here first rather than guessing at a naming convention.

Installing it

ComfyUI Manager: search Model Utility Toolkit, install, restart. Or:

cd ComfyUI/custom_nodes
git clone https://github.com/silveroxides/ComfyUI-ModelUtils

Restart ComfyUI. No downloads needed beyond the LoRA file itself.

Where people get burned

Plenty of LoRAs simply weren't trained with a tool that writes rich metadata, or the metadata was stripped somewhere along the way (repacking, re-uploading, a strip-metadata step in someone's publishing pipeline). An empty or sparse metadata output isn't the node malfunctioning - it means the file genuinely doesn't carry that information, and you're back to inferring rank and target architecture from the keys output and context.

The other thing worth knowing before you go hunting: current-generation LoRAs increasingly aren't plain LoRAs at all. LoKr - a Kronecker-product decomposition from the LyCORIS library - has become the default for character work on post-Flux architectures, and its tensor naming looks different from a standard LoRA's lora_up/lora_down pairs. If the keys output doesn't match what you expected from a "normal" LoRA, check whether you're actually looking at a LoKr or LoHa file before assuming something's wrong with the file itself.