Ares Load Last Video

MiniMax H3 generates 4–15 seconds per clip. If you want a minute of video, you don't get it from one prompt - you generate a clip, save it, then feed bits of it back in as the reference for the next generation and stitch the results together. The annoying part of that loop is the handoff: something has to take the file you just wrote and hand it to the next round as a VIDEO.

Ares Load Last Video is that something, and it is dumber than it sounds - in a good way. It doesn't track node state, doesn't know what round you're on, and doesn't care that this pack exists. It looks in ComfyUI's output folder, finds the newest video file, and loads it.

What it's actually doing

The whole node is about fifteen lines. It walks ComfyUI/output recursively, keeps every file ending in .mp4, .webm, .mov, .mkv or .avi, filters that list, and returns whichever one has the newest modification time. That's the trick. No graph introspection, no bookkeeping - a filesystem scan, which is why it survives restarts and works even if round one ran in a completely different session.

The second half of the mechanism is caching, and this is the part that would silently break the node if the author had forgotten it. ComfyUI caches nodes aggressively: if a node's inputs haven't changed, it just replays last run's output. A loader that reads "the newest file" has no inputs that change, so round two would happily hand you round one's same video again. AresLoadLastVideo declares a fingerprint that returns the newest file's mtime, so the moment Ares Save Video writes a new file, this node is considered dirty and actually re-reads the disk. (That's the same IS_CHANGED family of tricks covered in the plumbing docs - it's how every "reload this file every run" node works.)

Inputs and outputs that matter

Two inputs, one output.

prefix is a plain string, required, empty by default. If you leave it empty you match any video in the output tree; whatever was written most recently wins, including files from other workflows and other days. Type a substring of the path here - video/ComfyUI if you kept the save node's default - and it only counts files whose relative path contains that text. Set this. It is the difference between a predictable loop and one that occasionally grabs a clip you generated last Tuesday.

initial_video is the optional VIDEO you want used for round one. Where people get burned: it is only consulted when the scan finds nothing. If there's an old mp4 sitting in your output directory, your "first round" quietly uses that instead of your initial video, and you get a continuation of something you don't remember making. Fresh install, clean output/video folder, or a tight enough prefix that the scan can't miss.

The output is a single video (VIDEO). Wire it into Ares Trim Video, or into anything else that eats a VIDEO. One thing beginners trip on: H3's ref_video_0 input does not take a VIDEO object - it takes an IMAGE frame batch. So the real chain is Load Last Video → Trim Video → its images output → ref_video_0, and its last_frame → ref_image_0. The loader gets you the file; the trim node turns it into something the model can chew on.

Install

Same pack, same steps for all four Ares nodes:

cd ComfyUI/custom_nodes
git clone https://github.com/SuperWJ062/ComfyUI-ares_MiniMaxH3_IntelligentPrompt

Restart ComfyUI. No requirements.txt, nothing to pip install - the pack imports only torch, folder_paths and comfy_api.latest, which ship with ComfyUI. ComfyUI Manager will install it by pack title too, registry permitting.

Two real prerequisites. Your ComfyUI needs to be current enough to have the new node-authoring API (io.ComfyNode / io.Schema); on an ancient install the pack won't even import. And you need the H3 weights themselves - roughly 42.5GB - which is a separate download. Worth knowing before you invest the evening: MiniMax's community licence excludes the US, EU, UK and South Korea, so depending on where you are, running these weights locally isn't licensed at all.

When it breaks

The one error you're most likely to see is the node's own message, which is unusually helpful: it tells you no saved video was found and to either run Ares Save Video once or wire initial_video. That's the classic first-run failure - you queued the loop before any video existed.

After that, it's all the stale-file traps above. If your loop keeps re-using an old clip, your prefix is too loose. If round two looks nothing like round one, check what else is writing video files to your output directory. And if you move files out of the output folder, this node simply won't see them.