Reproducibility in image generation usually gets treated as a seed problem. Lock the seed, get the same output. It works, and it also hides how little you know about the rest of your setup.
I spent a few days probing that on a small scale, because I write anime character work and I need the same character back on demand. The result changed how I think about where my prompts actually live.
The setup
I treated one character as a spec with seven fields:
- ash-grey hair, asymmetric undercut on the left
- amber eyes, thin ring pattern in the iris
- a small dark metal panel set into the left temple
- faint seam lines along the neck
- charcoal flight suit, burnt orange stripes on the sleeves
- heavy chest harness with metal buckles
- slim armored plate on the left forearm
The first three and the fourth are the interesting ones. Hair and clothing are coarse features that almost anything will approximate. A nine-word clause about a panel on someone's temple is a fine-grained field, and fine-grained fields are where systems fail quietly.
Test one: remove the seed
Standard assumption: without a locked seed, output drifts.
I ran the spec five times with the seed left free, on an anime-tuned DiT model, changing nothing else. All five came back with the undercut, the amber eyes, the temple panel, the harness and the forearm plate. Pose, camera angle, background and lighting varied every time.
One field wavered: the neck seams, the faintest thing in the spec, rendered lightly and inconsistently.
For contrast, the same scene from a fourteen-word prompt of the kind most people start with produced a competent pilot with no relationship to the spec at all.
So the seed governs composition, and the written spec governs identity. If you want the same character, you are not looking for a seed, you are looking for a spec detailed enough to survive sampling noise. Vague fields do not survive. "Futuristic details" would have produced five different characters. "A small dark metal panel set into his left temple" produced the same one five times.
Test two: change the model underneath
Same spec, character reference image attached, moved to a model built on SDXL rather than the DiT family.
The coarse fields survived. The temple panel and the neck seams dropped out. So did the scene: I had asked for an open airfield at dusk and got an abstract dark background with drifting embers.
Nothing was broken. SDXL-lineage models grew up on short keyword tags and read long written descriptions less closely than DiT models do. My spec was written for one runtime and executed on another without adaptation.
This is coupling, and it is easy to miss because the failure is graceful. The output is still a good image. It is just not your character, and if you are not checking specific fields, you will not notice until twenty images later when the panel is gone from all of them.
The settings tell the same story. On Tensor.Art, a model marketplace with a community library running into the thousands, I watched the workspace default to nine sampling steps at a CFG of 1, then offer a completely different sampler, CFG, and clip skip the moment I selected a community checkpoint. Those values belong to the model, not to you. A library of thousands of checkpoints is also thousands of small relearnings.
Test three: condition on a reference
Then the same spec and the same reference image, on a model built specifically for reference conditioning.
The airfield came back, hangars and a parked jet included. The temple panel came back. What changed was the render: softer and warmer than the flat cel look of the other runs, an accent the model brings with it.
So the recovery worked, and it cost me stylistic control. That is a reasonable trade when you know you are making it.
What generalises
Three things I would now tell anyone building on top of image generation:
Specificity beats determinism. A precise written spec survived random sampling better than I expected. If you need repeatability, invest in the spec before you invest in seed management.
Your prompt is coupled to a model family. Prompt style, weighting syntax and parameter defaults are all model-scoped. Treat a model swap the way you would treat a runtime upgrade, with a regression check on the fields you care about, rather than a drop-in replacement.
Test the smallest field, not the overall impression. Coarse features hide regressions. The temple panel was a better test signal than the whole character, because it failed first and it failed silently.
Where this leaves platform choice
For the anime work I do, this pushed me toward a character-first platform rather than a model-first one.
A model marketplace is a deep resource, and if exploring models is the work you enjoy, it is the right place to be. If the work you enjoy is the character, then every model swap is a tax you pay in relearning, and a platform that fixes the runtime and lets you iterate on the spec gets you further per hour.
Either way, write the spec down. It is the only part of the setup that is portable.
If you want to try the character-first version of this, PixAI is where I ran the tests.
Top comments (0)