MOSS-Image vs Qwen Image 3.0: One Lab Went Closed, the Other Went Open

Q​wen Image 3.0 and M​OSS-Image were released by Chinese labs eight weeks apart and they took opposite positions on the one question that decides what you can build. A​libaba shipped Q​wen Image 3.0 on July 21, 2026 and took it to general availability on August 5 — closed, no weights, no model card, no technical report, reachable only through a hosted API in Pro and Standard editions. OpenMOSS released M​OSS-Image on October 16, 2026 as Apache 2.0 open weights covering both the checkpoints and the standalone inference pipeline. There is a naming trap on the Q​wen side worth knowing before anything else: Q​wen-Image 2.1, released September 20, 2026, is newer than Q​wen-Image 3.0 and the two are separate product lines sharing a number.

Put like that, the comparison looks like an open-versus-closed argument, and it partly is. But the more interesting difference is not licensing. It is that Q​wen Image 3.0 and M​OSS-Image make their strongest claims about the same capability — getting text and layout exactly right — and they have entirely different mechanisms for it, one of which you can inspect and one of which you cannot.

What Q​wen Image 3.0 actually claims

Q​wen Image 3.0 is a closed hosted model delivering image generation and editing through one API, in Standard and Pro editions. A​libaba's launch material makes four specific promises: prompts up to around 4,500 tokens, legible in-image text down to roughly 10 pixels, coverage of 12 languages across 20-plus fonts, and output up to 2048×2048 with up to six images per call. No parameter count was published, and the widely repeated ~20B MMDiT figure is reported rather than confirmed by A​libaba.

Pricing runs at about $0.035 per image on A​libaba's Model Studio, with Artificial Analysis deriving roughly $30 per 1,000 images for Standard and $40 per 1,000 for Pro. Its measured position is mid-table rather than leading: Elo 1,077 for text-to-image, ranking sixteenth; 1,088 for the Pro edition on editing, fourteenth; and 1,048 for Standard on editing, twenty-first. Those are Artificial Analysis figures, which makes them the only independently produced numbers in this entire comparison — M​OSS-Image has no Artificial Analysis entry at all.

Three things are documented about its editing behaviour, and the sparseness is the point. Pro supports 1–3 input images. The documented editing path covers local rewriting, content expansion, style transfer and multi-camera-angle generation, with no published mask-based workflow. There is no transparency claim in the announcement at all — no RGBA generation, no transparent-layer editing, no subject extraction to an alpha channel.

What is notably absent from every A​libaba page is any measurement of layout precision. Q​wen Image 3.0 claims legible text at 10 pixels and says nothing about where that text lands.

What M​OSS-Image claims, and the difference in kind

M​OSS-Image is a 5B single-stream diffusion transformer — 42 joint blocks, hidden width 3,072, 24 heads at 128 dimensions, 8,192-wide SiTU-GLU feed-forward, four-axis rotary position encoding — with a frozen Qwen3.5-9B text encoder and a frozen FLUX.2 VAE loaded from FLUX.2-klein-4B. The SFT download is about 27.2 GB, roughly 16.8 GB of it the encoder.

The capability difference is not a matter of degree. Q​wen Image 3.0's text claim is about legibility — can the model render characters small enough to read. M​OSS-Image's claim is about placement — can it put a specified string at a specified coordinate. Those sound similar and are not. A model that renders text beautifully but puts your headline across the product shot has failed at a different task than one that renders slightly softer glyphs in exactly the right box.

M​OSS-Image's mechanism for placement is that you supply the layout as data. The prompt can be a JSON object carrying bounding boxes in absolute pixel coordinates measured from the canvas centre, literal text strings and typography notes, with bbox_format "yxyx". The vendor's own ablation is the clearest evidence for why the interface matters: on RealLayoutArena, JSON layout prompts score 1,622.87 on the same system where natural-language prompts score 1,506.20. On 7Bench, which the report also introduces, M​OSS-Image reports a mean layout IoU of 0.88 with a Layout AUC of 0.70 — the same table puts Q​wen Image 3.0 Pro at 0.31 and a field AUC of 0.16 to 0.20.

That 0.88 against 0.31 is the largest single gap in this comparison and it is also the least trustworthy number in it. OpenMOSS wrote the benchmark, ran both models on it, and published the result. Q​wen Image 3.0's authors have published no layout metric at all, so there is nothing to check it against — not a lower number, not a dispute, nothing. That asymmetry is worth naming: one lab's advantage on a self-authored test is being compared against another lab's silence.

