H3 Continue Sampler
The GO button that finishes the clip you already approved
- draft_state
- output
- denoised_output
- report
Every video workflow eventually asks the same question: can I look at the thing before I commit twenty minutes of GPU time to it? The usual trick - decode an intermediate, like it, start over from the same seed - doesn't reproduce anything, because the second run re-noises the latent from scratch. H3 Continue Sampler is what happens when somebody decides to do it properly: it resumes the exact sampling state the Draft produced, with zero new noise added.
This is the second half of the Draft/Continue pair. It goes with H3 Draft Sampler, and if you're confused about which of the four nodes in this pack you want, the split is simple: the Sampler pair plugs into a hand-built SamplerCustomAdvanced graph and hands you raw LATENTs; the T2VA pair builds its own conditioning and decodes its own video. Don't cross the streams - the state types don't match and the node tells you so.
Inputs and outputs
Three inputs, and two of them are bookkeeping you don't type:
- draft_state - the wire from
H3 Draft Sampler. It's declared lazy, which is the polite part: while GO is off, ComfyUI doesn't re-execute the upstream Draft just because you queued the graph. - go - the boolean. In the UI it's the GO control in the status panel, and it's disabled unless the directly connected Draft has a valid reviewed Preview. From the API, set it yourself.
- approved_state_id - the tooltip says it plainly: "Filled by GO after Preview. API clients use the reviewed state.state_id." You only ever paste a value here if you're scripting.
Outputs are plain Core LATENTs: output and denoised_output, plus report. Both latent outputs are the joint video+audio nested tensor, so your existing video VAE Decode, audio VAE Decode, upscale, refine and Save branches keep working untouched. There's no decoder or saver inside this node, which is deliberate - it's a drop-in replacement for a sampling block, not a workflow.
How the resume stays honest
Before a single step runs, the node re-verifies four things against the state it was handed: that the state came from this backend session, that your approval ID matches the state's own ID, that the upstream graph hash still matches what was Previewed, and that the model/LoRA runtime signature is unchanged. Then it fingerprints the stored payload itself. Miss any of them and you get a specific error - "Prompt, model, LoRA or another upstream setting changed after Preview" is the one you'll meet most.
Sampling then continues from the frozen AV latents with the remaining slice of the original sigma schedule and a DisableNoise object (seed preserved, no fresh noise generated). The report records resumed_from_step, new_noise: false, conditioning_reencoded: false and schedule_rebuilt: false - that trio is the claim this pack is making, and you can check it in the JSON rather than taking anyone's word.
One neat detail: with GO off the node returns an execution blocker rather than an error, so a queue with GO off simply skips everything downstream - your Decode and Save nodes don't fire, and nothing turns red. Try it: Preview, review, then queue. That's the intended rhythm.
Install
Same as the rest of the pack - Manager search for "MiniMax H3 Draft Continue", or:
cd ComfyUI/custom_nodes
git clone https://github.com/ukr8b3g-cmyk/MiniMax-H3-T2VA-Draft-Continue
# restart ComfyUI
No pip installs, no downloaded models, no server routes. You do need Core with native MiniMax H3 support and a recent frontend for the review panel; the author's validated combo is ComfyUI 0.37.0 with Frontend 1.52.7 on a 16 GB card.
Where people get burned
"This draft has not been reviewed." Nine times out of ten the state is simply gone: you restarted ComfyUI, reloaded the tab, or reopened a saved workflow. Approval state is session-scoped on purpose and is never serialized into the workflow file, so opening someone else's template always means a fresh Preview.
Reconnecting the wire counts as a change. The node checks that the Draft feeding it is the directly connected Draft at output slot 1. Disconnect and reconnect to the same node and the old approval is invalid - by design, since the pack can't otherwise tell two branches apart.
"This draft is already being continued." A draft holds a lock while Continue runs. Queue twice by accident and the second job errors instead of racing the first.
Wrong Draft attached. Feed it the integrated H3 T2VA Draft state and you'll get a message about the legacy integrated Draft using a different state type. That's the pack catching a mix-up, not a bug - pair each Draft with its own Continue.
Inputs (3)
| Name | Type | Default | Description |
|---|---|---|---|
| draft_state | H3_SAMPLER_DRAFT_STATE | — | |
| go | BOOLEAN | false | — |
| approved_state_id | STRING | Filled by GO after Preview. API clients use the reviewed state.state_id. |
Outputs (3)
| Name | Type | Description |
|---|---|---|
| output | LATENT | — |
| denoised_output | LATENT | — |
| report | STRING | — |