One ComfyUI graph, one script box, one boolean. Flip it and the same scene renders through a different engine.

It is not a quality ranking. It is a choice of grammar. 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.

The switch is lazy: the engine you did not pick loads nothing and renders nothing, so you can install one lane, run it, and add the other later.

Both engines read one script in H3 form: one block per shot, --- alone on a line between blocks, 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 (RiftEngineScript) emits both forms: verbatim blocks for H3, and for LTX the scene stated once with the per-shot remainder 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.

One script. Nothing written twice.

Two example scripts ship, because one script cannot show off both engines. example_script.txt (loaded in the graph) holds one static two-shot, which is what lets H3's chain read as a single take; example_script_cuts.txt names a different framing in every block — wide two-shot, medium on her, over-the-shoulder on him — which is what makes LTX-2.5 cut. Naming a new framing every block is exactly what would make H3 jump at its joins.

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, the beat boundaries — 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 with no cut identifiable anywhere.

Same scene, same characters, same room. Two grammars.

Needs ComfyUI-H3-Multishot v2.2.0 or newer — the multishot sampler, RiftEngineScript, the lazy switches and MASTER CONTROLS all come from there. Everything else in the graph is core ComfyUI. Model list and VRAM notes are in INSTALL.md.

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

RES4LYF is required as shipped — the graph selects the beta57 scheduler, 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 must be present before the first Queue, even though only one lane executes: the lazy switch is a render-time mechanism and ComfyUI's validation knows nothing about it.

The LTX-2.5 lane ships pointing at the int8-convrot transformer and encoder, which is what it was verified on. bf16 LTX-2.5 22B is roughly 44 GB of weights and spills to system RAM on a 32 GB card.

For 12, 16 or 24 GB, swap the two LTX loaders to a quantised build from LTX-2.5-Quantized. 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 there too at 10.60 GB - at bf16 that encoder alone is 26.3 GB, which is what actually owns a small card.

Sensible picks: Q3_K_M (10.60 GB) on 16 GB, comfy-mix4x8-13.8GB if you have the room, Q5_K_M or comfy-mix4x8-17GB on 24 GB.

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