MiniMax-H3-Image-PE: MiniMax Shipped a 27B Prompt Expander for Its Image Model and Told Nobody

There is no launch post for MiniMax-H3-Image-PE. There is no entry on M​iniMax's news feed, no blog, no changelog line, no social post — on 2026-11-11 the company's news index lists H3, M3.1 Flash, Speech 2.8 and Music 3.0, and nothing about images at all. What exists instead is a Hugging Face repository whose first commit is timestamped 2026-11-10 at 14:38 UTC, a model card that never states a release date, and a license file dated November 10, 2026. That is the whole announcement. MiniMax-H3-Image-PE is a prompt-expansion model — a caption writer — built to feed its sibling MiniMax-H3-Image, the open-weights 33.1B image generator M​iniMax published on 2026-11-03. The image model got eight days of quiet; its prompt expander has had one. Everything below that carries a number comes from those two repositories, the license text, or M​iniMax's own API documentation, and where something is not knowable from those sources it is marked as such rather than guessed. MiniMax-H3-Image and MiniMax-H3-Image-PE are not on OrcaRouter as of 2026-11-11, so this is a self-hosted evaluation. the catalogue The rest of the catalogue is one key away when you want to compare the expansion against a text model you already trust.

The short version, for anyone deciding whether to care: this model does not draw anything. You give it a sentence, it gives you back a long English description of the image you meant plus a recommended aspect ratio, wrapped in a two-key JSON object. A 27B model exists to write that paragraph because MiniMax-H3-Image is unusually fussy about its input — the parent card says it "expects a detailed English description of the whole image" and truncates anything past 4096 tokens. If you have ever typed six words into an image model and gotten six words' worth of thinking back, that gap is what this repository is trying to close, and on 2026-11-10 M​iniMax open-sourced its side of the fix.

What is actually in the repo, and what the timestamps say

The repository is MiniMaxAI/MiniMax-H3-Image-PE on Hugging Face. Its creation timestamp is 2026-11-08 15:35 UTC; its first commit — unhelpfully titled "Init MiniMaxAI/MiniMax-H3-Image-PE" — landed two days later, on 2026-11-10 at 14:38 UTC, authored by M​iniMax staff accounts ryanlee-dev and 500kg. A second commit followed 38 minutes later adding a Diffusers usage section, and that one is a pull request merged from Hugging Face's own multimodalart, which tells you the diffusers integration was contributed from outside M​iniMax rather than shipped by it. Three pull requests were opened against the repo on its first day, all closed or merged. None of them is an announcement.

What is inside is a checkpoint in four safetensors shards totalling roughly 17.9 GB, a tokenizer, a chat template, a quantisation config, and — the part that matters more than the weights — a prompt/ directory containing the actual system prompt, task prompt and request parameters M​iniMax uses. There is also a single client script, scripts/expand_prompt.py. The repository declares 27.4B parameters in total across two tensor types: about 25.6B stored as U8 and 1.76B left in BF16. That split is explained by the quantisation config, which records NVFP4 with a group size of 16 and lists the modules held out of quantisation — the embedding table and the convolution and gating projections inside each linear-attention block.

The base model is stated plainly on the card and in the metadata: Qwen3.8-27B, the Apache 2.0 vision-language model Q​wen published on 2026-08-05. So the architecture is Q​wen's, the weights are M​iniMax's fine-tune, and the packaging — NVFP4 rather than BF16 — is M​iniMax optimising for deployment rather than for redistribution fidelity. The card says the FP4 weights occupy about 19 GiB of GPU memory and that GPUs with native FP4 support run the NVFP4 weights directly while others fall back to bitsandbytes.

What it does, precisely

Two workflows live in the repo, and they are not the same deal. This is the single most important thing to understand before you download 18 GB.

• Text-to-image PE — you get everything: the fine-tuned weights, the system prompt, the task prompt, the request parameters, and a working client. This path is complete and runnable today.

• Image editing PE — you get a prompt and a message-assembly example. No weights. The card says it outright: "Image editing PE is still under development; this release provides its prompt only." You are expected to run that prompt through a vision-language model of your own choosing.

