Viggle Open-Sources Two LoRAs for MiniMax-H3: Swapping People in Video Works From 12 GB of VRAM

Viggle has published Viggle Remake, a pair of open LoRAs, or compact adapters, for the MiniMax-H3 video model. They rework existing video and preserve what usually breaks in generative editing: motion, camera position, timing and audio all stay from the source clip. Only what you explicitly draw on the keyframes changes. The adapters can run locally: in ComfyUI, a GPU with 12 GB of memory (VRAM) is enough at 832×480 resolution with Q4_K_M or Q8_0 quantized weights. The weights are on HuggingFace, and you can try the model without your own hardware in the Viggle app.

Two modes and how to use them

The release consists of two adapters. Swap handles replacing people and characters, either one or several at once. Edit takes care of everything else: objects, backgrounds, weather, lighting and style.

Both LoRAs were trained with rank 256 on the H3 transformer, and each weighs 2.67 GB. For those short on storage or memory, there are low-rank versions at 1.34 and 0.67 GB. According to the authors, their quality is nearly the same.

The input is a source video, one to four "redrawn" frames and a text prompt. The workflow is simple: take a frame from the source and edit it in any editor. You can insert a new character, remove an unwanted object or paint in a thunderstorm. The model carries appearance and style over from those frames and takes motion and camera from the original clip.

For long projects, Viggle has released an MCP server. With it, an agent built on Claude Code or Codex can cut a film into windows, draw keyframes, render segments and stitch them together with the audio on its own.

Hardware requirements

In ComfyUI, the Viggle node pack is all you need: it goes into custom_nodes, and the LoRAs go into models/loras. Ready-made workflows for swap and edit are in the repository. VRAM recommendations are as follows:

• 12 GB — Q4_K_M or Q8_0 with the --reserve-vram 8 flag, 832×480 resolution;
• 16 GB — int8 with no extra flags, 832×480;
• 24 GB — int8 or Q4 at 832×480; for 1280×736 you need Q4 or Q8 with --reserve-vram 20;
• 48 GB — Q8_0 at 1280×736;
• 80 GB — bf16 together with the LoRA.

You will need 47–55 GB of system RAM at 832×480 and 55–80 GB at 1280×736. bf16 at 1280×736 requires as much as 127 GB. One important caveat: the 12–24 GB configurations were tested by emulation on a B200, not on actual consumer cards, so the flags may differ on real hardware.

Clip length and speed

A single window is designed for 90–345 frames. The --frames parameter is chosen using the formula 17n+5, and the developers advise staying within 294 frames, which is about 12 seconds at 24 frames per second. Longer clips have to be split into windows, and the MCP server handles that chore.

According to B200 measurements, an 832×480 clip of 226 frames renders in about 95 seconds in ComfyUI and in 58 seconds via the sample.py script. The first run in ComfyUI takes 2.5–3 minutes. At 1280×736, rendering stretches to 510–585 seconds.

What this means in practice

The key point of the release is the division of roles. Motion, camera and audio come from real footage, and the neural network is responsible only for the visual substitution. For editors and anyone making ads and music videos, this is more convenient than generating an entire clip from scratch: the rhythm and shot composition don't drift.

The timing figures were obtained on a B200, so rendering will be noticeably slower on home cards. Still, the entry threshold starts at 12 GB of VRAM and quantized model variants, so the tool is accessible beyond studios with server-grade GPUs. The authors put the details on prompting and ComfyUI setup into separate guides in the repository.