MiniMax H3 · Native AV Context Commit

If the R37 motion-context system is a relay race, IAMCCS_MiniMaxH3MotionContextStateCommitR37 is the handoff. It takes the sampled AV latent from a finished chunk and persists it to disk under a numbered run directory, so that when the next chunk runs, IAMCCS_MiniMaxH3MotionContextConditionR37 can load it back and continue the motion. Nothing fancy, but in a chained video pipeline the state between runs is where everything either stays coherent or silently falls apart - and this node is what makes it coherent.

How it works

It's deliberately small. Feed it the decoded frames, audio, the sampled latent, and the resolved render ID plus segment index, and it:

1. Checks whether the motion-context branch is actually active in the shot plan. If it isn't (you're on the standard branch), it's a transparent pass-through - frames and audio come out unchanged, report passes through. No disk writes, no fuss.
2. If active, it saves the latent through the companion provider (MiniMaxH3AutoChainSaveLatent) to a path like h3_context/<render_id>_clip<N+1>, with N being the segment just finished. The next segment's load_clip_index is set to match.
3. Appends the save path to the incoming checkpoint report so you can see the chain state in the log.

The naming detail matters: it saves the next clip index (segment + 1) because the latent you just rendered is exactly what segment + 1 will consume as its context. Get that off by one and every chunk loads the wrong predecessor.

Inputs

• frames and audio - the visible decoded output, passed straight through.
• sampled_latent - the AV latent to commit. This is the payload that matters.
• cine_linx - the shot plan (activates/deactivates the commit).
• segment_index - which chunk just finished.
• resolved_render_id - names the chain; the source says "after IAMCCS resolves the numbered render ID", meaning upstream decides the final run name first.
• checkpoint_report - the accumulated report string from the native checkpoint stage, which this node extends.

Outputs

• frames, audio - unchanged (pass-through by design).
• resolved_render_id - passed through.
• report - the incoming checkpoint report plus the commit line, including the exact latent path saved.

Install

The usual pack install (ComfyUI Manager → IAMCCS, or git clone https://github.com/IAMCCS/IAMCCS-nodes.git into custom_nodes). It needs the same companion ComfyUI-H3-Motion-Context-Auto-Chain addon as the rest of the R37 family - the save happens through that addon's provider node, and without it you'll get a clear "provider node unavailable" runtime error.

Gotchas

• This node is why you don't purge h3_context mid-run. The whole loop's continuity lives in those saved latents. Delete them while chunks are queued and every subsequent chunk errors on load.
• It's not an output/save node in the video sense - no MP4 comes out of here. It commits latent state; the R38 delivery stages write files.
• Both pass-through and commit look identical on the surface, so read the report string if you're not sure the motion-context branch actually activated. "R37 Motion Context AV latent committed" = it saved; no such line = bypass.
• Running chunks out of order (segment 2 before 1) will happily commit latents the chain never expects - trust the queue, don't hand-drive segments.