MiniMax-H3-Image Is on Three Surfaces: What Each One Actually Hands You

The shortest true sentence about MiniMax-H3-Image this week is that it is available in three places: Hugging Face, M​iniMax Code, and M​iniMax's own API. The sentence a buyer actually needs is narrower. Two of those three hand you a request endpoint and a rate card; one hands you 135 gigabytes of weights, a licence to read, and a hardware decision. Those are not three flavours of the same access, and treating them as interchangeable is how a team ends up budgeting a week for something it could have bought per image for two cents.

The model itself is a genuine release rather than a repackaging. M​iniMax put the weights in the Hugging Face repository MiniMaxAI/MiniMax-H3-Image on 10 November 2026 at 14:50 UTC and posted about it at 15:40 the same afternoon; the repository itself dates from 3 November, which is a week of the weights existing privately before anyone could download them. It is a 33.1-billion-parameter diffusion transformer that generates at roughly sixteen megapixels, which is the "4K" in the announcement, and it does text-to-image and reference-guided editing from a single checkpoint. What follows is organised around the one question the announcement does not answer: which surface should you be on.

Three front doors, and only one of them is a download

Start with what each door is, because the difference is structural, not cosmetic.

The API is the conventional path. The model is listed as MiniMax-H3-Image with a Highspeed sibling, on M​iniMax's international and mainland platforms, billed per million tokens in and out rather than per image. The interface is unusually opinionated — six sampling steps, no guidance scale, no negative prompt — and M​iniMax's own reference says a request that asks for anything else comes back as HTTP 400. You are buying a working endpoint with a fixed recipe inside it.

M​iniMax Code and Hailuo AI are product surfaces: the same model behind a prompt box, with the sampling decisions already made and no per-token arithmetic for you to do. Useful for evaluating whether the output is any good; not useful for building anything, because the thing you would build against is not exposed. Note also that M​iniMax Code is a coding-agent product, so image generation there is a side door rather than the main function — do not read "available on M​iniMax Code" as an image API with a code wrapper.

Hugging Face is the third door, and it is the only one that is a transfer rather than a service. You get a repository, a licence file, and a set of weights you now have to make run. Self-hosting is the reason most teams look at an open-weight image model at all; it is also where the arithmetic stops being about the model and starts being about your rack.

The repository is heavier than the headline parameter count suggests

33.1 billion parameters in BF16 is about 66 GB before you count anything else, and "anything else" is where the repository surprises people. The diffusion transformer alone is 66.28 GB. The full download is 68.65 GB, which accounts for the transformer plus the VAE and configuration. The text encoder is not in that figure: MiniMax-H3-Image reuses the Qwen3-VL text encoder from the MiniMax-H3 video repository, reads from layer 50 of it, and that encoder is a separate 66.7 GB pull. Budget roughly 135 GB of artefacts on disk before the first image, in other words, and that is before any framework's own cache.

The architecture is worth a paragraph because it tells you what the model is. Fifty transformer layers, hidden size 5,376, 56 attention heads, feed-forward width 14,336, with three-dimensional multimodal rotary position embeddings. The VAE is a convolutional encoder paired with a 24-layer two-dimensional ViT decoder at 16× spatial downsampling and 24 latent channels — a decoder choice that costs more compute at the end of the pipeline than a plain convolutional decoder would, and is plausibly where some of the fine detail at 4K comes from. The design is described in the model card as the H3 architecture minus audio, which is a fair summary: this is the video model's image branch, shipped on its own.

Two consequences follow. First, a 33B-class diffusion transformer at sixteen megapixels is not a laptop model, whatever the parameter count sounds like next to modern language models; the activation memory scales with output area, and area is the entire point of this release. Second, because the text encoder is shared with the video model, a shop already running MiniMax-H3 has most of the download on disk already. That is a real discount, and it is the kind of thing the "available on Hugging Face" line does not convey.

Four ways to serve it, and one number that does not agree

The model card lists four routes: SGLang, vLLM-Omni, diffusers, and ComfyUI. vLLM's team shipped day-zero support in vLLM-Omni for both NVIDIA and AMD hardware on release day, with native output at about sixteen megapixels, which is a stronger launch signal than the weights existing — someone outside M​iniMax had it running before the announcement was an hour old. Diffusers covers the reference path, and ComfyUI covers the workflow-graph crowd.

The disagreement is worth flagging because it will bite someone. The model card describes editing with up to 16 reference images, addressed positionally as <Picture 1> through <Picture 16> in upload order. The vLLM-Omni release recipe for the same model documents up to 9 images per request. Both can be true at once — a framework's serving limit and a model's trained capacity are different numbers, and a batching or memory constraint in the serving stack will bind first — but if your workflow needs twelve references, the honest answer today is that the capability exists and the documented serving path may not carry it. Test the number on your stack rather than trusting either document.

The same caution applies to the prompt window. The card accepts up to 32,000 characters, of which roughly the first 4,096 tokens are what the model actually conditions on. A long prompt is not rejected; the tail is simply not doing work. Anyone porting a detailed art-direction prompt from a language-model habit will find that out the expensive way.