The text-to-image path takes your instruction, expands it, and returns JSON constrained by a schema to exactly two keys. The output for a test prompt — "An orange tabby cat sleeping on a sunlit windowsill" — is a single sentence about warm photographs and soft afternoon light, plus the ratio "3:2". The schema is strict, with additionalProperties set to false, and the ratio field is an enum of ten values: 1:1, 5:4, 4:3, 3:2, 16:9, 21:9, 4:5, 3:4, 2:3, 9:16. There is no free-text ratio, no "auto" token in the output, and no way for the model to answer with anything other than one of those ten strings. That is a deliberate design choice and it maps directly onto the parent model's published size table, which lists exactly those ratios with pixel dimensions from 4096×4096 at 1:1 up to 6272×2688 at 21:9.

The ratio decision is not a vibe. The released task prompt spends several hundred words on a strict precedence order: an explicit final canvas wins first, then the requested deliverable (a poster is vertical, a slide header is horizontal, an avatar is square), then the primary composition of the subject, then optional context — with an explicit warning that "a generic room, park, forest, sky, or cinematic background must not turn a focused subject horizontal." The prompt also forbids inventing a platform: you do not get to assume Instagram. And it distinguishes a depicted scene from a communication artefact — a dashboard, poster, packaging, technical diagram or multi-panel composite gets built as an information architecture rather than as a scene containing the requested objects. For anyone who has watched an image model turn "quarterly results slide" into a photograph of a meeting room, that distinction is the interesting part of this release.

Why spend 27B parameters on a caption

The answer is in the parent model's documentation, and it is more interesting than the prompt expander itself. MiniMax-H3-Image is a 33.1B dense single-stream diffusion transformer, 50 layers, hidden size 5376, 56 attention heads, reading hidden states from the 50th layer of a full Qwen3-VL text encoder inherited unchanged from MiniMax-H3. That text encoder is 66.7 GB and is not in the image repository — you download it separately from the video model repo. The checkpoint is distilled to six sampling steps with no classifier-free guidance, and the API enforces this: any num_inference_steps other than 6 and any guidance_scale other than 1 returns HTTP 400, and negative_prompt is rejected outright. There is no dial to turn.

When there is no dial, the prompt is the control surface. That is the design logic connecting the two repositories: a six-step distilled sampler with no negative prompt has very little room to interpret a short instruction, so M​iniMax moved the interpretation into a separate model that can think before it writes. The hosted equivalent is an API endpoint called H3-Image-Context-IR, which does the same job server-side — accepts up to 32,000 characters of prompt and one to sixteen reference images, returns a revised prompt and a chosen ratio, and bills by converting the expansion model's input, output and thinking tokens into text tokens. MiniMax-H3-Image-PE is that endpoint's local escape hatch, and the parent card recommends exactly that usage: run the PE, save its expanded_caption into the generation call, and skip paying for enhancement twice.

The request parameters released with the PE are worth reading as a statement of intent rather than as tuning advice. Temperature 1.0, top_p 0.95, top_k 20, a 4096-token budget that includes thinking, and reasoning_effort set to "xhigh", with thinking enabled and preserved. M​iniMax is running its caption writer in maximum-deliberation mode and constraining only the final serialisation, not the reasoning. Serving that means SGLang 0.5.23 or newer with XGrammar 0.2.7 or newer, the q​wen3 reasoning parser, and constrained JSON decoding — or the Diffusers modular-blocks route the card documents. One caveat on that second route: the blocks repository the card points at, diffusers/minimax-h3-image-pe-blocks, returned HTTP 401 when checked on 2026-11-11, so it was not publicly readable at the time of writing. The card's Diffusers section may well be ahead of the artifact it depends on.

The license is the part that will actually stop people

MiniMax-H3-Image-PE is not separately licensed. The card states it "is part of MiniMax-H3-Image and is accordingly subject to" the MiniMax-H3-Image Community License Agreement, and the license file carries a date line reading "release date/License date: November 10, 2026." Read that carefully, because it means the prompt expander's license date and the parent image model's publication date are eight days apart while the license itself is one document governing both.

Three clauses matter more than the rest, and none of them is the usual "open weights" story:

• Territory — the grant applies only within the "Applicable Territory", defined as worldwide excluding the European Union, the United Kingdom, the Republic of Korea and the United States of America. This is a territorial exclusion, not a use restriction, and it is stated in the definitions rather than buried in an appendix.

• Commercial scale — Section IV requires separate prior written authorization if your annualised revenue, or that of your affiliates, exceeds 1 million USD, or if you provide a hosted service to third parties at all. The second condition has no revenue floor.