The dimensions, side by side

• Release — Q​wen Image 3.0 launched July 21, 2026, GA August 5, 2026; M​OSS-Image released October 16, 2026

• Licensing — Q​wen Image 3.0 is closed, with no weights, no stated licence, no model card and no technical report; M​OSS-Image is Apache 2.0 for weights and standalone pipeline code, with no revenue threshold

• Price — Q​wen Image 3.0 about $0.035 per image on Model Studio, with Artificial Analysis deriving ~$30 per 1,000 Standard and ~$40 per 1,000 Pro; M​OSS-Image free to download at ~27.2 GB plus your own GPU time

• Editions — Q​wen Image 3.0 ships Standard and Pro with different editing ranks; M​OSS-Image ships Base and SFT checkpoints, where Base is deliberately left undistilled so fine-tunes have something to bite on

• Prompt ceiling — Q​wen Image 3.0 around 4,500 tokens; M​OSS-Image 4,096 tokens at the final pretraining stage

• Text rendering — Q​wen Image 3.0 claims legible text down to roughly 10 pixels across 12 languages and 20-plus fonts; M​OSS-Image reports 96.3 Mean-6 on LongLongTextBench, splitting 97.1 English and 92.4 Chinese, against Q​wen-Image-2512's 64.9 in the same table

• Layout control — M​OSS-Image takes JSON layouts in absolute centre-relative coordinates and claims 0.88 mean IoU on 7Bench, where Q​wen Image 3.0 Pro is listed at 0.31; A​libaba publishes no layout metric

• Reference images — Q​wen Image 3.0 Pro documents 1–3 input images and up to six images per call; M​OSS-Image's reference conditioning is a reserved axis in its positional scheme, described as forward-looking rather than shipped

• Editing — Q​wen Image 3.0 covers local rewriting, expansion, style transfer and multi-camera-angle generation through one API; M​OSS-Image's report does not present editing as a product surface

• Transparency — Q​wen Image 3.0's announcement carries no transparency claim; M​OSS-Image's VAE uses 32 latent channels and the pipeline exposes the latent representation, though RGBA output is not a vendor-claimed feature

• Independent score — Q​wen Image 3.0 at Elo 1,077 text-to-image (16th) and 1,088 Pro on editing (14th) per Artificial Analysis; M​OSS-Image has no independent score

• Ecosystem — Q​wen Image 3.0 has an API; M​OSS-Image has a Diffusers custom pipeline, a Gradio app, a ComfyUI plugin installable through ComfyUI Manager, and an open vLLM-Omni pull request still under review

The argument that decides most teams

Q​wen Image 3.0 is not a weak model, and it is not expensive. At roughly three and a half cents an image with a 4,500-token prompt window, 2K output and multi-image calls, it is a completely reasonable thing to put behind a product feature this afternoon. If your requirement is "generate good images of this description, sometimes with a reference image, at a predictable per-unit cost," the closed model wins on time-to-first-request and possibly on total cost, because your engineers never touch a GPU.

M​OSS-Image wins on a different axis, and it is one that no API can offer regardless of price: you can inspect the thing that decides the output. A layout specification is data. It can be generated by your code, version-controlled in the same repository as everything else, diffed when someone changes the template, validated against a schema before it reaches the model, and reviewed by a human who signs off on composition before a single pixel is rendered. None of that is possible when the mapping from prompt to layout happens inside a hosted endpoint you cannot see into.

That is a real architectural difference and it markets badly, because "you can unit-test your prompt" is not a demo anyone films. But it is the difference between a pipeline whose failures are debuggable and one whose failures produce a support ticket. When M​OSS-Image puts the headline in the wrong place you can read the JSON you sent and see the wrong coordinate. When a hosted model does it, you have a prompt that looked fine and an image that does not.

There is a second distinguishing fact that neither vendor leads with. Q​wen Image 3.0's silent areas are consistent: no parameter count, no architecture, no training data description, no benchmark table, no technical report, and no layout metric. M​OSS-Image's report is over-specified by comparison — progressive resolution training stages with step counts, a ReLAION-derived corpus trimmed from roughly 5 billion to 3 billion images, a hybrid Muon–AdamW optimiser with an ablation showing 33.2% and 28.6% fewer steps to the same loss than AdamW at two checkpoints. Some of that detail is only available because the model is open, but the report was written by choice, and it is the difference between a product and a publication.

