H3 Draft Sampler

MiniMax H3 is the 33B omni-modal video model MiniMax opened in August 2026: text, image and audio in one context, native stereo sound, up to 15 seconds at 2K. Day-zero ComfyUI support, and a genuinely strong launch reception. It is also slow enough that finding out at the very end that your subject is off-frame, or that the model drew a completely different room, costs you the entire run. (One non-technical thing worth knowing before you spend a weekend on it: the H3 Community License excludes the US, EU, UK and South Korea from its Applicable Territory, so in those regions you aren't licensed to run the local weights at all.)

H3 Draft Sampler is the fix for the slow part. It runs the first chunk of your sampling schedule, decodes a preview of frame zero, and hands you a state object that resumes the same generation later - from the same noise, the same schedule, the same conditioning.

What it actually does

You drop it exactly where SamplerCustomAdvanced sits. Feed it the same NOISE, GUIDER, SAMPLER, SIGMAS and LATENT you'd normally connect, plus the H3 video VAE so it has something to decode the preview with. It then:

1. clones the guider and freezes the conditioning and the sigma schedule,
2. samples only the first preview_steps transitions of your schedule,
3. decodes the predicted x0 through the video VAE and keeps frame 0 as an IMAGE,
4. copies the joint AV latents to CPU and prints a report with a state ID and the sigma it stopped at.

Nothing is rebuilt. The node doesn't re-encode your prompt, doesn't re-run the text encoder, doesn't pick a new seed. That's the whole point - resuming is only exact if nothing upstream moved.

Inputs and outputs that matter

The five sampler ports and the latent are pass-throughs; if you already have a working H3 workflow, you're just re-homing the wires. The two you actually think about:

• video_vae - the H3 video VAE, used only to decode the one-frame preview. You don't need the audio VAE here.
• preview_steps - the split index. Default 3. The tooltip is the important bit: "Number of sampling transitions before review. Must leave at least one transition in the supplied SIGMAS." With the author's proven baseline (4-step Turbo LoRA at strength 1, 6 total steps) the split is 3/3.

Outputs: preview_image (one RGB frame at your full canvas size - wire it to a Preview Image node, or just watch the built-in panel), draft_state (goes to H3 Continue Sampler and nowhere else), and report (a JSON string - the useful place to read the state ID, the reference manifest and the split sigma).

What it refuses to do, loudly

This node validates harder than most. It only accepts a native MiniMaxH3 model - connect it after your Turbo LoRA loader, not before - and only Core BasicGuider, CFGGuider or DualCFGGuider. The sampler must be Core Euler with s_churn at 0, and the schedule must be strictly descending and end at zero. Multistep solvers like res_multistep are refused on the same principle: they carry hidden solver history the state can't reproduce, and the author would rather fail than pretend. Latents with a noise_mask are rejected too - image references and keyframes belong in CONDITIONING, not in the latent.

Install

No pip dependencies and no model downloads come from this pack; requirements.txt is empty and the H3 weights, text encoder, VAEs and Turbo LoRA are yours to supply. Either search the pack title in ComfyUI Manager, or:

cd ComfyUI/custom_nodes
git clone https://github.com/ukr8b3g-cmyk/MiniMax-H3-T2VA-Draft-Continue
# restart ComfyUI

You need a recent Core with native H3 support; the author's validated environment is ComfyUI 0.37.0 on an RTX 5060 Ti 16 GB.

Where people get burned

A preview is an x0 estimate, not your final first frame. The author says it in the tooltip and in every doc: it's the model's current guess at step 3 of 6, so it will sharpen and shift as Continue runs. Judge composition and framing, not skin texture.

The approval doesn't survive much. The draft state lives in the current ComfyUI backend session only. Restarting the server, reloading the page, or reopening a saved workflow means a fresh Preview - saved workflows deliberately never store approval. Editing anything upstream after Preview marks the draft stale and GO will refuse.

Duration snaps to H3's frame grid. Ask for 5 seconds and you get 124 frames at 24 fps, i.e. about 5.17 seconds. Not a bug, just how H3's 17k+5 grid works.

The state has a 512 MiB budget. The AV latents, conditioning and schedule are copied to CPU RAM to make resuming safe. Go big on resolution or duration and you can price yourself out of a draft state - you'll get an explicit size error, not a silent quality loss.

One draft, one downstream branch. Another Draft/Continue branch is a hard boundary, and a reviewed draft can only be continued once. Want a second look? Generate a second Preview.