MOSS-Image vs Krea 3: One Bills Per Image, the Other Bills Per Hour

The two models in this comparison are priced in different currencies, which is why the obvious comparison — six cents against zero — is the wrong one. K​rea 3, released 15 October 2026, is a hosted editing model with a published rate: $0.06 per image at native 2K, under eight seconds end to end by the vendor's own measurement. M​OSS-Image, released by OpenMOSS on October 16, 2026 as the Apache 2.0 checkpoints M​OSS-Image-Base and M​OSS-Image-SFT, has no rate at all. You rent a GPU and you pay for the hour, whether you generate one image in it or four hundred.

So the real question is not which one is cheaper. It is what your workload looks like over a month, because a flat per-image rate and an hourly rate cross over at a volume that depends entirely on your own utilisation. Below that crossover, K​rea is better on money and enormously better on latency. Above it, M​OSS-Image's marginal cost per image approaches the cost of electricity. Almost nobody does the arithmetic, and it is the whole decision.

Both of them want a box, and they want it in different units

Start with the part that makes them comparable at all, because it is easy to miss. Neither of these is a prompt-and-pray generator. K​rea 3's editing tooling includes bounding boxes for placing new elements, and multi-turn edits that hold their context across turns. M​OSS-Image's layout format takes a JSON object as the prompt — a summary block plus an items array where each element carries a label of text, character or object, a caption, a bounding box, and for text elements the literal string to render.

• Where the box comes from — M​OSS-Image: a JSON field on each item in the layout prompt, using bbox_format: "yxyx" in bbox_coord_space: "abs_centralized", i.e. absolute pixels measured from the centre of the canvas. K​rea 3: a bounding-box control in its editing interface for placing new elements.

• Output resolution — M​OSS-Image: trained across 256px, 512px and roughly 1024², with the token budget moving 576 → 3,072 → 8,192. K​rea 3: native 2K, with examples quoted at 2736 × 1536 px, and 1K at half the price.

• Reference images — M​OSS-Image: elements are described structurally in the layout prompt rather than supplied as reference images. K​rea 3: up to six per edit on the launch post, eight on the product page — the vendor's own material gives two figures and neither has been withdrawn.

• What you are building — M​OSS-Image: a composition, from a specification, largely from nothing. K​rea 3: an edit to an image you already have, with the region outside the edit left alone.

That last line is the one that decides most real workloads. If your job is "take this product photo and change the background", M​OSS-Image is the wrong instrument — it is not an in-place editor, and its vendor labels the editing behaviour experimental. If your job is "produce four hundred unique posters with specific copy in specific places", K​rea 3 is the wrong instrument, and its own material is thin on long text — its launch examples are English, its documented strengths are product scene changes, object removal and photo cleanup.

Speed, where only one side has published anything

K​rea 3's headline number is under eight seconds per edit, end to end, at 2K. It is a vendor figure and the vendor is unusually forthcoming about where it came from: the timings are the median request-to-result time of each model's twelve-image batch, queue time included, measured on K​rea's own platform between 24 September and 1 October 2026. A methodology printed on the benchmark is worth more than a bare number, and this one has it. It is still K​rea measuring K​rea.

M​OSS-Image has no published latency figure at all, and it is worth understanding why before treating that as an omission. The sampling defaults are flow-matching Euler at 50 steps with CFG 3.0, shift 5.0, and negative-branch skip-layer guidance at layer 22. The default guidance path needs two transformer forwards per step. Latency for M​OSS-Image is therefore not a property of the model the way it is for a hosted endpoint — it is a property of the GPU you put underneath it, the step count you choose, and whether you drop guidance or run distillation. The community shipped INT8 and INT4 quantisations, a 4-step DMD LoRA and an 8-step distilled variant within roughly a day of release, which tells you people found the 50-step default too slow for interactive work and fixed it themselves.

So the honest comparison on speed is: K​rea 3 quotes a number that depends on K​rea, and M​OSS-Image has no number because it depends on you. A 50-step default at two forwards per step is not fast. An 8-step distilled build on a rented card might be. Neither of those statements is checkable from any vendor's page, and the second one is checkable by you in an afternoon.

The revision arithmetic, which is where the six cents stops mattering

Here is the calculation that changes the decision, and it starts from K​rea's own framing.

At $0.06 an edit, running five passes and picking the best one costs thirty cents and no meeting. That is K​rea's implicit pitch, and it is a good one, because the alternative to a cheap retry is a designer's hour. A hundred thousand edits a month at 2K is $6,000 — and K​rea is explicit that the launch price is the list price and that it expects the price to come down rather than up, which makes the $6,000 a ceiling rather than a floor.

M​OSS-Image's side of the same arithmetic is not a rate, it is a utilisation problem. The licence is Apache 2.0 with no revenue threshold, and there is a $0.008-per-image open-weight model in this comparison's neighbourhood from a different vendor for reference — but that is not how the open path works. The download is about 27.2 GB, of which roughly 16.8 GB across four shards is the frozen Qwen3.5-9B text encoder and about 10.2 GB across three is the transformer. The 5B badge describes the diffusion generator alone and the encoder is the bigger half of the disk footprint.

