Analysis September 1, 2026 workflow 10 min read

HR Endless Sampler renders arbitrarily long MiniMax H3 video on a 16 GB card by running Gemma 4 as a continuity supervisor between chunks, and because the entire supervision policy ships as an editable prompt file, continuity has become a text problem you can debug.

HR Endless Sampler MiniMax H3 Gemma 4 ComfyUI video-gen local-creative-ai creative-workflows prompt-craft

The Fix for AI Video That Forgets Is an Editable Text File

A ComfyUI node pack renders unlimited-length MiniMax H3 video on 16 GB by putting a language model in charge of continuity, and it ships the director's notes as plain text you can rewrite.

Buried in a ComfyUI node pack, in a file called gemma4_prompts.txt, there is this instruction:

A camera cut changes framing, not the character's physical state or location. If Tila was last observed mounted on the tiger inside the temple, a later face close-up of Tila remains inside that temple and she remains mounted unless the source explicitly dismounts or relocates her.

That is a continuity note. The kind a script supervisor writes on a set. It is addressed to a 12-billion-parameter language model, it is re-read from disk before every single chunk of video gets generated, and you can open it in a text editor and change it.

I have not seen a generative video tool expose its own reasoning this way before, and I think it is the most interesting thing anyone shipped this week. Not because the video is better than what a bigger model produces, but because it makes a class of failure debuggable that has been opaque since these tools appeared.

The problem this is aimed at

Every open video model has a length ceiling. Past it, you get nothing. Under it, you get a clip. Stitch two clips together and the character's jacket changes colour, the room reorganizes itself, and the person talking at the cut is not quite the person who was talking before it.

The obvious workaround is chunking: split one long generation into pieces the model can hold, carry some frames forward as context, and weld the seams. People have been doing this for a while and it half works. The reason it only half works is that carrying pixels forward tells the model what the last frame looked like. It does not tell the model what is supposed to happen next, where in the story it is, or what it already accomplished.

HR Endless Sampler, from a developer working as hradec, is a chunked replacement for ComfyUI's SamplerCustomAdvanced that adds the missing half. It supports MiniMax H3 only right now, with LTX-2.5 described as planned. The author's posted result is 625 frames at 1080p, about 26 seconds at 24 fps, rendered on a 16 GB GPU. The repo sits at 72 stars as of this morning, which tells you roughly nothing about whether it is good and quite a lot about how early you are.

What it actually does between chunks

The chunking part is conventional and worth understanding before the interesting part.

Each chunk generates a slice of one long latent. chunk_frames sets how many frames go into a single H3 call. video_continuation sets how many finished frames carry forward, presented to H3 as a synchronized <Video N> and <Audio N> reference pair. The previous chunk's final five frames also go across as a small boundary keyframe, automatically, to help adjacent chunks meet cleanly. H3 uses a 5 + 17k frame grid, so your chunk size gets aligned to that grid whether you like it or not.

Now the part that is not conventional.

Before chunk one is sampled, Gemma 4 12B reads the entire prompt and writes a timing plan for every shot, knowing in advance where every physical chunk boundary will fall. Then for each chunk, Gemma receives the relevant slice of that plan, the previous chunk's frames sampled at 2 FPS plus its exact final frame, the previous chunk's own Gemma-written description, and a persistent table of character state. It writes one short detailed_description for the chunk ahead. H3 sees only that description. It never sees Gemma's planning JSON.

The memory choreography that makes this fit on a consumer card deserves its own sentence. Gemma runs in a separate process. H3, Qwen and the video VAE are unloaded before it starts, and the Gemma process exits before sampling resumes. That is the whole trick: a 12B language model and a 33B video model take turns on the same 16 GB rather than sharing it.

The continuity memory is a JSON table, and you can read it

The persistent state Gemma maintains between chunks is called last_seen_character_state, and its schema is spelled out in the prompt file:

{"character_name":"Tila","subject":"<Subject 2>","last_seen_global_frame":208,
 "last_seen_source_shot":4,"environment":"inside the ancient temple",
 "pose_and_position":"mounted on the tiger, seated behind Heman",
 "state_and_action":"alert and leaning forward",
 "spatial_relationships":"behind Heman and on the tiger saddle"}

The rules around it are strict and they read like someone who has been burned. The table describes rendered evidence only, never a forecast. If a character is absent from the attached stills, their previous entry is copied verbatim rather than dropped. The instruction is explicit: "Never erase a known state merely because a character is off-screen, and never replace it with an inference from the current unrendered source plan."

There is a second design decision in there that I keep coming back to:

If the plan and rendered evidence conflict, the latest rendered still is authoritative: acknowledge the drift in analysis, then continue the next unfinished immediate beat without replaying a completed action or compressing every later beat.

The system assumes the video model will disobey. It plans anyway, checks what actually came out, and re-plans from reality. That is a mature assumption to build on, and it is the opposite of how most prompt-chaining tools behave.

The prompt file also handles the small, specific ways generated video goes wrong. Dialogue is immutable and preserved word for word inside <d>...</d> tags. A camera move that was not introduced by a real cut marker must begin with the exact words "In a continuous movement," so the model does not turn a pan into an undocumented cut. An audible thing the source never showed on screen stays off screen: "Never invent a cut to show a sound source, and never substitute a referenced animal or character merely because it can produce a similar sound." Events written in the same shot are assumed to happen at the same time unless the source uses an explicit connector like "then" or "after," because description order is not sequence order.

Every one of those is a lesson somebody learned by watching a render go wrong. They are sitting in a text file with a comment header explaining which placeholders you may use. You can add your own.

Put this into practice

Install. Clone the node pack into custom_nodes, then install its dependencies with ComfyUI's own Python:

