Self-host MiniMax H3 or use an API: a decision table

Run MiniMax H3 yourself if you need control over weights, LoRAs or data location and can operate GPUs. Call a hosted API if you want a finished MP4 per request, billing and retries handled for you. The MiniMax model page, read 2026-10-03, says H3 was released on Jul 31, 2026 as an open-weight omni-modal model.

What the vendor page and search suggest

The MiniMax page confirms the open-weight release. Search autocomplete for the model that day suggested four follow-ups: Hugging Face, ComfyUI, LoRA and local. That is a hint about what people want to do with the weights, not a measure of how many succeed.

The decision table

The right column describes how Sume documents its own hosted route. It is not a claim about what any particular local setup costs.

How a hosted job behaves

On Sume the call is asynchronous. You submit to POST /v1/videos, receive a job id and polling URL, then poll GET /v1/videos/{jobId} until completed and download from unsigned_urls. The jobs guide says to use exponential backoff and never resubmit a paid request just because a local process timed out.

The catalog entry minimax-h3 accepts 5-15 seconds at native 480p or 768p. If your self-hosted build supports a different range, that is a difference you own.

Questions to settle first

Before you commit either way, answer four questions in writing. How many seconds of video do you need per month, and how spiky is that demand? Which team owns GPU operations, and what happens at 3 a.m. when a node fails? Does any input data have to stay on your own hardware? And which output limits do you need, such as duration and resolution?

Hosted catalogs state their limits per model, so you can compare them to your answers directly. For self-hosting, you will establish the same limits by test.

A reasonable split

Many teams prototype against an API to settle prompts and durations, then decide whether volume justifies self-hosting. Moving later costs you a client rewrite, not a prompt rewrite, if you keep your own request model thin. Keep a record of the Sume job_id next to each asset so you can compare outputs from both paths.