LyCORIS Format Inspector π¬
Before You Load That 'LoRA,' Ask It What It Actually Is
- detected_format
- has_dora
- layer_count
- report
"LoRA" has become the generic word for every adapter file, and that's a problem - because LoRA, LoHa, LoKr, and DoRA are different math. Load a LoHa with plain-LoRA math and you get a technically-running but wrong result. LyCORIS Format Inspector exists to stop you from doing that: it reads a file's actual tensor key names and tells you what format it really is, before you load it with the wrong loader. Think of it as the ID check at the door. Run it on anything you didn't train yourself.
How it works
It reads only the safetensors header - the tensor names, shapes, and dtypes stored as a JSON block at the start of the file - never the weight data itself. That means it's fast and low-memory even on large files, because it never touches the actual weights. Detection is by real key-naming convention:
- LoRA / LoCon -
lora_down.weight/lora_up.weight/alphakeys. - LoHa -
hada_w1_a/hada_w1_b/hada_w2_a/hada_w2_bkeys (Hadamard product). - LoKr -
lokr_w1/lokr_w2, or their factored_a/_bvariants (Kronecker product). - DoRA - a
dora_scalemarker that can appear alongside any of the above.
It reports, per layer prefix found: detected_format (lora, loha, lokr, unknown, or mixed - mixed means the file contains more than one format's keys, unusual but possible for hand-merged files), has_dora (whether any dora_scale key exists), layer_count (how many distinct layers carry adapter weights), and a report with the details.
Inputs and outputs
- lora_name - picked from ComfyUI's
lorasregistry. - detected_format - the headline answer.
- has_dora - a boolean, wireable.
- layer_count - an INT.
- report - the fuller readout.
Why it matters now
Two reasons this is genuinely current, not busywork. First, the format landscape shifted: LoKr is now the default for character adapters on the 2026 bases (the published Z-Image and Flux.2 Klein recipes run LoKr at factor 8), so a "character LoRA" is increasingly a LoKr in disguise. Second, ComfyUI's built-in LyCORIS auto-detection has a documented open issue where these files can be silently routed through the plain-LoRA path. This node puts the format decision in your hands, and it pairs directly with the pack's LoHa/LoKr loaders, which apply the real math for whatever it reports.
Install
No extra dependencies:
cd ComfyUI/custom_nodes
git clone https://github.com/TensorVizion/OmniNodes
Restart, find it under TensorVizion/Model (ComfyUI Manager, search "OmniNodes", also works).
Troubleshooting
- detected_format is
unknown- the keys don't match any known convention. It's either a custom format, a hand-edited file, or something that isn't a LyCORIS-family adapter at all. Don't force it into a loader. - It says
mixed- more than one format's keys in one file. Rare, but real for hand-merged files; treat with suspicion and check the report. - "LoRA not found" - the file must live in
ComfyUI/models/loras/for the registry to see it. - The inspector and the loader disagree - the inspector reads keys, the loader applies math; if they disagree, the file is probably mixed or unusual. The report is the tiebreaker.
It's a five-second sanity check that prevents a whole class of "why does this adapter do nothing / do the wrong thing" mysteries. Run it once, know your file, then load with confidence.
Inputs (1)
| Name | Type | Default | Description |
|---|---|---|---|
| lora_name | COMBO | 0 options: |
Outputs (4)
| Name | Type | Description |
|---|---|---|
| detected_format | STRING | β |
| has_dora | BOOLEAN | β |
| layer_count | INT | β |
| report | STRING | β |