MiniMax H3 Flow Trajectory

MiniMax H3 Flow Trajectory doesn't generate anything. No model load, no sampling, no pixels. What it does is sit at the top of every workflow in this pack and be the thing everything else argues over: a shared, in-memory record of one H3 denoising run that the later nodes read back. If you're coming at this pack cold, this is the node you'll place first and understand last.

The reason it exists is the pack's whole premise. MiniMax's closed 2K "regenerate" trick - generate once, then reuse the journey to make a better final clip - is the thing this author is approximating without the closed model. The trick needs a memory of what the model predicted at each point of the trajectory, not just the finished clip. So the pack's two-pass and progressive nodes all agree on one contract: a H3_FLOW_TRAJECTORY handle that stores predicted-clean latent states with provenance.

How it works. When a model patched by Trajectory Capture (or a progressive node) runs, it writes each denoised estimate into this handle as a transaction - tagged with the flow coordinate (H3's video flow shift is 12, not a raw step index, which matters with PECE samplers that revisit the same sigma), whether the call was an exact H3 evaluation or a Spectrum forecast, the run's geometry, and a bounded conditioning fingerprint. Guidance nodes later match against it by coordinate, not by call count.

You only set two things. storage picks where captured tensors live: system_ram (default) keeps VRAM free by moving trajectory data to host memory; vram skips that transfer at the cost of your precious few gigabytes. max_runs (default 16) caps how many retained runs the handle will hold before it starts evicting. Neither is something you'll fiddle with on a first attempt - defaults are fine.

The single output H3_FLOW_TRAJECTORY feeds into whichever nodes need the memory: Trajectory Capture on the low-res pass, Flow-Aligned Regenerate on the high-res one, or Progressive Handoff (Target Input), which captures internally so it doesn't want a separate capture node at all. One handle, one prompt, shared by every node that should talk to each other.

Install

Same as the rest of the pack - it ships in xmarre's single repo:

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

Then restart ComfyUI. PyTorch comes from ComfyUI and the pack declares zero Python dependencies of its own. ComfyUI Manager finds it if you search the pack title. No model files to download here - the handle is pure execution state.

Gotchas

The handle is deliberately non-cacheable: ComfyUI creates one fresh trajectory per prompt execution, so you can't capture in one queue run and guide in the next. That's a feature (stale memory would poison a match), but it means the whole multi-pass flow has to be one graph, one run. And the pack fails closed rather than guess - if a downstream node can't prove it shares a handle with the capture run, you get an error instead of silently bad guidance. Annoying when it happens, but honest.