The half of H3 that stayed closed
For video generation, the central workflow has two stages after prompt preparation. H3-Base generates the initial video at 768P. H3-Regenerate-2K then feeds that result, together with the original context, back through H3 to regenerate it at 2K. MiniMax also operates a separate H3-Context-IR module to prepare complex multimodal instructions. The regeneration stage is the part that remains API-only.
The second stage never became available as open weights. MiniMax provides it through a hosted API that takes an unmodified H3 768P result together with its original context and returns a regenerated 2K video. Developers running the base model locally still need the service for that official finishing step.
Open-H3-Regenerate-2K is an attempt to close that gap from outside MiniMax. It was built by the NVlabs Sana / SoL-Engine team, and what they shipped is deliberately narrow: not a new video model, but a separately trained open-weight alternative to the finishing stage.
How three steps do the work
The draft is encoded once. A community 3D-convolutional model, H3-Latent-Upscaler, enlarges the latent directly onto the target grid, avoiding a slow decode-resize-re-encode round trip. This step carries the draft's layout, colour and motion to the larger resolution; it does not itself create the missing detail. The three subsequent diffusion steps regenerate surfaces and finer detail at the target resolution. The enlarged latent is re-noised to sigma 0.909 and denoised in three Euler steps (0.909 → 0.857 → 0.667 → 0) with guidance off, so each step is a single transformer pass at full resolution.
Almost nothing in H3 itself was retrained. The transformer and VAE stay frozen; the only trained component is a refiner LoRA, taught on real high-resolution clips paired with degraded copies of themselves. For inference that LoRA is merged with two community adapters, LightX2V's FL2VA Turbo and LMS Sharp, into one rank-576 LoRA over 312 linear layers.
Two design choices widen it beyond a clone of the API. It accepts drafts at several low resolutions, not just 768P, and drafts from other models: the project page shows LTX-2 and SANA-Video clips carried through the same refiner. And it goes past the API's ceiling, regenerating natively at 1080P, 2K or 4K rather than stopping at 2K.
Read the numbers with their conditions attached
The headline figures are the team's own, and each carries a condition.
The 87% preference figure comes from a blinded pairwise study the team ran itself: 50 cases, 20 completed sessions and 200 judgments. Twenty-five cases used videos from RefinerBench-150, the benchmark associated with the same SoL-Refiner research line; the other 25 used prompts shared online. Participants compared randomly ordered 2K outputs and chose which looked better. Blinding and pairwise comparison are useful safeguards, but 200 judgments across this limited set are not an independent, large-scale evaluation. The result should be read as the team's own preference study, not a general measure of how users will rate the model.
The automatic metrics are more nuanced than a single winner. On UniPercept, the open refiner scores higher on all three reported axes: aesthetics, image quality, and structure and texture. On VBench, it leads in aesthetic quality, imaging quality and subject consistency. The official API is slightly ahead on motion smoothness and dynamic degree, while background consistency is effectively level. These are the team's measurements on RefinerBench-150, not an independent replication.
The speed figure needs its hardware label. A five-second clip, starting from a 768P latent and ending at 2560 × 1440, took 22.45 seconds with the optimized SoL-Engine path and fast VAE decoder, against 87.26 seconds for the team's standard Diffusers forward with the released decoder. Both measurements were made on one B200, using warm runs and the median of three. Draft generation, model loading, text encoding and MP4 writing are excluded. This is a 3.89× improvement against the team's own baseline, not an independently measured comparison with MiniMax's API. The project page separately advertises "5.0× faster than the official API" but does not show the API timing behind that headline in its published benchmark table. Treat that claim as unverified.
Then there is the practical bill. The merged LoRA is stored in FP32. ComfyUI Wiki reports that Kijai subsequently published a separate rank-384 extraction of the refiner, at roughly 5GB, for community workflows. That is a community packaging option, not the official release format. There are no official ComfyUI nodes; the reference path is a Python CLI. Community nodes and conversions exist already. ComfyUI Wiki also documents a conversion trap: conversions that skip the required SwiGLU layout transformation produce incorrect weights and can make the resulting model appear broken.
What "open" means here
The license deserves the same care as the benchmarks. The newly trained refiner LoRA, fast H3 VAE decoder and bundled H3 base components follow the MiniMax H3 Community License, including its territory, use and redistribution terms. But the released inference bundle also incorporates LightX2V FL2VA Turbo and LMS Sharp, while the H3-Latent-Upscaler is another separately licensed component. Those components retain their own licensing terms. The Hugging Face card explicitly says the bundle is not covered by a single blanket license. This is an open-weight alternative, not an unrestricted open-source release.
That does not cancel the value. For anyone building on the open H3 base, the missing stage was the difference between a local pipeline and a local pipeline plus a paid API call at the end. That call is now optional. What remains unproven is how the refiner behaves on ordinary consumer hardware, outside its authors' benchmark, over the next few weeks of community use.
The interesting change is not just that H3 users can now avoid the regeneration API. The refiner accepts drafts from other models too, making it a potential finishing stage for video pipelines that do not use MiniMax for initial generation. Whether that flexibility holds up across ordinary hardware and a wider range of footage remains to be tested.
Sources
- [1] Hugging Face model card, Efficient-Large-Model/Open-H3-Regenerate-2K (primary — read first-hand): the three-step schedule (sigmas 0.909/0.857/0.667/0, guidance off), the merged rank-576 LoRA over 312 linears in FP32, the B200 speed table (87.26s standard + released VAE; 37.39s SoL + released VAE; 22.45s SoL + fast VAE), the fast VAE decode figures, and the licence paragraph including the component licencesRead source
- [2] NVlabs Sana project page, "High-Resolution Video Refinement with Few-Step Diffusion" (primary — read first-hand): method, UniPercept and VBench results (§4.1), user-study design (§4.3: 50 cases, 20 completed sessions, 200 judgments, 87%), LTX-2 and SANA-Video input demos, native-4K vs resized-4K comparison, and the "5.0× faster than the official API" header claim, for which the published benchmark table shows no API timingRead source
- [3] MiniMax official H3 model card (primary — read first-hand): the complete system consists of three modules — H3-Context-IR, H3-Base and H3-Regenerate-2K; the regeneration module feeds the 768P result together with the original context back into H3 and is not open-sourced, with an API provided insteadRead source
- [4] ComfyUI Wiki, "Open-H3-Regenerate-2K: Open 4K Refinement for MiniMax H3", Oct 27, updated Oct 28, 2026 (community-implementation source): Kijai's separate rank-384 extraction at roughly 5GB and the SwiGLU layout conversion warningRead source