DEV Community: Merl Merl

The Model Filled In a Null and I Almost Shipped It

Merl Merl — Mon, 20 Jul 2026 08:18:42 +0000

I spent a week treating an AI video model like a system under test, and the most useful result came from a bug I nearly missed.

Setup: I designed an anime character with a fixed spec. Navy hair with a lighter gradient, warm hazel eyes, cream hoodie, olive jacket, silver headphones, a beauty mark under one eye. Call it a fixture. Then I fed her to PixAI v4.0 Preview as a reference image and asked for a five second clip.

The output looked correct. Motion held, style held, the character was recognizably her. I almost moved on. Then I checked the spec field by field, and her eyes were blue.

Isolating the variable

The interesting question is why, and the only way to answer it is the same way you would debug anything else. Change one thing. Rerun. Compare.

Run	Reference shows eyes	Prompt states eye color	Result
1	no (back view)	no	blue, wrong
2	no (back view)	yes	hazel, correct
3	yes (front portrait)	no	hazel, correct

Three runs, one variable each. The pattern falls out immediately: what the reference image fails to show, the model fills in with a plausible default. My back-view reference never showed her eyes. The model had a null and it filled it with something consistent with the rest of the input, and blue hair gets blue eyes.

The headphones did the same thing, coming back with black earpads where the reference only ever showed the outside of the cups.

If you have ever debugged a system that silently coerces a missing field into a sensible-looking default instead of throwing, this will feel familiar. The failure mode is identical, and so is the reason it is dangerous: the output is plausible enough to pass a glance.

Two independent fixes both worked, which is worth stating separately, because it tells you the model is reading both channels:

Fix A: make the reference show the field.
Fix B: state the field in the prompt.

Either one closes the gap. Neither is documented as a rule anywhere I could find, because it falls out of the interaction between the two inputs rather than from either one alone.

The reference is an input with two possible contracts

This is the part I would push on if you are evaluating any image-to-video tool. "Supports reference images" is meaningless until you know what the tool does with the reference.

PixAI v4.0 Preview happens to expose both behaviors as explicit modes, which made the comparison clean. Same reference image in both runs, a front-facing studio portrait on a flat gray backdrop:

First and Last Frames. The reference is the literal frame at t=0. The clip starts as the portrait, gray backdrop and all, and animates forward. Deterministic, and it welds your character to the pose and background you happened to draw.

Multi-Reference. The reference is a semantic identity anchor. The clip opened on a rooftop at dusk, a scene that exists nowhere in the reference image, with the character intact and the gray backdrop gone. The model pulled the subject from the image and the world from the prompt.

Same input, two contracts, two different tools. A generator that only implements the first is a constrained animator. A generator that implements the second lets one character sheet serve as the source for arbitrary scenes, which is the difference between a demo and a pipeline. The v4.0 Preview overview documents how the reference system is structured.

One counterintuitive detail: more reference images gives you less. The platform's own testing found two or three focused images outperform a larger stack, since averaging across inputs softens the result. My single clean portrait beat the atmospheric wide shot for one reason. It showed the face.

Camera direction is a real interface

I wanted to know whether camera instructions are decoration or API, so I wrote a five second clip as four ordered beats: open on a close-up of her hands on a railing, tilt up along her arm to her face, orbit slowly left, then pull back to a medium wide.

All four executed, in order, without a cut.

That means push in, pull back, tilt, and orbit behave as directives rather than vibes, which is directly testable on any candidate tool and takes one generation to check. Ask for an orbit left. If you get a drift right, you have learned something the feature matrix would never have told you. The prompt guide covers the syntax, including how the timestamp format itself signals a continuous take rather than a cut.

Iteration cost is an engineering constraint

Every result above came out of a rerun of something that failed first. That arithmetic belongs in the tool decision, and it rarely shows up in comparisons.

Concrete numbers from my runs, read off the panel before each generation:

Five seconds on v4.0 Lite Preview: 27,500 credits
Five seconds on v4.0 Preview: 70,000 credits

Roughly 2.5x for the same duration. The two share an architecture and take identical reference and audio inputs, so the recommended practice is to draft on Lite and commit to Preview once the direction is locked. That held up for me. The entire eye color investigation, all three runs, ran on Lite. Paying premium rates to discover that a prompt needed one more sentence would have been pure waste.

The evaluation question this raises: what does a draft cost against a final, and can you change one variable and rerun without rebuilding the whole setup? A tool that produces beautiful output at a price that discourages iteration is a tool you will use once.

The short version

If you are choosing an image-to-video tool for character work, the test that matters takes one afternoon:

Build a fixture with a spec you can verify field by field.
Give the tool a reference that deliberately hides one field.
Check whether the output invents that field or leaves it alone.
Rerun with the field stated in the prompt.
Rerun with a reference that shows the field.
Compare all three.

You will learn more from those six steps than from every comparison table on the topic, because you will find out exactly where the tool's defaults live. Mine put them at blue.

If you want to run it yourself, PixAI is where I did.

Debugging a LoRA That Won't Render

Merl Merl — Tue, 14 Jul 2026 15:14:37 +0000

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.