The sampler is a constraint you inherit, not a setting you tune

Six steps, no classifier-free guidance, no negative prompts. That is not a default with room above it; the API rejects other step counts and guidance values outright. The model is distilled to run in six forward passes, and the whole reason a 33B transformer can return a sixteen-megapixel image fast enough to be useful is that distillation.

For the API path this is invisible and fine. For the self-host path it is the single most useful number in the spec sheet, twice over. It caps the compute per image at six transformer evaluations rather than the twenty-five to fifty a non-distilled model would need, which is what makes sixteen megapixels practical at all. And it means the usual self-hosting tuning loop — try more steps, add guidance, add a negative prompt, iterate — does not exist here. If output quality disappoints, the levers are the prompt and the references, not the sampler. Teams that budget a week for "tuning the model" should budget it for prompt work instead.

What each path costs, in the units it is actually billed in

The API bills tokens, and the card's own worked examples are the clearest way to read that. A 1,024×1,024 text-to-image request is $0.02179. A 2,048×2,048 request is $0.02333 — 1.07 times the price for four times the pixels, because the token count grows far more slowly than the area. A 4,096×4,096 request is $0.06879 list, and $0.03439 under a limited-time 50% discount that runs until 17 November 2026 at 16:00 UTC and requires the delivered image to be at least 16,600,000 pixels. Standard-tier rates are $2.30 per million input text tokens, $1.50 per million input image tokens and $3.80 per million output image tokens; the Highspeed tier keeps the input rates and charges $7.60 for output.

Read those three numbers together and the pricing argument for 4K mostly evaporates. Four times the pixels for 1.07 times the money at the 2K step is a gift; going from 2K to 4K costs about three times as much for the same fourfold area gain, and only the discount brings it back near the 2K rate. If your use case does not need 4,096 pixels a side, the 2K tier is where this model is cheap.

OrcaRouter does not serve MiniMax-H3-Image — there is no route for it here, and the CTA on this piece points at the video sibling, minimax/minimax-h3, which we do route. What we do offer is relevant to the day the route exists: 0% markup with provider list price passed through, which means a vendor price change like that 4K discount reaches your bill on the same day it reaches the vendor's page, and automatic failover if a provider path degrades. Until then, the comparison that matters is API spend against your own hardware, and no routing layer changes that arithmetic.

Self-hosting, priced honestly

Nobody can quote you a per-image self-host cost without knowing your GPU, because the dominant term is whether 135 GB of weights fit in memory or have to be offloaded. What can be said precisely: the six-step sampler fixes the compute, the sixteen-megapixel output fixes the activation budget, and both are large. A single 80 GB card will hold the transformer but not the transformer plus the Qwen3-VL encoder at full precision, so the realistic configurations are multi-GPU, or offloading the encoder, or a quantised transformer with a quality question attached. Add power, add the engineer-week to get SGLang or vLLM-Omni serving properly, and the break-even against $0.02333 per 2K image is a volume number in the hundreds of thousands of images, not the dozens.

Which is the argument for the API in most cases and the argument for the weights in a few: a shop that needs the model inside its own boundary for data reasons, or one already running MiniMax-H3 and holding the encoder, or one generating at a volume where the fixed cost amortises. Everyone else should price the API first and self-host only if the boundary genuinely requires it.

Reading the licence before the download, not after

The weights are released under the MiniMax-H3-Image Community License Agreement, which is not Apache 2.0 and not MIT. "Open-weight" is accurate; "open-source" is the word that gets teams into trouble, and this is the point in the process where a lawyer should read the actual file rather than a blog post — including this one. The practical question is commercial use at scale and whether the licence carries terms that attach to your product, and that question has an answer in the repository that no summary substitutes for.

There is a second, smaller artefact worth knowing about: M​iniMax ships a Context-IR component for the model, and an optional prompt-expander model, MiniMax-H3-Image-PE. The expander explains part of why the model tolerates long, detailed prompts; it is optional, it is separate from the 68.65 GB, and it is the kind of thing you find in a repository listing rather than an announcement.

What to check on your own stack this week

• References — confirm whether your serving path honours 16 images or the 9 the vLLM-Omni recipe documents, with a real request rather than a document read.

• Effective area — the model will run below sixteen megapixels, and the configuration exposes a minimum generation area defaulting to 4,194,304 pixels. Test the small end if your use case is thumbnails, because a model this size may not be the cheap option at 1K.

• Memory — measure peak VRAM at 4,096×4,096 before buying hardware. Six steps is cheap compute; the activations are not.

• Discount clock — if 4K is the plan, the 50% rate ends 17 November 2026 at 16:00 UTC, and whether you are on the API or your own metal decides whether that deadline matters to you.

• Licence — read it. The download is 135 GB and the decision is reversible; the licence is neither.

The interesting thing about this release is not that a good open image model appeared — it is that for the first time in a while, one appeared with the weights, the framework recipes and the hosted endpoint all landing in the same week. That is a stronger signal than a benchmark chart, because it means the thing runs. Whether you should run it, or call it, depends entirely on which of the three doors you walk through, and those three doors are much further apart than the announcement makes them sound.