Support

Everything here is free and stays free — the format spec, the nodes, the workflows, the cartridges, the LoRAs. If it saved you a night of debugging (it contains several hundred of mine), tips keep the 5090 warm:

• ☕ Buy me a coffee on Ko-fi

• 💛 Sponsor on GitHub

• 🔁 Liberapay (recurring)

⚡ Or right here: the Civitai tip button on this page sends Buzz directly.


One graph. One script box. One switch. Flip it and the same scene comes back as a single unbroken take, or as an edited scene that cuts itself.

Two engines share one workflow. MiniMax-H3 chains separate generations and hides the joins, so a five-shot scene reads as one camera roll. LTX-2.5 generates the whole scene in a single pass and places its own cuts inside it. Same script either way, same characters, same room - what changes is the grammar.

It is not a quality ranking. A conversation that should feel unbroken wants H3. A scene that wants to cut - wide, then her, then him - wants LTX-2.5, which will find those cuts itself.

What each engine gives you

MiniMax-H3, the continuous take

• chains N generations and welds the joins - picture, colour and audio cross each boundary as data rather than as a description

• as long as you like: add blocks to the script and the take gets longer

• identity held by reference images, a voice anchor and a raw-latent pin

• the seam cut lands in the quietest gap near each join, so a word that starts early is not clipped

LTX-2.5, the edited scene

• one generation, cuts inside it - you describe the framings, it decides where the cuts land

• picture and sound made together in the same pass, so room tone and dialogue run continuously across its own cuts

• identity held natively within the pass, no anchors required

• bounded by VRAM and length rather than by shot count

The script is the same either way

Both engines read one script, written in H3 form: one block per shot, --- alone on a line between blocks, and the scene restated in every block.

That restatement is what H3 needs - each block is a separate generation and the text is most of what they share. LTX-2.5 does not need it, and it buries the part that changes. So the SCRIPT node emits both forms: verbatim blocks for H3, and for LTX the scene stated once with the per-shot remainder following as a beat list. It finds the scene block as the longest common prefix across the blocks - which is exactly what "restate it verbatim" produces.

You maintain one script. Nothing is written twice.

What it does, shown

Two example scripts ship, because one script cannot show off both engines. The same diner scene, twice.

• example_script.txt - loaded in the graph. One static two-shot, with nothing in the text asking the camera to move, which is what lets H3's chain read as a single take.

• example_script_cuts.txt - the same scene with a different framing named in every block: wide two-shot, medium on her, over-the-shoulder on him. That is what makes LTX-2.5 cut.

Naming a new framing every block is exactly what would make H3 jump at its joins, because H3 renders each block separately. Write for the grammar you picked - that sentence is the whole workflow in one line.

LTX-2.5 on the cuts script: 385 frames at 1920x1088 in a single pass. A reviewer given the clip cold, with no idea how it was made, found three distinct camera setups and two cuts - at 00:06 and 00:12, which are the beat boundaries in the script - each framing as written. Identity held across the cuts, the room held, each voice stayed the same voice, lip-sync clean, and room tone and rain ran continuously across both cuts with no click or drop.

MiniMax-H3 on the one-take script: the same scene chained into three shots, 370 frames. The same kind of blind review read it as one continuous unbroken take, found no cut anywhere, and reported no shift in framing, colour, brightness or wardrobe and no hiss or dropout.

Layout

Four numbered groups, left to right: 1 WRITE IT ONCE - the script and the engine switch; 2 ENGINE A: MiniMax-H3; 3 ENGINE B: LTX-2.5; 4 OUT - the lazy switches, the mux and the save.

MASTER CONTROLS carries width and height for both lanes, and frames, steps, sampler and scheduler for the H3 lane; the LTX lane's step schedule lives in its own two sigma lists. Shot count is deliberately not there - it comes from the number of --- blocks in the script, so the script and the render cannot disagree.

The engine switch is lazy: at render time the engine you did not pick loads nothing and renders nothing, so you pay for one engine and not two.

Requirements

• ComfyUI 0.32.0 or newer. Verified on 0.32.0. Earlier versions do not ship LTXVDualCFGGuider, which this graph uses twice, so they cannot load it at all.

• ComfyUI-H3-Multishot v2.2.0 or newer. The multishot sampler, the script node, the lazy switches and MASTER CONTROLS all live there. Install it first; everything else in the graph is core ComfyUI.

• RES4LYF - required as shipped. The graph selects the beta57 scheduler, which RES4LYF registers, and ComfyUI validates every combo value before it runs anything, so without it the first Queue is refused on either engine. To run without it, set scheduler to beta on both MASTER CONTROLS and the H3 sampler.

• Both model sets present - H3 and LTX-2.5. The lazy switch is a render-time mechanism; ComfyUI validates every loader in a graph before it executes any of it, and validation knows nothing about laziness. Only one lane runs, but both have to be installed. Links below.

On the int8 builds. The bf16 LTX-2.5 22B is roughly 44 GB of weights; on a 32 GB card that spills to system RAM and crawls. The workflow ships pointing at the int8-convrot transformer and encoder, which is what it was verified on: 16 s at 1920x1088 with audio in about six minutes on an RTX 5090, no spill. On 48 GB or more, switch the two loaders to bf16.

On a smaller card - 12, 16 or 24 GB - the LTX-2.5 lane needs a quantised transformer, and there is a full ladder of them here: huggingface.co/joeygambino/LTX-2.5-Quantized-16GB. Thirteen builds cut from Lightricks' bf16 originals, from 7.91 GB up, in two families: GGUF for ComfyUI-GGUF, and comfy-* safetensors that load on the stock Load Diffusion Model node with no custom node at all. The quantised Gemma-4 text encoder is in there too at 10.60 GB, which matters more than people expect - at bf16 that encoder alone is 26.3 GB. Point the two LTX loaders at those instead and this graph runs on hardware it otherwise cannot.

Where the pieces live

• This workflow - Hugging Face and GitHub, both carrying the graph, the install notes and the two sample renders.

• ComfyUI-H3-Multishot, which the H3 lane needs - GitHub, or on Civitai as MiniMax-H3 Seamless Chain.

• Quantised LTX-2.5 weights for 12 to 24 GB cards - LTX-2.5-Quantized-16GB.

• How those quants were made, if you want to cut your own - ltx25-quant-lab.

MiniMax-H3 by MiniMax. LTX-2 by Lightricks. ComfyUI by Comfy Org.