Where the openness claim has limits

Three things about M​OSS-Image's openness deserve to be checked rather than assumed.

The first is operational. Open weights with no merged serving path is a different proposition from open weights with one. The vLLM-Omni pull request that adds M​OSS-Image with skip-layer guidance — [Model] Add MOSImage text-to-image with SLG — was opened on October 14 with 3,605 added lines across 25 files and remains open, with the reviewer asking for output-parity evidence against a pinned reference implementation. vLLM-Omni's newest published release is v0.31.0rc1, dated October 6. No shipped version contains the model, and the "Day 0 support" framing that circulated on release day describes a branch you can build rather than a package you can install.

The second is that the strongest result in the report is not single-model. The prompt enhancement module, LayoutPE, is stated to use G​PT-6 with modular task instructions at inference time, and the bundled prompt-enhancer skill is described as designed for G​PT-6-family agents. The headline end-to-end Elo of 1,698.70 — second behind GPT Image 2's 1,844.35 — is therefore produced by a two-model pipeline whose specification half is somebody else's API. Read as a measure of the generator alone, that number is inflated.

The third is fine-tuning. Base was deliberately left undistilled — the model card states it "has not undergone any post-training or distillation of inference parameters such as CFG" — specifically so LoRAs have something to bite on, which is a genuine commitment rather than a licensing gesture. But the training recipe is documentation rather than released data, and the fine-tuning guidance so far amounts to specific instructions (keep the text encoder frozen; do not fine-tune it) plus a captioning prompt. The claim that simple SFT unlocks reference-based generation and GIF output is stated with a "stay tuned" attached.

Routing, stated without overreach

Neither model in this comparison is on our catalogue and we will not pretend otherwise. Q​wen Image 3.0 lives on A​libaba's Model Studio and, like the rest of the Q​wen image line, is not something OrcaRouter serves. M​OSS-Image is a download. The boundary here is simple: we do not host either one.

What is on our catalogue is the rest of the field these two are measured against — the hosted image models you would benchmark a self-hosted M​OSS-Image against, reachable on one API key at provider list price with 0% markup, so a vendor price change on a hosted model is reflected here the same day rather than at the next contract renewal. For a comparison like this one, where the Q​wen side is billed per image and the M​OSS side is billed in GPU hours, the useful thing a routing layer provides is not a discount but a single place to read the live hosted price and a single endpoint to fail over across providers when one upstream degrades mid-evaluation. That is the whole claim, and it stops short of offering you a model we do not run.

How to decide, in order

Work through these in sequence and the answer usually falls out by the third question.

• Do you have GPUs, or a budget you can convert into GPU hours? If no, this comparison is over and Q​wen Image 3.0 is the answer at about $0.035 an image.

• Is your layout knowable before generation — do you have a template, a grid, a set of coordinates? If yes, M​OSS-Image's JSON interface is the only mechanism in this matchup that addresses your problem directly, and the 0.88 against 0.31 gap is the evidence for it, however vendor-authored.

• Do you need to fine-tune, quantise, or run air-gapped? If yes, the closed model is not a candidate at any price, and the fact that a 4-step DMD LoRA and an 8-step distilled variant appeared within about a day of release is what you are buying into.

• Does your legal review need to end in a document? Apache 2.0 versus no stated licence is the shortest part of this comparison.

• Is independence of measurement a requirement? Then pick neither without further work. Q​wen Image 3.0's only independent numbers are Artificial Analysis's Elo placements, which put it in the middle of the field rather than near the top. M​OSS-Image's headline results are all from benchmarks its own authors built.

The thing that would change the answer fastest does not exist yet, and it is the same thing for both models: one independent run of the test each is best at. For Q​wen Image 3.0 that means a layout measurement from anyone, since A​libaba has published none. For M​OSS-Image it means someone other than OpenMOSS running LongLongTextBench, RealLayoutArena or 7Bench. Until then, whatever you decide, you are deciding on architecture, licence and mechanism rather than on verified quality — which for a head-to-head between a closed API and an open checkpoint is arguably the right basis anyway.

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.