MiniMax-H3-Image vs Meta Muse Image: Where the Open-Weights Lead Stops

There is one comparison that MiniMax-H3-Image does not win, and it is the one against a model that costs a penny. Meta Muse Image, live since 7 July 2026 on Meta's own Model API at a flat $0.01 per generated image with search grounding folded into that price, sits at 1,127 Elo on AA-Image-T2I v2.1 over 9,061 votes — thirteenth, sixty-one points clear of MiniMax-H3-Image's 1,066 over 3,206 votes at twenty-fifth, with intervals that do not come close to touching. On the editing board the two are effectively tied: MiniMax-H3-Image at 1,138, Muse Image at 1,128, ten points apart with heavily overlapping error bars. And MiniMax-H3-Image costs $0.02179 to $0.06879 an image against the penny.

So the model that leads every downloadable competitor on both boards arrives at this matchup with a tie it pays twice as much for and a loss it pays sixty-one Elo for. That is worth sitting with, because it is the comparison that tells you what "best open-weights image model" is actually worth.

Ten points and sixty-one, and why the second one matters more

The editing tie is a genuine tie and should be reported as one. MiniMax-H3-Image's interval runs 1,122 to 1,154; Muse Image's runs 1,117 to 1,139. They overlap across most of their width, and the board's own rank ranges — ninth to eighteenth against thirteenth to twenty-first — are a longer way of saying the same thing. Nobody can claim an editing advantage here that survives a second read of the data.

The generation gap is a different kind of number. 1,066 with an interval topping out at 1,081 against 1,127 with an interval bottoming out at 1,116 — thirty-five points of clear air between the two intervals. That is not noise, and it is not a small effect: on a board of a hundred and fourteen models it is the difference between the top quarter and the second quarter. On plain text-to-image, Meta's penny model is better, and the data says so unambiguously.

Which inverts the story H3-Image's launch told. The model was presented with sixteen megapixels and sixteen positional references, and the inference everyone drew was that this was a serious editing-capable generator. The boards agree about the editing half and disagree about the generation half. What M​iniMax built is a very good editor that also generates, not a generator that also edits.

What a penny actually buys, and where the arithmetic breaks

Meta's billing unit is documented with unusual precision: the image, not the token. The developer documentation says the model is billed at a flat $0.01 per generated image and states directly that Muse Image "isn't priced per token"; the usage block it returns carries input and output token counts that are informational only. Two consequences follow, and both are operational rather than cosmetic. Failures are not billed — images that fail to generate, or that safety filtering removes before they are returned, are not counted. And search grounding, which is a live web lookup plus tool calls behind a single output, is inside the per-image price rather than billed alongside it.

Run that against M​iniMax's card on a job of ten thousand images. Muse Image: $100 flat, regardless of how many retries died. MiniMax-H3-Image at its 1K tier: $217.90, and every failed request that still produced a billed output is on your invoice. At the 4K tier where the model actually delivers sixteen megapixels, $687.90 list or $343.90 during the current discount, which expires 17 November 2026 at 16:00 UTC and applies only when the delivered image is at least 16,600,000 pixels. The gap is not a rounding difference at any tier; it is the difference between a job you can afford to attempt and one you budget for.

But the two are not selling the same artifact, and this is where the comparison has to get specific rather than stay at the per-image level. MiniMax-H3-Image publishes its canvas at every aspect ratio: 4096×4096, 4736×3552, 5024×3360, 5472×3072, 6272×2688, with a 20-megapixel API ceiling. Meta publishes no pixel dimension for Muse Image at all. Its documentation is explicit that the size parameter on the images endpoints "sets aspect ratio only, not exact pixels" — do not read it as a resolution guarantee. There is no published megapixel figure to divide the penny by, which means the per-megapixel comparison that would settle this cannot be computed from documentation. Treat that as a fact about the two vendors' disclosures, not as a defect in either product.

The closed model is the easier one to deploy, which is the inversion

Here is the part that makes this matchup more than a price list. Meta Muse Image is proprietary. There are no weights, no model card, no licence to read, and Meta's developer documentation draws the line explicitly: the Muse family models you call over Model API are served, and the one open-weight model in the family, Muse Glimmer, is a different model distilled from M​use Spark rather than an open release of Muse Image. Calling it is a model-string change on an O​penAI- or Anthropic-compatible SDK.

MiniMax-H3-Image is downloadable, which normally reads as the freedom option. Under the MiniMax-H3-Image Community License Agreement it excludes the European Union, the United Kingdom, the Republic of Korea and the United States — the model, not merely its outputs — requires separate written authorisation for hosted service at any revenue level and above a million dollars of annualised revenue otherwise, requires the model name to be displayed prominently wherever it is used, and forbids using its outputs to train other models.

Put the two side by side for a team in Austin or Manchester and the usual intuition is backwards. The proprietary model is the one they can use on Monday. The open-weights model is the one that needs a signature from M​iniMax before it can go in a product, and possibly a different conversation entirely. That is an odd thing to write on a blog that generally argues for open weights, and it is true, so it is here.

For a team in Singapore or São Paulo, the licence clause is inert and the calculation reverts to the one above: a penny against two cents for a tie on editing, and a penny against two cents for a loss on generation. Still Meta, on these numbers, unless the pixels are the requirement.

