MiniMax H3 Target Timing (Legacy)

This is the pack's smallest node and the easiest to skip, which is a shame, because it exists to stop a genuinely annoying failure: a graph cycle. When your final Visual Reference context feeds back into the Prompt Guide, and the Guide is also your source of the native frame count, you've created a loop - the reference video needs to know its length before the prompt is written, but the length comes from the prompt. Target Timing resolves the duration once, up front, so nothing feeds backward.

If that sentence made your eyes glaze, the practical version is shorter: in any legacy workflow that uses chained visual references, put one of these at the top, and never pull h3_length out of the Prompt Guide.

What it does

It takes one of two things:

• duration_seconds - your target playback length, 4 to 15 seconds. Rounded upward to H3's native 17k+5 frame grid at 24 FPS.
• shot_plan (optional) - the final node of a MiniMax H3 Shot chain. Its last end_time replaces duration_seconds, and the whole validated plan rides along inside the timing context.

The math is the pack's, cross-checked against ComfyUI's native H3 grid formulas: request 6.0 s and you get 158 frames (6.58 s); the maximum is 362 frames, 15.083 s.

Outputs - all three matter

• timing_context - connects to Prompt Guide's timing_context input. This is what keeps timing upstream when a reference context also feeds the Guide.
• h3_length - the native frame count. Connect it to every video Visual Reference's h3_length input and to the official H3 conditioning node's length input. Feeding the same resolved number everywhere is what keeps trimming and prompt writing in agreement.
• timing_report - a string showing the requested duration, the native length, the effective duration, and whether a connected Shot chain overrode the widget.

Installing

cd ComfyUI/custom_nodes
git clone https://github.com/ethanfel/ComfyUI-MiniMax-H3-Guide

Restart ComfyUI; it shows up under MiniMax H3/Prompting. No Python dependencies, no model downloads - it's pure timing arithmetic, which is exactly why it's safe to put at the front of any workflow.

The one thing to get right

Use it whenever a visual reference_context feeds the Guide. The old pattern of connecting the Guide's h3_length directly to reference nodes breaks in that setup, and the pack's tooltips are unusually explicit about it: "never create a backward cycle." Wire Target Timing first, fan its h3_length out to the references and the conditioning node, and the rest of the graph stays a simple directed flow. In a no-reference, text-only workflow you can get away without it - but it costs one node to make everything deterministic, and the timing_report output doubles as a nice sanity check on your durations.