MiniMax H3 Face Refine Window Studio Start / 多窗口串行启动 (Advanced)

The manual Window route fixes one bad stretch and stops. The Studio route is what you use when your video has several melt zones and you want to walk through them one at a time without babysitting the graph - and, crucially, without losing everything when ComfyUI crashes at frame 200. MiniMaxH3FaceRefineWindowStudioStartT8Advanced is the front door: it creates (or resumes) a durable multi-window manifest and hands you the first window to deal with.

What it does

You give it a window_plan (from MiniMaxH3FaceRefineWindowPlanT8Advanced) and a studio_id - a project name like face_refine_project_01. It writes a manifest that records, in order, every window in the plan and its decision state: pending, accepted, or rejected. From then on, the workflow processes one window at a time. Accept or reject a window in the Commit node, and the run advances to the next undecided one. If you crash mid-way, rerunning this node resumes from the first unresolved window instead of starting over - that's the whole appeal of the manifest.

The execution_mode trap

• review_only (default) - creates the manifest, reports the current window, and queues nothing. This is the safe starting mode. Read the output, look at the candidate, decide nothing.
• explicit_accept_and_continue - arms the chain so that after an explicit accept/reject in the Commit node, the controller may queue exactly one next window. Note the tooltip's warning: this mode does not accept anything by itself. The Commit node still requires your explicit decision. It only means "once I commit, keep the run going automatically."

Pair this with the Commit node's auto_continue input, which is where the actual next-window queueing gets triggered. The serial machinery (process lease, retry, cancellation) is reused from the pack's Long Video OS controller, so this isn't a reinvention - it's the same crash handling that long multi-keyframe renders use.

Inputs and outputs

Besides window_plan, studio_id and execution_mode, you get max_retries (default 1) and retry_delay_seconds (2.0) for the background job that queues the next window, plus release_policy (default clear_execution_cache) controlling what's freed between windows - sensible defaults, fiddly knobs for when a window repeatedly fails.

Outputs worth reading: window_index (which window you're on), chain_id and manifest_path (the durable state - back these up), auto_continue and job_id (wired into the Commit node so it knows which job to advance), complete (true when every window is resolved - that's your cue to run Studio Compose), and background_state_json/report_json for diagnostics.

Wiring it

Studio Start → extract/render the current window (via MiniMaxH3FaceRefineWindowExtractT8Advanced) → review + commit (MiniMaxH3FaceRefineWindowStudioCommitT8Advanced) → loop until complete → MiniMaxH3FaceRefineWindowStudioComposeT8Advanced to rebuild the final timeline. The working example is 2026-09-05_H3_Face_Refine_Window_Studio_Serial_Advanced_EXP.json under examples/workflows/06-face-refine.

Ground rules from the README, because they'll save you a corrupted project: accepted windows are immutable - you can't roll one back or rerun it, so preview first. A process-level lock stops two jobs from running the same project at once and fighting over VRAM. And don't batch-accept automatically; this route is Advanced EXP precisely because it hasn't finished multi-subject human blind testing. Install is the pack standard (Manager search "MiniMax H3 Audio T8", or clone into custom_nodes + restart - no extra pip deps).