Two ways of removing the knobs

Both models took away your sampling controls, and they did it in opposite directions. MiniMax-H3-Image distilled a 33.1-billion-parameter transformer to six sampling steps with no classifier-free guidance, and the API rejects any other step count or guidance value with HTTP 400. There are no negative prompts. The only things you vary are the prompt — up to 32,000 characters, of which roughly the first 4,096 tokens take effect — and the references, up to sixteen addressed positionally as <Picture 1> through <Picture 16>.

Meta Muse Image removed the knobs by adding a layer above them. In Meta's words the model "reasons before it renders": it invokes search and coding tools, self-refines its own generations, and improves through scaling test-time compute. Reference images go up to ten in a single request, and the agentic behaviour is switchable, which makes the reasoning depth the lever for cost and latency rather than the sampler. Meta describes a pairing with its M​use Spark reasoning model so that the two share tools and plan jointly, which is how the documented multi-part outputs — animated GIFs, pages with embedded images, small interactive games — are produced.

The practical difference shows up in failure. When MiniMax-H3-Image gets an edit wrong, there is a single pass to interrogate and no second opinion inside the call; the fix is a better prompt or a better reference. When Muse Image gets one wrong, the failure may be in the reasoning path rather than the render, and turning agentic behaviour up or down is the first thing to test on your own prompts rather than take on faith. Neither is better. They are different debugging surfaces, and knowing which one you are on saves an afternoon.

What Meta will not tell you

The penny comes with a large documentation gap, and it belongs in the same breath as the price. Meta has not published rate limits for Muse Image that we could read — the rate-limits page on its developer site returned a shell with no figures. There is no published latency profile, no success rate, and no independent evaluation of the agentic loop under production traffic. There is no benchmark of instruction-following or edit fidelity from any independent party, and Meta's own benchmark graphic carries no readable figures. If throughput matters to your design, you will discover the envelope from the API rather than from the manual.

Provenance has the same shape. Muse Image carries Content Seal, an invisible watermarking system that Meta says stays intact through cropping, compression, resizing and screenshots, with a detection tool in preview. Read the scope carefully: Meta describes the mark as being carried by images created in the Meta AI app and on meta.ai — the consumer surfaces — and neither the model page nor the API documentation says whether images generated through Model API carry it. Assume it does not travel with an API-produced file until you have tested output from your own account. Independently, the one reported test of the detector, from Reuters, found it failed to verify a majority of watermarked images. M​iniMax, for its part, publishes no provenance or watermarking system for H3-Image at all, which is a different kind of answer to the same question.

M​iniMax's own gap is latency in the other direction: the vendor claim is sixteen megapixels in ten seconds, and there is no published p50, p95 or ceiling per aspect ratio behind it. Krea publishes a per-job ceiling for its slowest mode; M​iniMax publishes a best case. Meta publishes neither. Three vendors, three different levels of disclosure about the same operational question, and the one with the most detailed price is not the one with the most detailed performance data.

How to decide, in one pass

If your output is going to the web, a feed, a listing, or a client deck at sizes under about four megapixels, the answer on these numbers is Meta Muse Image. It is measured ahead on generation, tied on editing, cheaper per call by a factor of two to seven, bills failures at zero, folds search into the price, and needs no licence review in the four jurisdictions that M​iniMax excludes. The documentation gaps are real and they are the kind of thing you resolve with a week of your own testing rather than a procurement cycle.

If your output has to hold detail at print size, or be cropped three ways out of one master, the answer is MiniMax-H3-Image and the price is irrelevant because the alternative cannot produce the asset. Sixteen megapixels native at every aspect ratio is a category the penny model does not compete in, whatever its preference score, and the reference system's sixteen positional slots let you compose several supplied images into a new scene rather than edit one — which is a facility no other model in this comparison documents at that scale.

If you are in the EU, the UK, Korea or the US and you need the pixels, the honest answer is that you are waiting — on a written authorisation from M​iniMax, or on a model that returns that much canvas without one. Both are plausible within a quarter. Neither exists today.

Where a router fits, and where it does not

OrcaRouter serves neither model. MiniMax-H3-Image has no route on our catalogue, and Meta Muse Image is reached through Meta's own Model API — not ours. Note also that the Muse models on our catalogue carrying similar names are chat models, not this image model, and nothing here should be read as a route to it. What we do carry from M​iniMax's H3 family is the video model, minimax/minimax-h3, at the provider's list price with 0% markup passed through.

The one place routing genuinely helps in this comparison is the part where the numbers are least settled. MiniMax-H3-Image is four days old with a sixteen-point interval on its editing row and a licence that varies by country; Muse Image has four months of votes and an undocumented operational envelope. Neither is a thing to wire in as a hard dependency. A primary route with an automatic failover to a second measured model is how you give a new entrant real traffic without betting the job on it — and when the comparison above is a tie within error bars, that is the honest production architecture rather than a hedge.

A penny against two cents looks like an easy call until the first model can return four times the canvas and the second can be switched to reasoning depth. It stops looking like a price question at exactly the point where you work out which of those two properties your output actually depends on.