MiniMax H3 Native Prefix Counterfactual

When a continuation join looks wrong, the instinct is to blame the sampler. Sometimes it's the decoder. Those are different bugs with different fixes, and the cheapest way to tell them apart is to hold the sampled latents completely fixed and intervene only on what the decoder sees.

MiniMax H3 Native Prefix Counterfactual does exactly that, on a saved capture. Both arms start from the same already-generated source latent, only one slice of it changes, and the whole rest of the tensor is verified bitwise identical before a single VAE call. No denoiser is invoked. No sampler runs. Three decodes, zero encodes, zero H3 evaluations.

The intervention, precisely

Arm A is the saved source_probe_clean_full tensor, untouched. Arm B is a copy where only the first 12 latent tokens - the protected source prefix, [:, :, 0:12] - have been replaced by the source-grid bicubic projection of the authoritative target prefix authoritative_prefix_full. In the reference capture that's [1, 24, 12, 62, 62] at a 992×992 target canvas, projected down to a [1, 24, 62, 44, 44] source tensor at 704×704.

The generated source tokens [12:62] stay bitwise identical between arms - the code compares them as raw int32 bit patterns and raises if they differ. The two arms share shape, output normalization and VAE weights. Then two sequential native decodes run through the production 5-token/2-overlap temporal stitching, reduced to matching pixel times f170–195 and released before the next call. A third decode of a short cropped window acts as a context control, to check whether the shorter replay window used in earlier audits disagrees with the full-context arm.

If the decoded geometry, tone or texture around the join moves, the decoder-side prefix is implicated. If nothing moves, you've ruled that branch out and you can go back to suspecting the sampler trajectory.

Inputs

video_vae - the native H3 video VAE, same checkpoint used in production. The documentation is specific that you connect minimax_h3_video_vae_int8_convrot.safetensors for the reference capture, and generally the production VAE rather than a preview, audio or decoder-only stand-in.

bundle_path - the original capture bundle directory, with its manifest.json and every unmodified .bin operand, or the manifest path directly.

chunk_join_frame - default 175, the assembled first-new-frame index for the reference capture.

Optional: static_roi_profile (off, 01784_room, custom), static_roi_json for your own fractional rectangles, feature_tracking_enabled, and expected_manifest_sha256.

That last one deserves attention, because it ships pre-filled with a specific hash - 80a082e5…d56, the digest of the original 01795 capture manifest. The tooltip says it outright: "Exact 01795 manifest hash. Clear to select a different native-carry bundle." Leave the default and try to run it on your own capture and you'll get a hash mismatch, which reads like corruption but is just the pin doing its job. Clear the field.

Output is a single numerical_report string: JSON, printed to the node UI, and written under output/h3_flow_regenerate/boundary_audits/.

Install

cd ComfyUI/custom_nodes
git clone https://github.com/xmarre/MiniMax-H3-Flow-Aligned-Regenerate
# restart ComfyUI

Manager route: search MiniMax H3 Flow-Aligned Regenerate. The pack needs only numpy beyond ComfyUI's own stack, plus OpenCV for the optional tracking and a native H3 video VAE checkpoint that you already have if you're generating with H3 at all. No H3 model is loaded by this node - the workflow that ships with it deliberately omits the sampler, Continuum assembly and upscaler.

Don't over-read the result

The report carries its own honest caveats, and two of them matter more than the rest. First, replacing the prefix changes the f174 anchor, so anything measured relative to f174 is confounded - a scale shift there is not automatically evidence of a defect. Second, and this is the sentence to keep: "A VAE-only counterfactual cannot demonstrate correction of the source sampler trajectory." Even a clean, dramatic result here is diagnostic evidence about the decoder window, not a fix you can promote into a workflow.

The practical consequence is that this node is best used the way it was built: as one instrument in a chain. It's a legacy reader, paired with the pack's other saved-bundle audits, and it tells you where a join problem lives. Whether to change anything is a question for decoded media and a rerun, not for a JSON file.