~/comfyui/tools/python.sh -m pip install -r requirements.txt

That pulls llama-cpp-python==0.3.35 from the CUDA 12.5 wheel channel, plus huggingface-hub>=0.34.0 and av>=16.0.0. The pinned llama-cpp-python version is not decoration; the MTP decoding path depends on symbols in that build.

Wire it. Replace SamplerCustomAdvanced with HR Endless Sampler and connect five extra inputs: clip from the model clip, vae from the H3 video VAE, images from your ref2va reference images, prompt from your full prompt text, and fps at 24. Then place HR Endless Sampler Preview in the model path ahead of the guider, routing the H3 model through the preview node and using its output for the guider.

There is no workflow JSON template. The author says so directly, under a heading that begins "Quick HELP as I don't have a workflow template yet." You are wiring this by hand.

Set the two numbers that matter. For 1080p on 16 GB with five 720p reference images, the author uses chunk_frames=56 and video_continuation=22, with KJNodes' MiniMax H3 Low VRAM Attention node set to 4. Without that node, drop chunk_frames to 39. Twenty-two frames of continuation is the documented default for continuity; five is the minimum.

Let the first run download Gemma. It fetches Google's Gemma 4 12B QAT Q4 GGUF plus its projector and a matching 465 MB Q8 MTP assistant into models/llama_cpp/gemma-4-12b-it-qat-q4_0/.

Write prompts in MiniMax shot format. First shot carries no timecode, later shots use strictly increasing cut times:

[Shot 1] The tiger runs through the jungle.
[Shot 2] At 00:02.833, the camera cuts inside the temple.

Set fps to the same rate those timecodes assume. The sampler converts cut times to frames, keeps each real cut at the right position inside its physical chunk, and hands H3 the local timecode.

Then use the two features that make this worth the setup.

Hover a coloured chunk bar in the preview timeline and you see the exact prompt Gemma wrote for that chunk, plus H3 render time, Gemma processing time and the total. When a shot goes wrong, you can read the instruction that produced it. That is a debugging loop that did not exist before.

And debug_start_chunk lets you re-render from a chosen chunk without resampling everything before it. The first run builds a replay cache holding the noise, the completed chunks and the continuation boundary. If you change the main prompt during a replay, the sampler keeps the saved frames and noise but asks Gemma for a fresh preproduction plan and rebuilds its KV cache, so moving a line of dialogue earlier actually changes the rerun. Set it back to 0 to clear the cache.

Every render also drops Gemma's full transcript at ${TMPDIR}/comfyui-hr-endless-sampler/last_gemma_chunk_prompts.txt, with the stills it saw in a sibling directory, even with debug off. A new render overwrites both, so copy them if you want to keep a comparison.

Where it breaks

Nothing is watching the audio. This is the one that matters most and it is stated flatly in the repo's own limits section: "Gemma observes generated video frames, not generated audio. It preserves dialogue and sound instructions from the source prompt, but does not judge the resulting soundtrack." So the whole continuity apparatus, the state table, the drift detection, the re-planning against rendered evidence, supervises picture. On a long chain the soundtrack is running unsupervised. Plan on a separate audio pass for anything you would show a client.

Chunk two is more expensive than chunk one. Later chunks carry the continuation tail, so a setting that survives the first chunk can still die on the second. The docs say this outright. Test to chunk two before you queue thirty.

Chunking buys you length, not resolution. "Chunking reduces the temporal part of H3's memory use. It cannot make an arbitrary resolution fit: one full-resolution H3 sampling step must still fit in VRAM." If 1080p does not fit for one step, no chunk size rescues it.

The speed path is riding an open upstream bug. gemma4_mtp enables Gemma's native four-token draft decoder, which is real speculative decoding with a reported acceptance rate. The README calls the fast MTP checkpoint path "currently experimental in upstream llama.cpp" and links to an open issue. The sampler handles this well, running Gemma in a disposable worker and retrying only the failed operation once with the ordinary decoder rather than silently degrading. But if you want a stable render, turn MTP off.

It is one model and one person. MiniMax H3 only. LTX-2.5 support is planned, not shipped. Chunked denoise masks are not supported. The sampler can reconstruct image and audio Ref2VA inputs but cannot turn an image input back into an original video Ref2VA source. And MiniMax H3 itself ships under a community licence rather than a permissive one, so check its terms before this workflow touches commercial work.

The part worth taking away

Long-form generated video has been sold as a model problem. Bigger context, longer attention, more frames per pass. This node pack proposes a different answer: the model stays the size it is, and a language model sits beside it writing down what happened so the next pass can act on it.

Whether that scales past a handful of chunks, I do not know, and neither does the author. What I do know is that the continuity policy is a text file with named sections and documented placeholders, re-read before every chunk. If your renders drift in a way that is specific to your material, you do not file an issue and wait. You open the file, add a rule, and run again.

That is a smaller thing than a new model and a more useful one. Go read gemma4_prompts.txt before you install anything. It is the best short document I have read on what actually goes wrong in generated video, and it costs you nothing to open.

Medium metadata

Title: The Fix for AI Video That Forgets Is an Editable Text File
Subtitle: A ComfyUI node pack renders unlimited-length MiniMax H3 video on 16 GB by putting Gemma 4 in charge of continuity, and ships the director's notes as plain text.
Tags: AI Video Generation, ComfyUI, Generative AI, Prompt Engineering, Open Source AI
Estimated read: 8 minutes
Canonical sources: ComfyUI-HR-Endless-Sampler · gemma4_prompts.txt · MiniMax H3 · Gemma 4 12B QAT Q4 GGUF · ComfyUI-KJNodes