MiniMax H3 Audio Plan Step

Every long video workflow has one node that quietly decides whether the result holds together, and it's usually the boring one. MiniMax H3 Audio Plan Step is that node here. The planner does the thinking once; this thing runs on every iteration of your extension loop and answers a single question: for task N, exactly which frames of audio, which frames of picture, and how many frames of everything else?

It doesn't render and it doesn't crop. It returns integers and tensors, and the crops are your job - which means a mistake shows up as an error instead of a subtly wrong video.

What comes out of it

Wire the planner's plan output into plan, feed your loop counter into task_index (zero-based), and pass the same master_audio and image_batch you gave the planner - in the same order. Optionally previous_frames: the accumulated retained output from all earlier tasks. Also optionally conditioning_audio, the H3 guide source (typically a raw Demucs vocal stem); its slices keep that source's native sample rate, and when it's disconnected the master audio is used as the guide.

Fifteen outputs, which sounds worse than it is. Grouped:

• audio_slice - the exact native-rate conditioning-audio window for this task, boundary padding included. Goes to H3's audio guide.
• continuity_clip + has_continuity - the final 22 generated frames of previous_frames, so motion carries across the seam. Ordinary extension tasks get it; destination handoffs don't.
• prompt_image - the image this task should be conditioned on. Feed it to current_image on MiniMax H3 Image Prompt Conditioning.
• visible_transition_image, has_visible_transition, visible_transition_frame_index - legacy names kept stable for v4 serialisation, and here's the trap: this is no longer a visible output frame. On a destination handoff it's the hidden anchor, cropped before anything is kept. Don't preview it and expect to see it.
• lookahead_image + has_lookahead + lookahead_frame_index - cropped trailing lookahead, present only when the planner's cropped_lookahead_conditioning is set to future_image.
• has_bridge_endpoint + bridge_endpoint_frame_index - a hidden bridge endpoint, for full_interval bridges.
• render_frames - the legal H3 length for this task, off the 17k+5 grid.
• crop_start_frames and keep_frames - chop this many leading frames, then append this many to the retained timeline. These two are the contract. Get them right and the audio stays locked.

The mechanism that matters: the hidden destination handoff

Understand this before you debug anything. On a short_window bridge, the next image's task generates 22 destination-tokenised lead-in frames plus one exact anchor at local frame 22 - and all 23 are cropped. Local frame 23 is the first retained frame, landing on the requested transition timestamp.

The point is that the literal reference photo never appears in your output. No flash of the raw still at the cut. Destination influence still starts where you asked, it just lives entirely inside discarded frames. And this 23-frame destination crop is not ordinary continuation - ordinary extension tasks keep exactly 22 generated frames as continuity; destination handoffs receive no old-image clip at all. Two similar-looking numbers doing opposite jobs.

Install

ComfyUI Manager → search ComfyUI_Eclipse, or:

cd ComfyUI/custom_nodes
git clone https://github.com/r-vage/ComfyUI_Eclipse

Restart ComfyUI. No model downloads for these nodes, and the dependency list is modest - opencv and pilgram are the ones a clean install is usually missing. The H3 weights are a separate ~42 GB download, and Eclipse's diffusion loaders live in the companion ComfyUI_SmartModelLoader pack now.

Fair warning: the pack ships these three node contracts and a README, not the workflow that connects them - that's distributed separately, and the repo's workflows/ folder doesn't include it. You're assembling the loop yourself. The old RvTools_v2 line is dead too: if a saved workflow red-lights on unknown Eclipse node types, the Workflow Migration Tool (or python tools/migrate_workflow.py) rewrites it with backups.

When it fights you

It validates hard, and the errors are specific enough to be useful.

The one you'll meet: Accumulated timeline drift at task N: expected X frames, received Y - meaning previous_frames has the wrong count, usually because crop_start_frames wasn't applied or the full render got appended instead of keep_frames. The node also checks the plan's sample rate and sample count against the audio you handed it, and the image count against your batch. Reorder the images or swap the master track and you'll be told, not silently mismatched.

Task 0 must not receive previous_frames is a loop-wiring problem, not a bug - the first pass can't have an accumulator. And Plan Step rejects older plan versions - it takes version 4 only, so if you're reusing a saved graph from an earlier release, re-run the planner.

Everything not applicable to the current task still returns something. Check has_continuity, has_lookahead and has_bridge_endpoint and route those guides through lazy branches so an absent anchor isn't evaluated. Keep the README's guide order: visual prompt conditioning, conditioning audio, ordinary continuity, hidden destination anchor, hidden bridge endpoint, cropped lookahead, guider. Every hidden thing - anchors, endpoints, padding, leading continuity - has to be cropped away by the plan's values before frames get appended.