• Interface attribution — the same section requires you to prominently display "MiniMax-H3-Image" on the user interface of any commercial product or service using the works.

There is also a redistribution condition requiring a NOTICE file with a specific copyright line, and a Section V obligation to maintain safeguards against violating outputs with a reporting mechanism and a duty to act on good-faith reports. None of that is unusual for a community license in 2026. The territorial exclusion is the one that will decide, for a lot of teams, whether the 18 GB download is even worth starting — and it is the clause most likely to be missed, because the Hugging Face model page surfaces it only as "other" with a link.

What is not knowable yet

Being clear about the boundary is more useful than filling it in.

• No benchmark numbers. Neither card publishes a single score. The parent makes only qualitative claims — "the strongest instruction following among open-source models", "state of the art" — and no independent evaluation of MiniMax-H3-Image, or of its prompt expander, was found as of 2026-11-11. There is no Elo, no preference win rate, no expansion-quality comparison against the hosted Context-IR endpoint.

• No evidence the editing path works. The edit prompt is thoughtful and unusually specific — it requires the caller to supply each reference image's reduced W:H ratio, tells the model never to estimate the source ratio from a preview, and instructs it to construct the intended target rather than pretend to have seen a hidden result. But no weights ship for it, so nobody has measured whether a general VLM follows it as well as the fine-tune presumably would.

• No announcement, therefore no stated intent. Whether this is a permanent commitment or a byproduct of the image launch is not stated anywhere. The repository has no roadmap, no model index entry, and no discussion from M​iniMax explaining why the expander was split out rather than folded into the image checkpoint.

• The download numbers are too small to read. MiniMax-H3-Image showed 667 downloads and 136 likes on 2026-11-11, eight days after publication. The PE model showed 0 downloads and 7 likes. On a repo that is one day old, that is a floor, not a verdict — but it does mean nobody has published a field report yet.

Where this fits if you are actually building something

The practical question is not "is this a good model" — nobody can answer that yet — but "what does adopting it commit me to." Three things, concretely. You commit to running two models instead of one: an 18 GB expander plus a 68.65 GB image checkpoint plus a 66.7 GB text encoder you likely already have if you run MiniMax-H3. You commit to a fixed decode budget of 4096 tokens including reasoning, which at a request timeout the API documentation sets at 600 seconds is not a latency you can hide behind an interactive UI without care. And you commit to a license whose territorial scope excludes four major markets.

The mitigation for the first two is the same one that applies to any model you have not measured yourself: put it behind a routing layer rather than into a hardcoded call path. This is the case routing is built for — the expander is a text-generation model behind an OpenAI-compatible /v1/chat/completions endpoint, so it can sit alongside everything else on one key, and a routing rule can send long or structured prompts to it while a shorter path handles the rest. If the expansion turns out to degrade a particular workload, failover moves that traffic without a redeploy. That is also the honest way to evaluate an unproven model: run it on a slice, keep the old path warm, and let the comparison decide. One clarification worth stating plainly, since it is easy to assume otherwise — MiniMax-H3-Image and MiniMax-H3-Image-PE are not on OrcaRouter's catalogue as of 2026-11-11, so this is a self-hosted evaluation, not a call we can make for you. What the catalogue does carry is M​iniMax's H3 video model and the M3.x text line at provider list price with zero markup passed through, which is the same arithmetic that applies the day an image endpoint arrives.

For the third — the territory clause — no amount of engineering helps. If you are in the EU, the UK, Korea or the US, the license does not grant you the rights it grants everyone else, and M​iniMax's own remedy is to contact them for a separate grant "based on robust controls and guardrails." That is a business conversation, and it should happen before the download, not after.

What to watch

Two signals would turn this from a repository into a release. The first is an announcement: a blog post, a model-index entry, a mention on M​iniMax's news feed. Its absence is currently the most informative thing about the launch, and its arrival would clarify whether the PE is meant to be the default local path or a stopgap. The second is the Diffusers blocks repository becoming publicly reachable — right now it returns 401, and until it resolves, the "run it locally through Diffusers" route documented on the card is a claim rather than a path.

In between, the thing to actually read is the task prompt. It is a few hundred lines of plain English describing how to decide what an image is for, and it is the most concrete artefact M​iniMax has published about how it thinks image prompts should work. You can learn more from it in ten minutes than from any benchmark table, and unlike the weights, it costs nothing to read.