Two LoRAs, one re-shoot

Most open video releases this year generate a clip from a prompt. Remake starts from a clip that already exists. The user supplies the source video, one to four painted frames showing what should change, and a prompt in MiniMax-H3's six-section format. The swap LoRA replaces the people in the footage, one or several at once. The edit LoRA handles everything else: an object removed, a prop inserted, a clear afternoon turned into a storm. Both LoRAs are designed to preserve the source footage's motion, camera movement and timing while changing its appearance. The source soundtrack is retained rather than regenerated. That is the intended behavior, not a guarantee that every movement, expression or transition survives unchanged. Viggle documents temporal drift and other failures in some configurations.

The card's demonstrations are chosen to make that point at length. One shot from a well-known musical is shown remade 22 ways. A 116-second music video is recast across 69 cuts, and a 101-second fight scene is re-performed with its lead replaced and every opponent turned into a dog, soundtrack intact in both cases. These are curated examples, and the card labels the film footage as third-party material it has no rights to. They show the intended use clearly enough: not generation, but re-shooting without a set.

Longer videos, assembled one window at a time

The gap between one window and a two-minute video is where the second half of the release sits. Remake is built agent-first: an MCP server hands the job to a coding agent, which finds the cuts, paints the keyframes, writes the six-section prompts, renders each window and splices the results back onto the soundtrack. Driven by hand, the same work is one painted frame set and one window at a time.

Viggle provides an RTX 5090 timing for its end-to-end ComfyUI workflow, but not a controlled consumer-GPU benchmark equivalent to its memory-feasibility table. Those are different measurements. Viggle reports approximately 28 minutes to render a 345-frame, 1280×736 window through its ComfyUI worker on a single 32 GB RTX 5090, using roughly 60 GB of system RAM. Its 116-second, 69-cut demonstration reportedly took about three hours on one 5090, compared with approximately 90 minutes using two datacenter workers. These are project-reported workflow timings, not independently reproduced consumer-card benchmarks. A hosted route exists for anyone who wants none of this: the Viggle app runs Remake with no local setup at all.

The 12 GB route, read carefully

The 12 GB figure describes a simulated available-VRAM constraint, not a successful run on a physical 12 GB graphics card. At 832×480, Viggle reports a GGUF configuration under that constraint, while its INT8 configuration is limited to 124 frames, approximately 5.17 seconds at 24 fps. The 1280×736 configuration was not tested at the same memory limit. These results establish what ran under Viggle's constrained B200 setup; they do not establish compatibility or performance on a particular 12 GB consumer GPU.

The 14.3–22.3 GB figures describe individual merged, quantized transformer files, not complete installations. The smallest listed text encoder adds another 15.7 GB, with larger alternatives reaching 51.5 GB, and the workflow also needs video and audio VAEs. The approximately 5.5 GB package contains the two primary LoRAs and supporting files; it does not include the complete MiniMax-H3 inference stack. Likewise, the approximately 144 GB base-model download refers to the full reference setup, not the minimum quantized ComfyUI configuration.

Then there is how the table was produced. Viggle states it plainly, in the same document: the measurements were made on B200 datacenter GPUs, with a second process holding the rest of the card so ComfyUI saw only the stated free memory. The small cards, in the card's own word, were emulated, and because the B200 still reported its full 183 GB, ComfyUI ran in its normal-memory mode rather than the low-memory mode a real small card would trigger. System memory is the other half of the emulation gap: the ComfyUI process used 47 to 55 GB of RAM at the tested resolution. A PC built around a 12 GB card rarely carries that. Viggle explicitly says it has not timed physical consumer cards under the constrained-memory benchmark configurations. The separately reported RTX 5090 workflow timings do not validate the simulated 12 GB result. A real 12 GB card may behave differently because ComfyUI would select a different memory-management mode, and its actual speed remains unmeasured in the published comparison.

None of this makes the quantized files pointless. Weight offloading can make a large model accessible under tighter VRAM limits, but its runtime cost depends on the host system, memory-management path and storage configuration. Viggle's emulation results do not establish that the overhead will be modest on a physical 12 GB card. Viggle documents the flags, the failure mode when activations run out, and the workaround. It does mean "runs on 12 GB" is, as published, a statement about memory arithmetic on a datacenter card, not a tested recipe on the hardware a reader would buy.

What the quality numbers compare

The quality section is careful work, aimed at a narrower question than most readers will assume. Each quantized file rendered the project's two example clips, and the output was compared, frame by frame, against the same pipeline running at full precision. On Viggle's two published examples, INT8 and Q8_0 produce outputs closer to the project's BF16 reference than Q4_K_M under the reported image-similarity measurements. The sharpness measurements also remain relatively close. These results measure differences between numerical formats in the same pipeline. They do not establish how accurately the pipeline preserves a replacement person's identity, maintains motion across cuts or compares with competing video-editing systems. The card itself warns against reading too much into the swap numbers: the same bf16 weights, rounded differently, score 29.6 dB against themselves, so it says to read swap differences of a few dB as noise.

What that test cannot establish is whether the remake succeeds at the task users actually care about. There is no score for whether the replacement person still looks like the painted reference, none for consistency across a cut, and no comparison with any competing tool. The known-failures list is short and specific: a non-humanoid character held in one long take, small artifacts in fine detail, and shots drifting in time when a multi-shot clip is rendered without pinned keyframes. Anyone planning to recast a real performance should treat identity preservation as unmeasured, because in the published material it is.

Viggle says Remake is intended for footage users have the right to modify, and warns that its models can place a real person's likeness into scenes without that person's consent. The model itself does not verify identity, permission or provenance; safeguards in upstream image-editing tools are not a substitute for that check. Viggle also calls for labeling generated output. The weights remain subject to the MiniMax H3 Community License, including its geographic restrictions covering the United States, European Union, United Kingdom and South Korea without prior authorization, along with applicable attribution and commercial-use conditions. The surrounding code is separately licensed under Apache-2.0. Neither license grants permission to use third-party footage or someone's likeness.

Sources

  1. [1] Viggle Research, Viggle Remake model card, Hugging Face (read in full, 8 November 2026)Read source
  2. [2] Viggle Research, COMFYUI.md in the Viggle Remake repository (read in full, 8 November 2026)Read source
  3. [3] Hugging Face API record for Viggle/Viggle-Remake (created 2026-10-22, last modified 2026-11-07, 76,308 downloads at read time)Read source