A LoRA is a patch for a compatible base model—not a miniature checkpoint and not a style percentage slider. Prove the checkpoint first, let Forge insert the adapter tag, then compare the same seed with one controlled change.
Evidence boundary: product behavior is tied to original Forge commit dfdcbab. No GPU generation was performed for this review; your exact checkpoint, adapter and hardware outcome remains UNKNOWN until the controlled test passes.
Choose the earliest failure. Folder, activation, compatibility and visual effect are separate acceptance gates.
Record the LoRA publisher page, declared base family, exact file, trigger text and suggested starting weight. Generate the checkpoint alone first; only then place and activate the adapter.
Confirm the installation that is actually running, its effective --lora-dir, the exact models/Lora capitalization, a supported suffix and a completed download. Refresh the LoRA inventory.
Use the card to insert the exact alias, add any publisher trigger text, keep one compatible checkpoint and inspect the console. Compare the same seed with the tag absent and present.
At the inspected commit, more than 12 unmatched keys causes Forge to print “LoRA version mismatch” and return without applying that adapter. A smaller unmatched set is logged and processing continues.
The weight is a patch multiplier, not a calibrated percentage of style. Return to one adapter, one fixed seed and the publisher starting point; only add another adapter after each passes alone.
A marketplace category or .safetensors suffix cannot identify the target architecture, trigger recipe or rights by itself.
SD 1.x, SDXL, FLUX or another explicit architecture
publisher page, direct file URL, version, bytes and hash
card alias plus any documented trigger words
publisher weight, checkpoint and required generation settings
adapter, source images, training data and output terms
commit, loader line, fixed-seed A/B result
| Loaded base | Adapter requirement | Do not assume |
|---|---|---|
| SD 1.x / 1.5 | An adapter explicitly trained for the same SD 1.x family and intended checkpoint lineage. | Do not pair it with SDXL or FLUX because the container suffix matches. |
| SDXL | An SDXL adapter; derivatives such as Pony may require their own documented ecosystem and trigger conventions. | “SDXL-shaped” is not proof that every SDXL derivative combination is useful. |
| FLUX | An adapter documented for the exact FLUX base or variant. | Use the dedicated FLUX LoRA guide for low-bit application and patch-time behavior. |
| Unknown / unlabeled | No compatibility claim can be verified from the filename alone. | Return to the artifact page or treat the combination as an explicit experiment. |
VERIFIED Forge can detect some family metadata, but the current UI can show all networks and can classify a file as Unknown. Treat the publisher’s exact base declaration as the contract. Inspect detection code ↗
Keep optional features off until the LoRA has passed. Every extra adapter or extension adds another plausible cause.
Keep the publisher page and direct download URL. Record the stated base family, version, trigger text, suggested starting weight and license before the page changes.
Select the matching Forge preset and checkpoint. Generate one clean image with no LoRA, embedding, ControlNet, Hires fix or unrelated extension.
Use the active models/Lora directory or the path supplied by --lora-dir. The inspected inventory recursively accepts .pt, .ckpt and .safetensors.
Open Extra Networks → Lora and use its Refresh control. Restart only after the active path, suffix, permissions and completed download are confirmed.
Click the LoRA card so Forge inserts its filename or metadata alias. This avoids guessing which name the loader resolves.
Some adapters require trigger words or phrases. A trigger steers conditioning; it does not load the file or repair incompatible tensor keys.
Keep the explicit <lora:alias:weight> value. Do not translate 0.5 into a guaranteed “50% visual effect”; test it as a multiplier.
Fix checkpoint, prompt, seed, size, sampler, scheduler, steps and every optional feature. Save both images, infotext and the first LoRA console lines.
The inventory is recursive and alias-aware. Confirm its actual root before copying the same file into several installations.
[Forge]/models/Lora--lora-dir "D:\Models\Lora"On Linux, Lora, lora and Loras are different paths. Read the launch line instead of guessing.
The useful range belongs to the exact adapter, base and prompt. Change only the final number until one adapter behaves predictably.
<lora:alias:0.8>The inspected activation path applies one value to text-encoder and model targets by default.
Rank, alpha, trained targets, captions, trigger text and checkpoint behavior shape the visible result.
Save the clean fixed-seed result.
Prove load and intended effect.
Repeat before combining.
Add one tag; compare again.
FLUX BOUNDARY Low-bit bases add patching versus on-the-fly precision behavior. Keep that separate from this generic workflow. Open the FLUX LoRA guide →
Console wording matters. Save the complete LoRA sequence rather than reporting only “it did not work.”
The inspected original Forge commit registers a built-in Lora Extra Networks page. Confirm you are running the original repository and that its built-in sd_forge_lora extension loaded. A missing tab is an installation or extension-loading problem, not a file compatibility result.
Create the directory under the active Forge model root, preserving the capital L used by the standalone default. First confirm --data-dir, --models-dir and --lora-dir did not move the effective root.
Verify the running installation, effective --lora-dir, completed filename, .pt/.ckpt/.safetensors suffix, permissions and hidden-directory settings. Then use the Lora page Refresh control.
Each inventory has its own path. The current --forge-ref-a1111-home helper maps an existing A1111 models/lora directory only when that path exists, and an explicit --lora-dir takes precedence.
Do not trust visibility as compatibility. The current setting can show all networks, metadata can be missing, and family detection is heuristic. Verify the publisher-declared base before generating.
Forge can prefer the alias stored in file metadata. Use the inserted tag, or change the “When adding to prompt, refer to Lora by” setting to Filename. Keep basenames unique to avoid ambiguous inventory entries.
Confirm the tag is in the active prompt, the alias resolves, the documented trigger is present and the base family matches. Then inspect the console for Loaded, version mismatch, unmatched or skipped-key lines.
At the inspected commit, more than 12 state-dict keys remain unmatched after Forge tries model and text-encoder mappings, so it returns the unchanged model and clip for that adapter. The wording is a code threshold, not a complete semantic version diagnosis.
Twelve or fewer keys remained unmatched and Forge continued. Preserve the list: the message proves an imperfect mapping, while the fixed-seed A/B test determines whether the intended effect survived.
More than 12 patches for that component were skipped. The other component may still have a different outcome, so do not reduce this to “loaded” or “failed” without the complete console sequence.
Return to the publisher starting point and lower only the LoRA multiplier while holding the seed and every other setting fixed. If the base is FLUX low-bit, continue in the dedicated FLUX LoRA diagnostic.
Remove the stack and reproduce each adapter separately. Then add them one at a time in a recorded order; target overlap, triggers and weights can interact even when both files load.
The current patch identity contains filename, model strength, text-encoder strength and application mode. A different multiplier creates a different compiled target and must refresh the patched model state.
Use the card-generated alias and enable the optional console or Gradio “Lora not found” warning. Manual spelling, duplicate aliases and stale inventory state are separate from architecture compatibility.
[LORA] Loading … with unmatched keys […]Smaller unmatched set; inspect later component lines and output.
[LORA] Loaded … with N keys at weight W (skipped S keys)Loader evidence; visual intent still needs A/B proof.
[LORA] LoRA version mismatch for …More than 12 unmatched keys at the inspected commit.
“The card appeared” and “the image looked different” are weak evidence without artifact identity, fixed settings and console mapping.
Tag and trigger absent. Save image, infotext and console.
Exact tag and trigger added; every other input identical.
Use another seed or prompt to confirm the learned effect.
External tutorials supplied user language and failure questions. Original Forge code controls every product-behavior claim.
Paths, suffixes, recursion, prompt parsing, aliases, metadata heuristics, mismatch thresholds, hashes and console lines.
Empty tabs, cross-family confusion, stale shared paths and misleading mismatch wording are reports—not universal causes.
Visual effect, useful weight, stack behavior, performance and hardware stability remain open until your receipt passes.
Standalone models/Lora default and --lora-dir override.
↗Suffixes, recursive scan, mapping thresholds, caching and console outcomes.
↗Alias and SD1/SD2/SDXL/FLUX family heuristics.
↗Refresh, inserted alias, preferred weight and activation text.
↗TE/UNet multipliers and LoRA hashes in infotext.
↗Visibility, naming, warning and metadata options.
↗Prompt-tag grammar and named/positional arguments.
↗Subfolder, hidden-directory and suffix behavior.
↗Conditional models/lora mapping and explicit-argument precedence.
↗Report contract and low-bit behavior; generic page defers detailed FLUX settings.
↗Real cross-family confusion and the accepted matching-family answer.
↗Why the current threshold wording is not a complete semantic version system.
↗Shared checkpoint success does not prove the LoRA path.
↗Linux path and --lora-dir discovery symptom.
↗Visible incompatible cards and heuristic-filter limitation.
↗Recent missing-tab symptom after a drive move; reported reinstall is not generalized.
↗LoRA path and low-bit questions; dated recipe values excluded from generic rules.
↗Folder and card workflow; hardware conclusions not generalized.
↗Subfolders, card tag and user family confusion; “percentage style” claim corrected against code.
↗Fresh-install model/LoRA placement language.
↗Family filtering, triggers, Refresh and A/B vocabulary; settings remain dated.
↗Beginner LoRA purpose, publisher recipe and card activation flow.
↗dfdcbabUse these answers after the route above; each keeps file discovery, loader mapping and visual proof separate.
A LoRA is a smaller set of learned patches applied to a compatible base model and, when present, its text encoder. It modifies a working checkpoint; it is not a standalone image generator.
The standalone default at the inspected commit is models/Lora. A --lora-dir launch argument replaces that inventory root, and the scanner searches its subfolders recursively.
The inspected original Forge LoRA inventory scans .pt, .ckpt and .safetensors. A recognized suffix proves discovery eligibility, not architecture compatibility.
Yes. The current file walker is recursive. Use family-oriented subfolders if useful, but keep unique basenames and preserve the actual active --lora-dir root.
Check the active installation, effective --lora-dir, models/Lora capitalization, completed supported filename, permissions and hidden-folder state, then Refresh the Lora Extra Networks page.
Usually start with the Lora page Refresh action, which rebuilds the available-network list. Restart after discovery checks fail or when you changed the configured root.
Click its Lora card to insert <lora:alias:weight> into the active prompt, add any publisher-documented trigger words, then generate with a compatible checkpoint.
The normal explicit form is <lora:alias:weight>. The current parser also supports separate text-encoder and model multipliers, but advanced syntax cannot fix a wrong family or unsupported export.
Forge may use an alias stored in safetensors metadata or the filename according to settings. The card inserts the name the current inventory expects and can append saved activation text.
No. Use trigger text only when the publisher or training documentation specifies it. The trigger affects conditioning; the <lora:…> tag is what requests the adapter file.
Start with the exact value documented for that adapter and base. Change one value at a time with a fixed seed; there is no source-supported universal best weight.
No. Forge passes 0.5 as a patch multiplier. The visual effect is not calibrated linearly because training rank, alpha, targets, captions, triggers and the base model all matter.
No. LoRA weight scales adapter patches. Denoising strength controls how far img2img or a Hires pass can depart from its input latent.
Yes. In the inspected parser, one value applies to both by default; additional positional or named te/unet values can separate them. Treat that as an advanced experiment, not a first-line compatibility repair.
No reliable compatibility should be assumed. Match the adapter to the publisher-declared base family; shared .safetensors packaging does not align tensor targets.
No. FLUX uses a different model architecture and target map. Use an adapter explicitly published for the exact FLUX route and follow the dedicated FLUX LoRA guide.
Pony is derived from SDXL, but useful compatibility, prompting and trigger conventions can be ecosystem-specific. Follow the adapter publisher’s declared base rather than assuming every SDXL combination.
The current UI can be configured to show all networks, and family detection depends on metadata plus heuristics. A visible card is an inventory result, not approval for the selected checkpoint.
At inspected commit dfdcbab, Forge prints it when more than 12 keys remain unmatched after mapping attempts and returns without applying that adapter. Preserve the exact file and console for reporting.
No. Twelve or fewer unmatched keys produce a warning and loading continues; later component-level skipped-key checks can still matter. Use the complete console sequence and controlled output comparison.
Look for a console line beginning [LORA] Loaded that names the file, component, loaded-key count, weight, skipped count and application mode. Then require a fixed-seed visual effect.
Common boundaries are an unresolved alias, missing trigger text, wrong base family, unsupported key layout, too-subtle multiplier or a prompt that hides the learned concept. Test one adapter with a fixed A/B job and read the loader lines.
Lower only the adapter multiplier from the publisher baseline and repeat the same seed. Do not simultaneously change CFG, sampler, steps, denoising, VAE or checkpoint.
Yes as an experiment, but first prove every adapter alone. Add one at a time, record tag order and weights, and watch console, memory and output for interactions.
The current compiled target identity includes the file, model weight, text-encoder weight and online mode. A changed weight therefore changes the patch set.
The current built-in extension can add LoRA names and short hashes to infotext. Keep that enabled and retain the source URL plus full file hash for a stronger reproduction record.
The official --forge-ref-a1111-home helper maps an existing A1111 models/lora path. You can also set --lora-dir explicitly; confirm the launch line because checkpoint sharing does not prove LoRA sharing.
Include original Forge commit, launch arguments, adapter page and direct URL, file hash, base checkpoint and hash, exact tag/triggers, all generation settings, full console mapping and a fixed-seed A/B pair.