MiniMax H3 Regenerate 2K

MiniMax's 2K regeneration endpoint is the cleverest thing in this API, and it's easy to miss. Instead of rendering 2K from scratch, you hand it a request you already ran at 768P plus the video that came out of it, and it re-renders that clip at 2K. Same composition, same motion, higher resolution.

MiniMax H3 Regenerate 2K is the node for it, and it's the reason to keep your drafts on the 768P tier even though the base Generate Video node defaults to 2K.

How the wiring goes

Two required inputs, both forced wires rather than widgets - you can't type into them:

generation_request_json takes the request_json output of Generate Video. That's the exact body the original 768P run posted, which is why the pack re-exports it as an output instead of hiding it. base_video_url takes the resulting video_url from that same node.

There's also an optional base_video input of type VIDEO, for when you'd rather hand it the clip as a ComfyUI object - but you use one or the other, not both. Sending both gets you Use base_video or base_video_url, not both.

The node validates your inputs before spending anything. The stored request has to be a MiniMax-H3 request (not Max, not Fast), its resolution has to be 768P, its content has to be a non-empty list, and it must not already contain a base_video item. Then it appends the source video to the content as a base_video role and posts the whole thing at 2K.

Outputs

video_url, task_id, status, task_json - the same four-bookkeeping-outputs shape as the other generation nodes, minus the request JSON. Send video_url into Preview Video, and you're done.

The requirement nobody reads

The source video has to contain audio, and it has to match MiniMax's H3 768P output spec. That last part is why this is a regeneration rather than an upscale: you can't feed it a clip you shot on your phone or upscaled with your own pipeline and expect it to work. The base video has to be something this API produced.

It also means you can't skip the 768P step. There's no path from a 2K render down to a regenerated 2K render, and no way to reconstruct the request JSON after the fact - the first generation node emits it, the API doesn't hand it back afterwards.

Is it actually cheaper

Yes, in the way that matters: you render the idea once at 768P (¥0.50/sec on the base model), like it, then pay for a regeneration instead of re-rolling a fresh 2K job (¥0.80/sec) and hoping the seed gods cooperate. Ten seconds of 768P plus a 2K regeneration beats two 2K attempts at the same duration, and you get the motion you already approved rather than a new interpretation of it.

That's the workflow worth building: 768P draft, inspect, regenerate the winner. Keep the request_json around between runs - it's a string, so a text node or a saved workflow will hold it.

Install

cd ComfyUI/custom_nodes
git clone https://github.com/magicwang1111/ComfyUI-MiniMax-H3-API

Restart ComfyUI, then cp local.example.json local.json in the pack folder and fill in api_key, with base_url matching your key's region - https://api.minimax.cn for China, https://api.minimax.io overseas. Dependencies are requests and Pillow, and there are no model downloads. ComfyUI Manager users can search ComfyUI-MiniMax-H3-API.

Traps

generation_request_json must use MiniMax-H3 means you grabbed the request from a Max or Turbo node - those tiers don't have a regeneration path. Video regeneration requires a source request generated at 768P means the original run was 2K; start the draft at 768P next time.

The pack ships an example (06_768p_regenerate_2k.json) that wires draft to regeneration end to end. Load it before you build by hand - the two-wires-in shape is easier to copy than to describe.