MiniMax H3 Partitioned Exact-Prefix Handoff [Compatibility]

If you searched for "MiniMax H3 Partitioned Exact-Prefix Handoff" you probably landed on its sibling first - the one without [Compatibility] on the end. That's the right one. This node is the older signature of the same engine, kept registered so workflows saved against it still load, and it carries the display name [Compatibility] for exactly that reason.

In the code it's the parent class: H3PartitionedExactPrefixHandoff runs the patch, and the production node subclasses it to add nine selectors. Same partitioning, same VDN/Sol execution path, same exact-prefix restoration. What you lose is the shipped production configuration.

What it does, briefly

MiniMax H3's Continuum workflow continues video in chunks, and every chunk after the first carries an exact protected prefix. Resizing that prefix down to the cheaper low grid changes what the transformer conditions on; restoring the values afterwards can't undo it. So the pack splits the low stage into two explicit video domains instead - protected prefix frames at the target grid (P), generated suffix frames at the lower source grid (S) - each with its own coordinates and RoPE, then evaluates one permitted K/V union with an additive log-measure bias on the prefix rows so the denser domain doesn't silently win more attention mass. VDN builds that union, Sol runs it in one call.

If you want the full mechanism, the sibling article covers it. Here the question is just whether to use this node.

Why the missing selectors matter

The nine fields the production node adds aren't cosmetic. Without them the runtime has no diagnostics keys to read, so it falls back to its internal defaults - and those defaults are the historical comparison path, not the validated production one. The one that bites is low_probe_execution_source: absent, it resolves to main_then_shadow, which runs the main low/probe pair and then a duplicate source-uniform shadow lifetime on top. You pay for an extra sampler lifetime you didn't ask for.

The audio side degrades too. There's no tick widget and no mode widget here, so the overlap width comes from the environment/default path - H3_FLOW_AUDIO_GUIDED_OVERLAP_TICKS, defaulting to 4 - and the mode falls back to plain sampler_mask, meaning the sampler-owned ramp runs without restoring H3's authoritative exact inner timestep labels. On a previously-failing continuation, that exact-timestep pairing is what took the first decoded boundary from about +11.15 dB down to +0.21 dB. The sound story here is the pre-fix one.

There's also no vdn_linear_diagnostic and no prefix-transformer-context control, so the escape hatches you'd use to bisect a bad seam aren't on the node.

What you do control

The shared front half is identical, and it's what a beginner actually sets. model (your patched H3 model) and trajectory (an H3_FLOW_TRAJECTORY from MiniMax H3 Flow Trajectory). learned_upscaler is required - there's no handoff_transfer field on this node either, because the code pins learned_3d; you need the H3_LATENT_UPSCALER provider from xmarre/Comfyui_Minimax_h3_latent_Upscaler-Plus. Then source_scale=0.70 (a linear width/height scale, not area), handoff_coordinate=0.35 with handoff_selection=fixed, and guidance_mode=direction+temporal with direction_weight=0.25, temporal_weight=0.20, low_frequency_cutoff=0.25. As always, acceleration_weight and consistency_weight are staged and unused in that mode.

Outputs are model (wire onward into the sampler or the next patcher) and metrics, with an optional metrics input so you can pass an existing H3_FLOW_METRICS through to MiniMax H3 Metrics JSON.

Installing it

Same pack, same steps:

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

Restart, then search "MiniMax H3 Flow-Aligned Regenerate" in Manager if you'd rather click. No requirements.txt, no pip step - the only declared dependency is numpy>=1.25.

When to actually pick this node

Two honest cases. First, you have a workflow serialized against this signature and you don't want to re-wire widgets: load it, it still works. Second, you've pinned the pre-0.3.8 Flow against a matching Sol-H3/VDN-H3-Plus pair and your whole stack is frozen - staying put is defensible, moving the node alone is not.

Otherwise, use the production node. It's the same class with the validated defaults and the knobs to diagnose them, and the release notes are explicit that the H3PartitionedExactPrefixDiagnosticHandoff ID was retained purely so old graphs keep loading.

Either way, the environment requirement is identical: both nodes lazily import the partitioned backends from xmarre/ComfyUI-Sol-H3 and xmarre/ComfyUI-VDN-H3-Plus, and both throw the same RuntimeError - "partitioned exact-prefix continuation requires the matching Sol-H3 and VDN-H3-Plus development branches" - at queue time if those aren't installed at a matching version. If that message is what brought you here, the fix is the coordinated release set in the repo's RELEASE_CONTEXT.md, not a different node ID.