MiniMax-H3-Image vs Krea 3 Ultra: Eight Seconds Against Several Minutes

Krea 3 Ultra is not a model you call by name to get a picture. It is a thinking mode — thinking_mode: "ultra" on Krea's existing krea-3 image endpoint — which generates several candidate edits, reviews them against your prompt and your references, and returns the one it judges best. Krea describes a job as taking "several minutes", with a ceiling around ten, or sixteen at low priority. MiniMax-H3-Image, whose weights went up on 10 November 2026 at 14:50 UTC, went the other way entirely: a 33.1-billion-parameter transformer distilled to six sampling steps with no classifier-free guidance, and a vendor claim of sixteen megapixels in ten seconds. One product sells deliberation. The other sells a single pass at the largest canvas in its class.

Neither latency claim has been independently measured, which is the first thing to be clear about. But the two are not symmetric in what they leave you able to check: Krea publishes a per-job ceiling, so you can plan against the worst case; M​iniMax publishes a best case, and there is no published p50, p95, or ceiling per aspect ratio that we could find. That difference matters more than the ten seconds.

Ultra is a flag, and the flag changes what the endpoint will do

Setting that mode has consequences that are easy to discover the hard way, all documented and all worth reading before a first call:

• Size — Ultra is 2K only. It will not output below 2K, and it does not go above it.

• Input — Ultra requires at least one entry in image_urls. Text-to-image is out. There is no prompt-only path to Ultra, which is also why you will not find it on Artificial Analysis's text-to-image board at all: only Krea 2 Large, Krea 2 Medium and Krea 2 Medium Turbo appear there. The editing board is the only board where Ultra has a row.

• Plan — Ultra is unavailable on workspaces below the Max plan. A team evaluating it on a starter tier is evaluating the wrong thing.

• Data handling — on a request carrying Krea's Zero Data Retention header, Ultra returns HTTP 422. An organisation with a ZDR requirement cannot use this mode at all, on any plan.

MiniMax-H3-Image has constraints too, and they are of a different kind. Six sampling steps, fixed; the API rejects any other step count or guidance value with HTTP 400. No negative prompts. No mask input. What you can vary is 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.

Both products took your knobs away, for opposite reasons

This is the part that makes the comparison more interesting than a speed contest. Krea removed the knobs by adding a thinking layer: you cannot tune Ultra because Ultra is doing the tuning, generating candidates and picking one. M​iniMax removed the knobs by removing the search: six distilled steps, one pass, no guidance scale to argue about. Both are answering the same complaint — that image models have too many dials and the dials are not the job — and they answer it in opposite directions.

The practical difference is what happens when the output is wrong. With Ultra, a bad result means its review step preferred the wrong candidate, and the fix is usually a better reference image rather than a better prompt, because the review is being run against the references. With M​iniMax, a bad result means the single pass was wrong, and the fix is prompt and reference surgery — there is no second opinion inside the call to appeal to.

Which suggests a diagnostic worth running once on your own workload: if your edit failure rate drops when you add a second reference but not when you rewrite the prompt, Ultra's architecture is aimed at your problem. If it drops when you rewrite the prompt, M​iniMax's is.

What the boards put between them

On AA-Image-Editing v2.1, read on 14 November 2026, Krea 3 (Ultra) sits eighth at 1,154 Elo over 6,062 votes, interval 1,141 to 1,167. MiniMax-H3-Image sits thirteenth at 1,138 over 3,137 votes, interval 1,122 to 1,154. Krea 3 (Fast) is twentieth at 1,124 over 5,798.

Sixteen points between Ultra and MiniMax-H3-Image, and the intervals overlap across most of their width. So the board's verdict is that these two produce edits of roughly comparable preference — a result that favours neither and that undercuts any claim that the slower, more expensive mode buys measurably better taste. What Ultra's extra machinery does buy is consistency of a specific kind: it removes the occasional bad generation from a batch by construction, which is a variance claim rather than a mean claim, and preference Elo measures means.

The more informative pair of rows is Ultra against Krea's own Fast mode: thirty points, and intervals that miss each other by four. The premium for thinking, on this board, is smaller than the premium for being Krea 3 rather than Krea 2. On text-to-image Krea's own newer entries are absent entirely — Krea 2 Large is the highest Krea row on that board at 1,035 — and MiniMax-H3-Image's 1,066 is thirty-one points above it. Krea 3 cannot answer that comparison because the Ultra mode has no text-to-image path.

The price of one good edit, worked three ways

