H3 · Plan Windows

The standard trick for long AI video has been last-frame chaining: generate five seconds, grab the final frame, feed it back as the first frame of the next clip, repeat. It's how people got 30-second Wan clips out of 81-frame generations - at the cost of a visible seam at every join and a slow smear of identity drift. H3 Relay's answer is to stop pretending the clips are separate. H3 · Plan Windows is where that starts, and it's the cheapest node in the pack: pure integer arithmetic, no models, no GPU.

What it decides

Given a source frame count, a window size and a history length, it produces the immutable list of windows the rest of the graph loop iterates over. Each window record knows where it starts in the source, where it ends, how many frames of generated history precede it, how many frames get thrown away as overlap, and how many new frames it delivers. Same input, same list, every time.

That determinism is the point. If window geometry is decided by state carried through a loop, then changing any setting rebuilds a different timeline and nothing you already reviewed matches. Here the plan is one object computed once, hashed against your settings, and reused.

How it works

The planner respects H3's two arithmetic grids: windows are 17n+5 frames (22, 39, 56 … 362) and history is 0, 1, or 17n+1 (18, 35, 52 …). The first window carries no history at all. Each subsequent window starts one frame before the accepted prefix ends, so exactly one boundary frame is regenerated and the overlap you discard is that one frame. Window size is the smallest legal value that covers what's left - so a small tail doesn't get blown up into a full-size window and waste compute.

Three schedules:

• adaptive - the character-swap planner. Picks legal sizes on the fly from your window setting.
• removal_v1 - Person Remover's original behaviour: fixed stride, requires exactly 18 history frames, seeds increment per window.
• segment - one explicit pass whose source already contains its supplied history. This is the only schedule that accepts external history; feed it initial_history from the history-file loader and the history is excluded from delivery.

Inputs and outputs

source_frames should come from Prepare Source's source_frames output - the unpadded real count. window_frames is your budget/quality dial: bigger windows give H3 more to hold together per pass, smaller windows are more reviewable and use less VRAM. history_frames at 18 is the sane default; larger overlaps carry more matched audio + visual context and leave you less new duration per render. seed plus seed_mode (fixed or increment) control per-window noise, and seed_overrides is a JSON string for pinning one specific window - it must map existing window indices to integers or the node refuses the whole string.

Outputs: windows (the bundle you wire into Window Inputs or Review Windows), count (drive a native Start Loop's iteration count with this - it's an INT, which is the loop mode that survives a frontend export/reload), window_list (the same windows as a real list, for the loop's per-iteration value), and timeline, a JSON dump you can actually read when a boundary looks wrong.

Install

ComfyUI Manager → search H3 Relay → install → restart, or:

cd /path/to/ComfyUI/custom_nodes
git clone https://github.com/akatz-ai/h3-relay.git

This node needs nothing else - no ffmpeg, no weights, no GPU. It will happily plan a timeline on a laptop with ComfyUI 0.37.0 and no H3 files installed, which makes it a good way to check your geometry before committing to a 40-minute render. (The models come later, and they're the part with the licence attached: the MiniMax H3 Community Licence carves the US, EU, UK and Korea out of its territory, outputs included.)

Where people get burned

The error messages here are unusually good, so trust them. History must be smaller than the generation window means you asked for 124-frame windows with 137 frames of history - a contradiction, not a bug. External history requires the explicit segment schedule is the most common one: you wired initial_history but left the schedule on adaptive, because nothing in the UI stops you.

The subtler trap is treating count as "how many clips I'll get". It's how many diffusion passes you're about to queue, each carrying up to a full window of frames, and on a 24 GB card they will not fit simultaneously. If you're not using the staged/reroll path, plan a sequence you're willing to run in sittings, review window one, then continue - that's the workflow this node is sized for.