Whether that beats six cents depends on three numbers you already know: your GPU-hour rate, your images per hour at the step count you settle on, and what fraction of the month the card is actually busy. A team running a steady production line will get a low effective per-image cost and should host. A team that needs forty images on Tuesday afternoon should not rent a GPU for it, and should not pretend the licence price is the image price.

The fine-tuning claim, which both sides make and neither has proved

This is the section that a spec comparison usually misses, and it is the most interesting thing these two models have in common.

K​rea's claim is that K​rea 3 is the first editing model you can fine-tune on a specific product, a person or a style, so a brand's packshot or a recurring character stays the same across a campaign. The mechanism is checkable — the API reference carries a "Train a custom style (LoRA)" endpoint — and whether "first" holds up is a claim about the field rather than a measurement. It is K​rea's claim. But the mechanism exists, it is documented, and it is the only published path on K​rea's side for locking a subject.

OpenMOSS's equivalent is structural rather than commercial. Base is the pretrained checkpoint, deliberately left undistilled — the model card states explicitly that no post-training or distillation of inference parameters such as CFG was applied, in order to preserve training information and keep LoRA training viable. That is a vendor choosing to ship a worse default in exchange for a better training substrate, and it is the clearest signal in the entire release about who the Base checkpoint is for.

Both claims point at the same buyer: someone with a recurring subject that must not drift. Neither vendor has published a drift measurement, and the community builds around M​OSS-Image — the ComfyUI packaging, the quantisations, the distilled LoRAs — arrived within about a day, which says the training path is real even though no training result has been published by the vendor.

• Where the LoRA lives — K​rea 3: a hosted endpoint on K​rea's platform, trained against K​rea's model on K​rea's infrastructure. M​OSS-Image: your own weights, your own training run, your own GPU, with a checkpoint the vendor deliberately left in a trainable state.

• What that costs you — K​rea 3: the training conversation is a licence conversation. M​OSS-Image: the training conversation is your electricity bill and somebody's week.

• What it gives you back — K​rea 3: a style you can call, on someone else's uptime. M​OSS-Image: a checkpoint you own, that keeps working if the vendor walks away.

Access, and where a router fits into a two-tool pipeline

K​rea 3 is closed. K​rea has released open weights before — K​rea 2 RAW and Turbo are on the Hub — but K​rea 3 is not among them, and K​rea's FAQ puts self-hosting under enterprise plans, on your own GPUs, with licence terms and hardware sizing to be discussed. So it is a call. M​OSS-Image is a download, and the download is the whole product.

Neither is on the OrcaRouter catalogue — we serve more than 200 models and neither of these two is one of them — so both mean going to the source: for K​rea 3, K​rea's own API and several third-party platforms; for M​OSS-Image, the repositories and your own hardware.

What the router is good for in a pipeline like this is the part that is not either model. Placing an element in a frame is usually one step of a job that also needs a hosted generator for the base image, a separate model for upscaling, and a captioning or judging pass — and that is where one endpoint over a few hundred models with automatic failover and provider list prices passed through at 0% markup removes the integration work rather than the model work. The routing DSL matters for the same reason: if the base-image step and the edit step are two different models, pinning each per request in one config beats holding two vendor SDKs. It is the plumbing, and M​OSS-Image's own architecture is a reminder of what the plumbing is worth relative to the model — the vendor's strongest end-to-end layout result was produced by a pipeline whose prompt-specification half runs on a third-party model entirely.

Which one, and the crossover that decides it

Take K​rea 3 if the deliverable is an edit to an existing image, if your team measures its own latency in minutes, and if your volume is lumpy enough that a rented GPU would sit idle most of the month. Six cents with a sub-eight-second round trip, a documented precision story and a LoRA endpoint on the vendor's own infrastructure is a coherent product for that job, and the fact that the launch price is stated as the list price means the economics are unlikely to get worse. Go in knowing that every performance figure attached to it is K​rea's own, that the reference count is documented two ways, and that it carries no independent score of any kind — which is the whole explanation for its absence from the leaderboards, since it was released the day before this article's research was collected.

Take M​OSS-Image if you are producing composed images from a specification at steady volume, if a bounding box in a JSON prompt is a better fit for your pipeline than a box in somebody's UI, or if owning the checkpoint is a requirement rather than a preference. Apache 2.0 with no revenue threshold makes the legal review short, the Base checkpoint is deliberately trainable, and the layout schema is a real specification. Go in knowing that the latency depends on you, that the encoder is most of the download, that the community quantisations exist because the 50-step default is slow, and that neither of the vendor's benchmarks has been reproduced by anyone.

The crossover is not a mystery. Divide your monthly GPU cost by your images per month and compare the result to six cents. If you cannot estimate images per hour confidently, that uncertainty is the answer: rent K​rea for a month, generate the volume you actually expect, and let the invoice tell you whether the open path is worth building. It is a cheaper experiment than renting a card for a month to find out.

The documented AI failures and agent incidents behind releases like this one are collected in the OrcaRouter AI Incident Archive, where each entry carries its own sources, severity, confidence grade and disputed flag.