Train a LoRA on Krea 2, load it into a Z-Image workflow, and you'll get something. It just won't be your character. LoRAs are tied to the weights of the model they were trained on. Swap the base model and the LoRA doesn't degrade gracefully — it stops matching the architecture it's being asked to steer.
This is obvious once you've hit it, but it still catches people, usually mid-project, when a new model family becomes the better option for a shot and the old LoRA comes along for the ride out of habit.
The problem isn't training, it's bookkeeping
Training a LoRA per model family isn't the hard part. Most people have already done it by accident — a Krea 2 LoRA here, a FLUX one there, saved under slightly different filenames, in different folders, named after the character but not the model.
The hard part is remembering which file goes with which model at 11pm when you're trying to finish a batch. You load the wrong LoRA into the wrong model, generations come out soft or just wrong, and you spend twenty minutes assuming it's a prompt problem before checking the obvious thing.
The fix is to stop treating the LoRA as a loose file and start treating the character as a record with slots.
What a character record actually holds
A character record is one structured thing that bundles everything needed to keep a character consistent, with explicit room for the fact that model families don't share weights:
- A written description (so the character has a consistent identity on paper, not just in pixels)
- Reference photos (for face lock and visual QA)
- A separate LoRA slot for each model family — Krea 2, Z-Image, FLUX — each one trained specifically for that architecture
The point of the separate slots isn't redundancy. It's that a character only has one LoRA per model family, and that slot is either filled with the correct file or it's empty. There's no ambiguity about which Krea 2 LoRA is the real one versus an old test run, because the record only holds one.
Loading by ID instead of by memory
Once a character exists as a record rather than a loose collection of files, workflows can load it by ID. The workflow checks which model is loaded, looks at the character record, and pulls the LoRA slot matching that model family automatically.
This removes the manual step entirely. You're not hunting through a LoRA folder trying to remember which version was trained last, and you're not relying on filename conventions to keep you honest. The workflow does the lookup for you, and if a model family's slot is empty, the gap is visible rather than silently papered over by whatever LoRA happened to be loaded last.
If you haven't set this up yet, registering a character is the starting point — it creates the record that everything else reads from.
Why this matters more as you add model families
With one model, a single LoRA file is manageable even if it's a bit messy. The trouble compounds as you add more. Three model families means three LoRAs, three sets of training runs, three opportunities to load the wrong one. Without a structure, the number of files you have to track grows faster than your ability to keep them straight.
A per-model slot system scales the way you'd want: adding a new model family to your pipeline means training one more LoRA and dropping it into the corresponding slot. The character record doesn't need to change shape, and none of your existing workflows need to be touched, because they were already built to look up the slot that matches whatever model is loaded.
It also makes it obvious when you're missing coverage. If a character only has a Krea 2 LoRA and you want to run a FLUX batch, the gap is visible in the record instead of discovered mid-render when the output doesn't look right.
Keeping the library honest over time
The other thing a structured record buys you is cleanup. Loose LoRA files accumulate — old training runs, abandoned experiments, duplicates from testing different settings. A character record with fixed slots per model family doesn't have room for that sprawl. There's exactly one current LoRA per family, and anything else is clearly a leftover you can delete.
This matters more than it sounds like it should. The failure mode isn't usually a corrupted file or a bad training run — it's just drift. Six months in, nobody remembers which of the four similarly-named files is the one actually in use. A record with explicit slots prevents that drift from starting in the first place.
Takeaway
If you work across more than one model family, stop keeping LoRAs as loose files and start keeping them as slots on a character record — one slot per model, filled with the LoRA trained for that model, nothing else. Set it up once with the custom nodes that support character lookup, and every workflow that loads that character by ID will apply the right LoRA without you having to think about it again.
