MiniMax H3 Regenerate 2K: What Qualifies and What It Costs

MiniMax H3 Regenerate 2K is a second model pass for a compatible 768P video made by MiniMax-H3. It is not a general video upscaler, and it does not accept an H3 Max, Turbo, Highspeed, Lite, edited, audio-track-stripped, or otherwise arbitrary MP4.

That one distinction answers most failed requests. If you still have a recent MiniMax task ID, regeneration can reuse the original task. If you only have the 768P file, you must send the exact final prompt and every original conditioning input again. Either path creates a new asynchronous task whose only output resolution is 2K.

A five-second job can cost $0.65 before extra inputs

Checked October 28, 2026, MiniMax's direct rates make the basic arithmetic unusually clean. A text-only five-second H3 generation costs $0.40 at 768P. Regenerating that result costs another $0.25, for a combined $0.65. A direct five-second H3 request at 2K is also $0.65.

This equivalence applies to a text-only job, or an image-conditioned job that stays within the free image allowance. It is not a universal total. The MiniMax pricing table says regeneration bills the original conditioning inputs again:

• output is $0.05 per regenerated second;
• reference video is $0.05 per input second;
• the first five images are free, then each additional image is $0.025;
• audio input is free.

The original 768P task remains a separate charge. For example, if that task used a seven-second reference video, the regeneration pass adds $0.35 for the reference video as well as its 2K output charge. Save the original request manifest; the base MP4 alone is not enough to reconstruct an honest quote.

Run this eligibility check before uploading anything

The official /v2/video_regeneration contract currently accepts only MiniMax-H3. A local-file request needs one unmodified 768P H3 result that passes all of these checks:

Do not “prepare” the source by trimming one frame, replacing its audio, changing its frame rate, or running it through an editor. Those operations can make an H3 output fail the source contract even when the picture still looks identical.

The model-name check is equally important. MiniMax lists H3 Max under its extended models and H3 Regeneration under a separate base-H3 section. A 768P H3 Max result is not made eligible just because its resolution and duration look correct. The H3 versus H3 Max guide explains why those model families should not be treated as interchangeable.

Choose one input path, never both

There are two ways to start the request. They solve different storage problems.

Use source_task_id while the original task is still available

This is the smallest request because MiniMax already has the source result and its context.

{
  "model": "MiniMax-H3",
  "source_task_id": "YOUR_SUCCEEDED_TASK_ID",
  "resolution": "2K"
}

The source task must belong to the current account, have succeeded status, remain queryable, and have been created within the seven-day query window. MiniMax also marks this path as requiring whitelist access. A saved task ID is therefore useful, but it is not a permanent regeneration archive.

Use base_video when you have the file and the original manifest

This path sends exactly one source video plus the same inputs that produced it:

{
  "model": "MiniMax-H3",
  "content": [
    {
      "type": "text",
      "text": "THE_FINAL_PROMPT_ACTUALLY_SENT_TO_H3"
    },
    {
      "type": "video_url",
      "video_url": {
        "url": "https://cdn.example.com/original-h3-768p.mp4"
      },
      "role": "base_video"
    }
  ],
  "resolution": "2K"
}

If the 768P generation used a first frame, last frame, reference image, reference video, or reference audio, put the same assets back into content with the same roles and order. The request must contain exactly one item whose role is base_video.

Do not send source_task_id and content together. The endpoint requires exactly one route.

“Same prompt” means the post-Context-IR prompt

The base-video path has an easy-to-miss rule: send the final prompt that H3 actually received, not the short prompt written before H3 Context-IR expanded it.

That makes request logging part of the video pipeline. Store these beside every 768P result:

model and resolution
final prompt sent to the generation model
ordered input URLs, file IDs, and roles
source task ID and creation time
output URL plus an immutable copy of the original MP4

If a reference asset expires or its order is lost, the 768P file may still play while the full regeneration request can no longer be reconstructed. The H3 Max API workflow guide covers the same queue and provider-result ownership problem for browser products, even though the exact model route here is base H3.

Regeneration is not conventional upscaling

A normal upscaler starts from the finished pixels and estimates a larger image. H3 regeneration receives the base video together with its generative context, then runs a 2K model pass. That is why the endpoint asks for the original prompt and references rather than accepting any MP4.

It also means “same video, just bigger” is too strong a promise. The route is designed around the original H3 result, but the documentation does not promise bit-for-bit motion, faces, text, sound, or timing after the new pass. Keep the 768P master, compare the complete clip, and approve continuity and audio again.

Choose the two-pass route when you want to review a cheaper 768P H3 result before committing to 2K and can preserve the complete request context. Choose direct 2K when you already know the shot deserves a 2K request and do not need a 768P approval gate. For text-only work the current output arithmetic is the same; workflow and input charges decide the better option.

Diagnose a rejected or surprising request

The endpoint rejects a normal MP4

That is expected. Confirm the source was generated by MiniMax-H3 at 768P and still has its original audio track, frame rate, dimensions, and frame count.

A task ID worked last week but fails now

The task-ID route uses a seven-day query window. Use the base-video route only if you saved the unmodified file and exact original manifest; otherwise the job is no longer reproducible.

The regenerated shot changes more than expected

Check that the text is the final post-Context-IR prompt and that every first, last, image, video, and audio reference matches the original request in both role and order. Do not “improve” the prompt during regeneration.

The estimate is higher than $0.05 per second

$0.05 per second is the regenerated output line, not always the whole second task. Add chargeable original input video and images beyond the first five. Then keep the original 768P generation charge separate.

A 768P H3 Max video passes the media checks but is still rejected

The media values are necessary, not sufficient. The regeneration endpoint currently names MiniMax-H3 as its supported model; H3 Max is a different route.

MiniMax H3 Regenerate 2K FAQ

Can I regenerate any 768P video to 2K?

No. The source must meet the MiniMax-H3 768P output contract. This is not a general-purpose video processor.

Can I regenerate an H3 Max or H3 Max Turbo clip?

Not through the current MiniMax-H3 regeneration contract. Its supported model is MiniMax-H3.

Is 2K regeneration just an extra $0.05 per second?

Only when the original inputs add no regeneration charge. Reference video and images beyond the free allowance are billed again, and the original 768P generation was already a separate task.

Can I change the prompt during regeneration?

The base-video contract asks for the exact final prompt and original inputs. Changing them breaks the request's connection to the source context and may change or invalidate the result.

Does AI Live Generator offer H3 Regenerate 2K?

No. This site's main generator uses H3 Max Turbo for 480P and 768P text or first-frame video. The regeneration workflow described here belongs to MiniMax's separate base-H3 API.

Treat the final prompt, references, task ID, and untouched 768P file as one production asset. If any part is disposable, the 2K option is disposable too.