Krea prices by component and the components add. Base is $0.03 for a 1K image or $0.06 for 2K. Each 1K reference adds $0.02, each 2K reference adds $0.07. High thinking adds $0.02 per generation. Ultra adds $0.20 per generation, at 2K only. So at 2K with one 2K reference, a Fast request is $0.06 plus $0.07, and the same request through Ultra is $0.33 — 2.5 times the price. With four references the reference fees dominate and the markup compresses to about 60%. Neither is the 3.3× that comparing $0.20 against $0.06 implies.

MiniMax-H3-Image's card is per delivered size with input metered separately. $0.02658 for a 2K edit with one reference image. $0.04177 for 2K with three. $0.03656 for a 4K edit with one reference during the current discount, $0.07312 at list — the discount runs to 17 November 2026 at 16:00 UTC and applies only when the delivered image is at least 16,600,000 pixels, to the whole request. At the tier the model is built for, a reference-carrying edit costs about a tenth of Ultra's.

That is a headline that needs its asterisk immediately. The two are not selling the same output. Ultra returns a 2K image — around four megapixels. M​iniMax returns roughly sixteen at every aspect ratio. Per megapixel the 4K tier at list is $0.0041 against Ultra's $0.079, which is a nineteenfold difference before the discount. Some of that gap is the thinking pass, and some of it is that Krea is charging designer-tool prices for a designer-tool workflow, which is a legitimate thing to charge for and a different market from a print-resolution generator.

The throughput question nobody puts on the rate card

Krea's launch claim for Krea 3 is "most edits in under 8 seconds, end to end, at native 2K". That figure belongs to the fast path. Ultra is a different class of operation: ten minutes ceiling normally, sixteen at low priority. Run the arithmetic on a thousand-image catalogue refresh and the two paths are not the same week of work — Fast finishes inside a coffee break's worth of wall clock per hundred images, Ultra does not finish inside a working day without concurrency.

MiniMax-H3-Image's ten-second claim sits between them, and it is a claim rather than a measurement. What is documented is the architecture that makes it plausible: six forward passes through a 33-billion-parameter transformer instead of the twenty to fifty a standard diffusion sampler would take, which is a real and specific reason for a large speed advantage rather than a marketing assertion. What is not documented is the delivered latency at each aspect ratio, the queue behaviour under load, or whether the ten seconds includes the 66.7 GB Qwen3-VL text encoder's pass over a 32,000-character prompt. Test it on your own prompts before you plan a pipeline around it.

Which one to put in the loop

Ultra earns its price when the deliverable is a small number of high-stakes edits where a bad generation is expensive to catch downstream — a campaign key visual, a packaging mock that a client will scrutinise, a product shot where the reference must be honoured exactly. It is also the only one of the two with a zero-data-retention story that is explicit enough to be a constraint: ZDR and Ultra are mutually exclusive, which means Krea has documented the boundary rather than hand-waving it, and that is worth something to a team that needs to know where it stands.

MiniMax-H3-Image earns its price when the deliverable is many large images and the per-image cost of a retry is trivial — catalogue backgrounds, out-of-home crops, anything that will be cut three ways and needs detail at the edges. Sixteen megapixels for three and a half cents during the discount changes what a batch job can afford to attempt.

The adoption risk is not symmetric either. Krea 3 Ultra is a mode on a hosted endpoint: it can be deprecated, repriced, or moved behind a higher plan, and there is nothing you can do about it except keep the integration thin. MiniMax-H3-Image's technical risk is low — the weights are files you hold, and the sampler will behave identically in five years — but its legal risk is high, because the MiniMax-H3-Image Community License Agreement excludes the EU, the UK, the Republic of Korea and the United States, requires separate written authorisation for hosted service and above a million dollars of annualised revenue, and requires prominent display of the model name. In those four jurisdictions the throughput argument above is academic.

Keeping both reachable

OrcaRouter serves neither of these two models. Krea 3 Ultra is reachable through Krea's own API — Ultra is a parameter on Krea's endpoint, not a separate product anyone else resells — and MiniMax-H3-Image has no route on our catalogue at all. 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.

For a studio running both a deliberative editor and a bulk generator, the integration shape that survives is one interface with two backends and a failover between them, so that a rate limit on one becomes slower work rather than stopped work. That is not a reason to route this particular pair through us — we do not serve them — but it is a reason to keep the second backend's credentials live rather than archived, because the whole point of the comparison is that these two are good at different jobs.

Sixteen Elo apart with overlapping intervals, ten times apart in price per edit, nineteen times apart per megapixel, and separated by a licence that decides the question outright for a good part of the market. Pick on the constraints, not the score — the score has not decided anything here.