Two video APIs both advertise a 2K output. You send the same prompt to each, you get back two files with identical dimensions, and your billing line item looks roughly the same. They are not the same product, and the difference is visible in one place: small text.
The two pipelines
Path A — post-hoc super-resolution. The model generates at its native resolution. A second network then scales the frames. ESRGAN, a diffusion SR pass, a temporal-consistency variant, it doesn't matter which. What matters is that the upscaler sees pixels and only pixels. It never saw your prompt. It has no idea the scene was supposed to contain a shop sign, so it does the only thing an interpolator can do: it makes edges confident. A blurry six-pixel-tall word becomes a crisp six-pixel-tall word that spells something else.
Path B — conditioned re-generation. The low-resolution result goes back into the same model along with the original conditioning — prompt, reference images, whatever produced it the first time — and the model generates again at the higher resolution. Nothing is interpolated. The second pass knows the sign reads OPEN because the conditioning still says the sign reads OPEN.
Both produce a file with the same pixel dimensions. Only one of them can recover information that was never in the low-resolution frames.
How to tell which one you actually bought
You don't need the vendor to tell you. Two tests, both cheap.
Test 1: put legible text in the scene. Generate at the low resolution, then at the high one. Look at the same word in both.
- If it's an upscaler, the high-res glyphs are a sharpened version of the same wrong shapes. The error is preserved and then rendered crisply. This is the tell — interpolation cannot invent a letter that wasn't there, so it commits to the smudge it was given.
- If it's a re-generation, the text is simply different. Often correct, sometimes wrong in a new way, but not a cleaned-up copy of the previous mistake.
Test 2: diff the motion. An upscaler operates frame by frame, or over a short temporal window. Frame 40 of the high-res clip corresponds exactly to frame 40 of the low-res one. A re-generation is a fresh sample: same intent, same composition, but the micro-motion drifts — a hand lands a few milliseconds off, the hair moves differently.
So: if your high-resolution render has frame-for-frame identical motion to your preview, you bought an upscaler. That's not a criticism, it's just a different product, and it should be priced like one.
The part nobody puts in the docs
Re-generation is not strictly better, and treating it as a free upgrade will break a pipeline.
The trade-off is exact frame correspondence. If you are building anything that previews at low resolution and then commits at high resolution — an editor with a scrubbing timeline, a batch job that picks a thumbnail frame index, an approval workflow where a human signs off on the cheap render — an upscaler is the thing you want. Your frame 40 stays frame 40. With re-generation, the clip your reviewer approved is not the clip you ship. Same shot, different take.
I've watched a team lose two days to this. They rendered previews, had a client pick an in-point by frame number, then rendered final at high resolution and cut on that number. The final motion had drifted maybe 80 ms. The edit landed mid-blink on every take.
The rule I'd write down: preview-then-commit workflows want deterministic upscaling; one-shot delivery wants re-generation. Decide which one you are before you pick the model, not after.
Cost follows the pipeline, and per-second pricing hides it
Most of these APIs bill per output second, with a different rate per resolution. That framing quietly conceals which pipeline you're on, because an upscale pass and a full second forward pass have wildly different compute costs but can be sold at similar-looking per-second rates.
Worth doing the arithmetic yourself before committing to a length. On the model I've been testing most, the high-resolution path runs roughly 60% above the base rate per output second, which is consistent with a real second pass rather than a bolt-on upscaler — someone has written up what a 2K clip actually costs once you multiply that out across a realistic set of takes, including the failed ones. The failure rate matters more than the rate card, and almost nobody models it.
A concrete example of the difference
MiniMax H3 is the clearest implementation of Path B I've found, mostly because it's documented as such rather than left ambiguous: the 768P result is fed back through the model along with the original context and generated again at 2K. The site I pulled the pricing from also puts the same frame down both paths side by side, which is the comparison every vendor should publish and almost none do.
There's an architectural consequence worth noting for anyone planning to self-host: if the high-resolution stage is a separate hosted component, downloading the base weights gets you the low-resolution path and nothing else. Your local output will be correct and will not match the hosted result, and you'll spend a while assuming you configured something wrong.
What to ask a vendor
Four questions. Any vendor running a real re-generation path can answer all four in one sentence; any vendor running an upscaler will get vague on the second one.
- Is the high-resolution output conditioned on the original prompt, or only on the low-resolution frames?
- Is frame n of the high-resolution render the same moment as frame n of the low-resolution one?
- Is the high-resolution stage the same model or a separate one?
- If I self-host, do I get both stages?
The answers determine whether "2K" in your invoice means resolution or means detail. They're not the same thing, and only one of them survives contact with a shop sign.
