Debugging a LoRA That Won't Render

A LoRA that "does not work" is almost never a corrupt file. It is a config problem, and config problems are debuggable. Here is the systematic pass I run when a character LoRA refuses to show up, treated the way you would treat any bug: isolate one variable, reproduce, compare.

I will use my own case as the repro. I trained a character LoRA (a winter-yokai OC named Yukimai) on PixAI, loaded it, generated, and got a generic anime girl with the wrong hair color. The file was fine. Every failure below was a setting.

TL;DR

• Trigger word missing or irrelevant. Some LoRAs are hard-gated on a trigger, some barely use it. Test both states on a locked seed.
• Weight out of range. Start ~0.7 to 0.8 for a character LoRA. There is no universal value. Sweep it.
• Base model architecture mismatch. The single biggest cause. An SDXL LoRA will not load on a DiT model, full stop. Match the LoRA's base tag to your model.
• Prompt conflict. An explicit positive token can override the LoRA's trained traits and even a negative prompt. Strip the prompt to isolate.
• Wrong mental model. Character LoRA vs style LoRA need different tests and different weights.
• Debug method: change one variable at a time, lock the seed, compare outputs against each other.

The environment

All tests ran online in PixAI, no local setup. Shared negative prompt across runs:

lowres, bad anatomy, bad hands, missing fingers, extra digits,
cropped, worst quality, low quality, jpeg artifacts, watermark, signature

Base model for the character runs: Haruka v2 (SDXL / Illustrious). Character LoRA weight default: 0.8.

1. Trigger word: is it even gating?

A trigger word is the activation phrase baked in at training time. The naive assumption is that without it, the LoRA does nothing. That assumption is only sometimes true.

Repro: same prompt, same locked seed, trigger on vs trigger off.

Result: near-identical images. My LoRA is concept-baked, not trigger-gated, because the training set was tightly consistent. Yours might be the opposite. The point is the test, not the assumption: two generations on a locked seed tell you whether the trigger is part of your bug at all. One caveat specific to PixAI: adding a LoRA often auto-inserts the trigger into your prompt box, so a full prompt rewrite can silently delete it.

2. Weight: sweep, do not guess

Weight scales the LoRA's influence. Too low, the character is faint. Too high, the render overcooks. Repro on a locked seed at 0.3 / 0.7 / 1.2:

Result: stable across the whole band, with only the frost detailing deepening as weight climbed. Note the pose shifts even on a locked seed, because LoRA strength bends the whole generation, style and composition together. Takeaway: start around 0.7 to 0.8 and step in small increments. A robust LoRA tolerates a wide range; a fragile one does not, and only a sweep tells you which you have.

3. Base model: the hard compatibility wall

This is the one that eats afternoons, because a mismatch can mimic every other symptom. A LoRA is trained against a base architecture and only works within that family. On PixAI that means two disjoint worlds:

SDXL family  → Haruka v2, Hoshino v2, Illustrious-based models
DiT family   → the Tsubaki line (Tsubaki.2)

SDXL LoRA on SDXL model  → works
SDXL LoRA on DiT model   → will not load (separate ecosystem)

My LoRA is SDXL. Pairing it with Tsubaki.2 (DiT) was refused outright by the platform. Neither a weight change nor a trigger fixes that. Within SDXL, though, it traveled cleanly:

Every LoRA card in the PixAI Market tags its base (DiT.2 or XL) on the front. Read the tag, match the model, and this entire class of bug never occurs. PixAI's own docs note that crossing into a distant SDXL branch (an Illustrious LoRA on a Pony base, for example) is where the classic melted faces come from, so "same family" is the safe boundary, not "same era."

4. Prompt conflict: precedence matters

A working LoRA plus a contradictory prompt produces an unstable image. To probe precedence, I kept trigger and weight correct, requested short blonde hair against a silver-haired LoRA, and left blonde hair in the negative from an earlier run. So: requested blonde, banned blonde, LoRA trained silver.

The positive prompt won, overriding both the LoRA and the negative. Two practical rules fall out: an explicit positive token is the strongest signal in the stack, and unstated traits drift (my first blonde bug came from leaving hair color unspecified under warm lighting). To debug an unstable output, strip the prompt to near-bare, confirm the LoRA alone, then add tokens back one at a time until one breaks it.

5. Character vs style: different test harness

A character LoRA reproduces an identity; a style LoRA reshapes the render. Testing one like the other is a category error. Three-way repro, character alone / style alone / stacked with style pulled to 0.5:

Stacking rule: keep the style weight below the character weight, or the style competes for the face. PixAI allows up to five LoRAs, but each one is another competing signal. Two is manageable. Five is a merge conflict.

The debug loop

1. Baseline: plain prompt, no LoRA
2. Add LoRA + trigger, confirm trigger survived into prompt
3. Lock the seed
4. Sweep weight in small steps
5. Mismatch? Check base tag vs model, switch to compatible model
6. Trait fighting? Strip prompt near-bare, reintroduce one token at a time
7. Compare outputs to each other, not to memory

Everything here runs in the browser. And when the Market has no LoRA that fits, training your own is the same workflow: Yukimai started as self-generated references plus a few minutes of browser-side training.

Bottom line: a "broken" LoRA is a settings bug plus one hard compatibility rule, all cheap to interrogate when you change one variable at a time. You can run every test above on PixAI without a local install.

Have a LoRA that behaves in a way this list does not explain? Drop the setup in the comments and I will take a look.