Dual Engine — MiniMax-H3 + LTX-2.5, one script, one switch
One ComfyUI graph, one script box, one boolean. Flip it and the same scene renders through a different engine.
| MiniMax-H3 | LTX-2.5 | |
|---|---|---|
| how | chains N generations and hides the joins | one generation, cuts inside it |
| result | one continuous take | an edited scene |
| length | as long as you like — add blocks | one pass, bounded by VRAM and length |
| audio | welded across the joins | native, continuous across its own cuts |
| identity | reference images, voice anchor, latent pin | held natively within the pass |
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.
The script is the same either way
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.
What it does, shown
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.
Install
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.
Running it on a smaller card
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.
Related
- ComfyUI-H3-Multishot — the node pack this depends on
- LTX-2.5-Quantized — quantised LTX-2.5 weights for the second lane
- ltx25-quant-lab — the tooling those were cut with, if you want to make your own
- MiniMax-H3 Multishot Workflow — the single-engine H3 seamless-chain workflow
MiniMax-H3 by MiniMax. LTX-2 by Lightricks. ComfyUI by Comfy Org.