Ming-Image-0.1-Design: a Z-Image fine-tune that is #1 of 42 open models and 16th of 129

mdjsonmcpcopy↗ai

2026-09-23 · 33 min · image-generation · diffusion · open-weights · benchmarks · evaluation · agents · explainer

inclusionAI, Ant Group's model lab, released the Ming-Image-0.1-Design family on 22 September: two "6B" models, one that generates text-heavy designs and one that splits a flat design into editable layers, plus two agent skills. The announcement carries one quantitative claim: "Ming-Image-0.1-Design ranks #1 among open-weight models on Artificial Analysis's UI/UX Design leaderboard."

A rank is only half a measurement. This site's standing rule is to put the denominator next to it, and the same rule applies to "6B", to "open-source" and to "Agent Skill". So I read the release rather than the announcement: every config.json, the safetensors header of every shard by HTTP range read, the companion code at inclusionAI/Ming-Image, the leaderboard data Artificial Analysis embeds in its own page, and the two skills in inclusionAI/ling-cookbook. I downloaded no weights and ran no inference. Where I compared weights, I range-read a few tensors of a few kilobytes each.

The short version: this is a careful, useful, permissively licensed release, built mostly out of other labs' open parts and crediting none of them. The #1 holds. It is narrower than the sentence suggests.

The 6B is a quarter of the download

The model card says "a 6B text-to-image model" and the GitHub README says "two 6B-parameter models". The Hub's own safetensors counter agrees: 6,154,901,056. It is only counting one folder.

The repo ships five components, and summing their headers gives the pipeline. Measured: 24,857,847,668 parameters in 52.9 GB of files at the current revision of the Design repo. (The card above shows the Hub's 71.5 GB storage figure, which also counts files from earlier revisions.) Every tensor's byte span matches its dtype times its shape, and each component's total equals its files' sizes minus their headers exactly, so there is nothing hidden in the padding.

Four things in that ledger are worth saying in prose.

The 6B claim is exact, and it describes 24.8% of what you download. That is almost the ratio this site found for Qwen-Image-2.1, whose "7B" was 28% of its pipeline. The difference is that Qwen's biggest non-DiT part was a dense 8.8B text encoder. Ming's is a mixture of experts: 17.0B stored, but only 0.79B of the language model runs per token, over a prompt that is read once. The DiT runs all 6.15B over every image token on every step. Reasoned from those two facts: by linear-layer arithmetic the DiT is above 99% of the work at every size the code supports. By storage it is a quarter. Both numbers are true. The one that decides whether a GPU fits is the storage one, and the release says it plainly: the validated configuration is "one CUDA GPU with 80 GiB VRAM".

565M parameters never run. The language model ships its 322M-parameter lm_head, and the pipeline reads hidden states and never samples a token. The connector is a whole Qwen2.5-1.5B, fed inputs_embeds, so its 233M-parameter token table is dead too. And the language model carries an audio router, 10M parameters, trained (its expert biases correlate 0.80 with the text router's), in a pipeline whose code raises "audio input is not supported by Ming Image inference". None of this is unusual. It is the residue of lifting a multimodal chat model into a text encoder, and it is worth knowing before you quantise.

The Layer repo is heavier than the Design repo. Its DiT is stored in FP32: 24.6 GB for the same 6.15B parameters, 65.2 GB for the repo. The card's recommended settings say "Precision: BF16". It works, because infer.py defaults to --dtype bfloat16 and casts on load. It doubles the transformer download for no stated reason.

The Design model can edit, and the card does not say so. infer.py accepts --task image-edit, served by the same generation_edit profile as text-to-image, at a 1024 bucket. The in-progress vLLM-Omni support lists "(design) Single-reference image editing" as a supported feature. Neither model card mentions it.

The DiT is Z-Image, and not the Turbo one

The transformer's config.json is where the lineage starts. dim 3840, 30 layers of 30 heads, n_refiner_layers 2, cap_feat_dim 2560, axes_dims [32, 48, 48], rope_theta 256.0, t_scale 1000.0. That is, field for field, Tongyi-MAI/Z-Image's ZImageTransformer2DModel: Alibaba Tongyi's 6B single-stream DiT, whose Turbo checkpoint appeared in November 2025 and whose base checkpoint followed in January. Only three things differ. The class is renamed DiffusionTransformer, the first RoPE axis is stretched from 1,536 to 20,480 positions, and two new capability fields decide padding and multi-frame output.

Three independent checks say it is more than a borrowed shape.

1. The code. Ming's diffusion/transformer.py is 744 lines. After undoing three class renames, 631 of the 653 lines of diffusers v0.36.0's transformer_z_image.py appear in it, in order. The diffusers file opens "Copyright 2025 Alibaba Z-Image Team and The HuggingFace Team". Ming's opens "Copyright (c) Ant Group. All rights reserved." Measured.
2. The count. The Layer DiT has 6,154,908,736 parameters: Z-Image's number, to the unit. The Design DiT has 7,680 fewer, which is exactly two 3,840-wide vectors. Those are Z-Image's learned x_pad_token and cap_pad_token, dropped because the Design checkpoint masks padding out of attention instead (alignment_padding_mode: "zero_masked"). Measured.
3. The weights. A shape match proves architecture, not initialisation, so I range-read nine small tensors, biases and norm scales totalling 38,464 values, from Ming and from three candidate parents, and compared them.

Measured: every informative tensor puts the Ming DiT nearest the base Z-Image, the January checkpoint, and not the distilled Turbo. The last block's 15,360-value modulation bias is 0.84% away from base and 16.1% from Turbo. That matters because inclusionAI has done this before. Its February omni model, Ming-flash-omni-2.0, ships a transformer/ whose config still says ZImageTransformer2DModel, whose _name_or_path is .../Ming_flash_zimage_final_5k_fixrope, and whose mlp/config.json says "dit_type": "zimage". Those weights sit on Turbo: 0.61% from it on the same bias. For the design model they went back to the undistilled base, which is what you do when you intend to train a lot.

The Artificial Analysis arena happens to rate the parent, which makes the size of that training visible. Reported by Artificial Analysis, arithmetic mine: Z-Image Base sits at 840 Elo in UI/UX Design, and Ming at 1083. That is a 244-point gain from fine-tuning, in the category it was fine-tuned for. Across all prompts the gain is 120.

How a 17B model talks to a 6B one

Z-Image conditioned its DiT on the hidden states of Qwen3-4B, which is 2,560 wide. Ming keeps that 2,560-wide slot and replaces what feeds it. Tracing modeling_bailingmm2.py:

• The prompt goes into a Ming multimodal LLM with 256 learnable query tokens appended (query_tokens_dict.16x16, the MetaQuery pattern). Its language model is Ling-mini-2.0's shape to the parameter: 20 layers, 2,048 wide, 256 experts with 8 active plus a shared one. Two extra routers, image_gate and audio_gate, make up the difference of exactly 19,932,672 parameters. Its norm scales sit 1.5–1.7% from inclusionAI/Ling-mini-2.0's.
• The final hidden states at those 256 positions go through proj_in (2,048 → 1,536), a full Qwen2.5-1.5B run as a bidirectional encoder (the code passes an all-ones attention mask), and proj_out (1,536 → 2,560). That lands in Z-Image's caption embedder, the slot Qwen3-4B's states used to fill.
• In parallel, a direct path concatenates the language model's hidden states at layers 5, 12 and 20 for every prompt token (3 × 2,048 = 6,144), normalises them and projects straight to the DiT's 3,840 width, skipping the caption embedder. Both streams are concatenated and go through Z-Image's context refiner.

The fingerprint agrees with the plumbing. The two tensors that make up the caption embedder are among the three that moved 50–90% away from every candidate parent: the one layer whose input distribution changed was retrained.

The VAE is the other swap. Z-Image uses a 16-channel RGB AutoencoderKL. Ming ships AutoencoderKLQwenImage with input_channels: 4, and Measured: its file has SHA-256 06520463…, identical to Qwen/Qwen-Image-Layered's RGBA VAE. It is the same file. It also has 16 latent channels at 8× spatial compression, which is why the swap is dimension-compatible with Z-Image's in_channels: 16. The config replaces Qwen's per-channel latent means and deviations with a single scaling_factor of 8.0064.

What -Layer means: the same body, with layers as frames

The Layer repo shares the multimodal encoder and the VAE with the Design repo byte for byte: all seven mllm/ shards and the VAE have the same SHA-256 in both. The DiT, the connector and the query tokens differ. The DiT's config differs in two fields, alignment_padding_mode: "learned" and multi_frame_output: true. Its two pad tokens are new: they correlate at −0.002 and −0.019 with Z-Image's, so they were freshly initialised rather than inherited.

The fingerprint's last column settles the family tree. The Layer DiT is closer to the Design DiT than either is to Z-Image, and on the retrained tensors the two moved away from Z-Image together. Two independent fine-tunes would not do that. The two releases share a Ming parent. Measured.

multi_frame_output is the whole trick. The VAE is a video autoencoder, descended from Wan's, with a time axis. The Layer model asks the DiT for N + 1 frames: one full composite, then N RGBA layers, front to back. It appends the flat input image as one more frame along the same RoPE axis the frames use. That is Qwen-Image-Layered's formulation, layers as positions on a third RoPE axis with the conditioning image as its own index, transplanted onto a Z-Image body. The README describes the output honestly: "The layer model returns the requested layers plus one leading composite/full-canvas image." The CLI drops the composite and writes layer_01.png onward.

expand

There is a cost in this design that the card does not spell out. Every layer is a full frame of image tokens, and the Design model's guidance scale of 1.0 becomes 2.0 here, which means two DiT passes per step instead of one. Reasoned from the code: a six-layer decomposition at the 1024 bucket is eight frames, 32,768 image tokens, run twice per step. A 2048² text-to-image image is 16,384 tokens, run once. By linear arithmetic the released six-layer demo is about four times the DiT work of the model's largest text-to-image output, before attention's quadratic term makes the gap wider. The layer count is a latency dial. The card mentions a 512 bucket for speed and says nothing about layer count.

expand

The Layer model's only number belongs to something called CLEAR

The Layer card has one quantitative figure. It is a table from a paper: "Table 1: Quantitative results of various layer-decomposition methods on Crello test set". The metrics are RGB L1 and alpha soft IoU, reported at zero to five "max-allowed layer merges". The bold row, the winner, is labelled "CLEAR-1024 (Ours)".

expand

Neither model card uses the word CLEAR. arXiv has no layer-decomposition paper by that name as of today. So the reader is left to infer that CLEAR-1024 is this checkpoint at its 1024 bucket. That is a reasonable inference and it is still an inference. Reasoned.

The rest of the table is checkable, so I checked it.

Measured: four of the seven rows are transcribed from Table 1 of the Qwen-Image-Layered paper, and all 48 of their numbers match to four decimal places. The paper's text confirms the dagger. Qwen's reported numbers come from a model they "finetune[d] … on Crello training set" because of the distribution gap between Crello and their PSD-derived data. Two rows are the Ming team's own runs of the released Qwen-Image-Layered weights, and those do much worse (0.1409 L1 against 0.0594). That matches the footnote's point that the paper's number came from an unreleased, Crello-tuned checkpoint.

So the load-bearing comparison is CLEAR against the Crello-tuned Qwen row. CLEAR wins it: 3.4% lower L1 and +0.022 soft IoU at zero merges, and it wins every column. What the table does not say is whether CLEAR also trained on Crello's training split. If it did, this is like-for-like and CLEAR is modestly better. If it did not, this is a zero-shot model beating a fine-tuned one, which would be a much stronger result, and I would expect them to say so. Crello is released under CDLA-Permissive-2.0, so either answer is legitimate. It is simply unstated. The gallery inputs above are Crello-style templates, which is suggestive and not evidence.

The alpha channel is a matte, again

One of this site's Qwen-Image-2.1 findings was that its RGBA output is a matte generator: 99.1% of pixels within seven levels of fully transparent or fully opaque. Ming makes the same kind of claim twice. The Design model generates RGBA from a prompt prefixed with one of ten fixed phrases ("RGBA, 4-channel, transparent background", "抠图素材，背景alpha=0" and so on), and the Layer model emits RGBA layers.

The Layer model's outputs cannot be tested. Measured by absence: no raw layer PNG is published anywhere. The showcase, the gallery and the repo's card_making_decomposition.png are all flattened previews on a checkerboard, in RGB. The Design model's can. The GitHub repo ships three text-to-image samples under transparent_rgba/, each at the native 2048 × 2048. WebP keeps alpha in its own chunk, and in all three that chunk reads compression=1 (lossless) with no level reduction, so the alpha is exactly what the model produced even though the colour is lossy.

expand

Measured: 0.652%, 0.888% and 0.144% of pixels fall between alpha 32 and 223, and 98.4–99.7% sit within seven levels of an extreme. The tabby cat is the interesting one, because fur is the case the Qwen piece's falsifier asked for. Fur edges are exactly where a matting model puts partial alpha. At native resolution the model draws the fur boundary as opaque tufts and the whiskers as thin opaque strands, and the soft band that remains is under 1% of the frame. The sedan's windows are fully opaque. The only real gradient in that frame is the contact shadow under the tyres. The same Qwen autoencoder family under a different denoiser, fine-tuned by a different lab, gives the same answer: a clean cutout generator, not a translucency generator.

expand

Two practical notes come out of the same files.

First, the background is not zero. Measured: alpha = 1 is the single most common value in the snowboarder frame, 43.2% of all pixels, and a quarter of the cat's. You cannot see 1/255, but any code that treats alpha > 0 as content will see a full-canvas object. PIL's getbbox() on the sedan's alpha channel returns the full 2048 × 2048 canvas. Thresholded at 8, it returns the car, 1,932 × 969. The PPT skill's cropper defaults to --threshold 8, which clears the floor. The UI skill's optional --trim-alpha uses a bare getbbox(), which does not.

Second, the colour under the transparent pixels is a dark maroon: mean (49, 31, 33) under the cat. Qwen-Image-2.1's was saturated purple. It is less alarming, and it still arrives if a loader drops the alpha channel.

#1 of 42, 16th of 129

Now the claim itself. First, what the leaderboard is, from Artificial Analysis's methodology page (AA from here on).

• Who judges: people. Blind pairwise votes on two images generated from the same prompt, left and right randomised, identities hidden until after the vote. There is a minimum engagement time, bot filtering, and short "judging hints" tied to the prompt's category.
• How it is scored: a Bradley–Terry maximum-likelihood fit, rescaled to an Elo range and anchored at FLUX.2 [dev] = 1000 in the overall board and in every category board. The 95% intervals shrink as a model collects votes.
• What "UI/UX Design" is: one of the use-case tags in AA's taxonomy, "UI mockups across app, web, in-car, and spatial surfaces". Every prompt carries exactly one use case and one capability tag, and the category board is the fit restricted to its votes.
• How images are made: English prompts in plain natural language, a single positive prompt, no negative prompt, seed 42, 1:1 aspect ratio. Each model is run at "the highest resolution each model supports, then downscale[d] to 1024×1024" on a public serverless endpoint.

Then the data, read from the leaderboard page on 23 September.

Reported by Artificial Analysis, arithmetic mine:

• UI/UX Design: Ming is 16th of 129 models at 1083 ± 22, over 2,095 appearances, with a 62.1% raw win rate. It is first of 42 open-weight models. The next is Ideogram 4.0 (Quality) at 1050 ± 23, a gap of 33.1 Elo. The two 95% intervals overlap by 11.9 points. Treated as independent, the gap is 2.04 standard errors (p ≈ 0.04). Treated as what a rating gap means, it predicts Ming winning 54.7% of head-to-head UI/UX votes against Ideogram. That is a real edge and a small one. All fifteen models above it are closed.
• Everything else: across all prompts, Ming is 45th of 161 at 994 ± 8, below the FLUX.2 [dev] anchor, and 6th of 52 open-weight models. It is first among open models in 3 of the arena's 20 views: UI/UX Design (+33.1), Layout (+7.0) and Text Rendering (+1.25 over FLUX.2 [dev] itself). The second and third leads are well inside ±21–23. Its worst view is Live-Action Film, 78th of 161.

The Elo arithmetic behind "54.7%" is the definition, not a separate model:

None of this makes the claim false. It is precisely true of the one category the model is named after, and naming a design model after design is not cherry-picking. It does make the claim specific: a specialist that leads its specialty among open models, sits mid-table everywhere else, and is 145 points behind the best closed model in its own category. The card publishes only the open-weights view of the chart, which is the view in which the rank is 1.

expand

Three things about the measurement cut in different directions.

1. The licence makes the claim understated. "Open-weight" on this board includes non-commercial weights. Ideogram 4.0's are ideogram-4-non-commercial, and FLUX.2 [dev] and its fal derivatives are under the FLUX non-commercial licence. Measured from the Hub metadata: the nearest open model in UI/UX under MIT or Apache-2.0 is HiDream-O1-Image at 985, 98 Elo behind. If what you need is a design model you can ship, Ming's lead is three times what the headline implies.
2. The prompts are not the ones the model wants. AA prompts are plain natural language. Ming's recommended path runs a separate VLM first, Ling-3.0-flash-VL or qwen3.8-27B, to turn a short request into a Figma-style JSON layout with coordinates, hex colours and every string quoted once. The system prompt for that rewriter is in the README. Whether the arena endpoint applied it is not stated anywhere I can find. The hosted API the skills call has a use_pe switch, so a server-side rewriter exists. Either the arena measured the model without its preferred input, or it measured model plus rewriter. Reasoned, and unresolved.
3. The model was rated before it was public. AA's record gives introducedAt as 14 September and the release as 22 September. AA says new models are "temporarily upsampled until their ratings converge". By its own interval, UI/UX has not finished converging: 2,095 appearances is more than any model above it has, and ±22 is still wider than the gap to second place.

expand

Two real skills, wired to someone else's server

The announcement lists "two open-source Agent Skills: the Ling UI Design Skill and the Image-to-Editable-PPT Skill". They live in inclusionAI/ling-cookbook under resources/recommended-skills/, beside a third skill, ling-gui-agent-skill, from earlier in the month. The PR that added the UI skill describes it as "a clean source snapshot without its original Git metadata or history": it was lifted from an internal repository. The cookbook also carries a submodule pointing at an internal code.alipay.com host.

Are they skills, or prompts with a README? Measured: they are skills, and good ones by the standard this site has applied before.

• Each has a SKILL.md with a name and a description that says when to trigger and, just as usefully, when not to. The PPT skill says "Do not use for text-to-deck authoring, ordinary presentation writing, or image generation."
• References load on demand: two for the PPT skill, seven for the UI skill.
• Every script and reference either SKILL.md names exists. I checked all 17 paths. That is the check figures4papers failed, where the SKILL.md specified nine functions no file implemented.
• The UI skill ships four test files. The PPT skill ships none.

What Image-to-Editable-PPT produces: one .pptx slide per source image. Text becomes native text boxes, simple cards and frames become native shapes, and illustrations become tightly cropped RGBA bitmaps, stacked by a scene.json that compiles offline. It has hard rules I would want in any such tool: "Do not place the untouched source image behind editable text", "Never silently call a flattened slide 'editable'", and a ten-minute budget with a stopping rule for API calls. It is an honest definition of "editable". Bitmap art stays bitmap, and the skill says so.

What it calls is the part the announcement leaves out.

The PPT skill never names its model in English. Only its Chinese README says it depends on "a model with strong visual spatial decomposition, such as Ming-Image-0.1-Design-Layer". The protocol it speaks has server-side super-resolution, a roughly 2K output and a region reading returned in revised_prompt. The released pipeline has none of these. Reasoned: as written, both skills target a hosted service, and the open weights reproduce part of it.

The UI skill's defaults resolve only halfway. Measured against OpenRouter's public API on 23 September: inclusionai/ming-image-0.1-design is listed, served by Novita since 22 September, free, text-to-image only. inclusionai/ming-image-0.1-design-layer returns 404. So does the route. An unauthenticated POST to /images/generations gets a 400 validation error, so that route exists; the same POST to /images/edits, which the decomposition script uses, gets a 404. A fresh install can generate a page mock and then stops at decomposition. The skill's own rules say to report a missing stage and ask, not to skip it, because decomposition feeds the asset gate that must pass before any code is written. Self-hosting is the other route. The model cards' "recommended" vLLM-Omni recipe link is a 404 on main, and support is vLLM-Omni PR #8021, opened on release day and still open, with a TODO list.

None of this is a defect in the skills, which are careful work. It is a mismatch in the announcement: "open-source skills" beside "open-weight models" reads as a self-contained stack, and today it is not one. For the broader pattern, where skills become the unit of distribution, see NVIDIA's Skill2Env, which trains on 3.4k public skills, and Beacon, which grades agent runs after the fact. The UI skill's loop (generate a mock, decompose it, implement it, screenshot, compare) is the visual cousin of json-render's decision-model approach to generative UI.

The licence is MIT, and mostly means it

The weights are MIT in both Hub repos: the standard text, "Copyright (c) 2026 inclusionAI". The GitHub code is MIT at the root, with Apache-2.0 headers on several of its source files. Both skills are MIT, "Copyright (c) 2026 Ant Group". Measured.

That is the opposite of what this site found three days ago, when Qwen-Image-2.1 moved an Apache-2.0 family to a non-commercial research licence under an "open-source" announcement. Here "open" means what it says, with one wrinkle: most of what is open was someone else's first.

Reasoned, and a reading of licence text rather than legal advice. Four of the five inherited parts come from Apache-2.0 or MIT sources, which permit exactly this. Apache-2.0 also asks that redistributed copies carry its licence text and keep the upstream copyright notices. The VAE is Qwen's Apache-2.0 file redistributed unmodified under an MIT-only repo, and transformer.py's Z-Image copyright line has been replaced rather than kept. Both are fixable with a NOTICE file. Neither changes what you can do with the weights.

The exception is the vision tower. Its merger norm sits 0.04% from Qwen2.5-VL-72B-Instruct's. Its 8,192-wide output fits only the 72B. The 72B ships under the Qwen License, which asks for a copy of the agreement, a "Built with Qwen" notice for models built from it, and a separate licence above 100 million monthly users. inclusionAI has shipped the same tower under MIT since at least Ming-Lite-Omni-1.5 in July 2025, whose vision weights sit 0.1–1.4% from Ming-Image's. It is a long-standing position rather than an oversight in this release. For most users the 100M line is irrelevant. For the few it touches, it lives in a 0.70B component that only runs when an image goes in.

Where it sits in the Ling and Ming family

The family links are real, not decorative. The language model inside mllm/ is Ling-mini-2.0, a 16B model from the Ling 2.0 generation, one step before the models this site covered as Ling-3.0-flash and its finance fine-tune Ling-3.0-flash-Fin. The recommended prompt rewriter is Ling-3.0-flash-VL, 124.8B parameters by the Hub's count. Run the README's full recommended path and the "6B" design model has a 125B model in front of it. The skills are named "Ling" because they live in the Ling cookbook, and their environment variables are LING_*. The architecture comes from Ming-flash-omni-2.0, whose image head was already a Z-Image DiT behind the same kind of Qwen2.5-1.5B connector and 256 query tokens. Ming-Image-0.1 is that recipe moved to a smaller language model, a base rather than Turbo DiT, and an RGBA VAE.

What is missing

Verified by absence, as of 23 September:

• No technical report. No paper for Ming-Image, and none for CLEAR, the method the Layer card's only table is about.
• No credit for the parts. Neither model card nor the GitHub README mentions Z-Image, Qwen-Image-Layered, Qwen2.5-1.5B or Qwen2.5-VL. The code headers credit Qwen for the VAE and ViT code. Nothing credits Z-Image.
• No training data disclosure, including whether Crello's training split was used.
• No evaluation of the Design model beyond the arena, and none of RGBA quality at all.
• No raw layer outputs. Every published layer is a checkerboard preview.
• No speed or memory figures, beyond "one 80 GiB GPU".
• No quantised release. BF16 shards, plus FP32 for the connector, the query tokens and the whole Layer DiT.
• No video. Nothing on the Hub, in the GitHub repo or in the cookbook. There is nothing to embed here.
• No limitations section. The showcase renders brand marks: an Instagram interface, and a Volkswagen badge on the transparent sedan. The card has nothing to say about that.

The take

Ming-Image-0.1-Design is a good fine-tune of a good open model, released under a licence that lets you use it. The engineering is legible from the files. Z-Image's base DiT is re-aimed at a Ming multimodal encoder through 256 learnable queries and a Qwen2.5-1.5B connector, with a parallel shortcut from three of the language model's layers. Its RGB VAE is swapped for Qwen-Image-Layered's RGBA one, which fits because both are 16 channels at 8×. Layer decomposition is done the Qwen-Image-Layered way, as frames of the same model. The arena measures what that training bought: +244 Elo over its parent on UI/UX prompts. That is the number I would lead with.

The announcement leads with a rank instead, and the rank is precise and narrow. First of 42 open-weight models in the one view the claim names, by about two standard errors, over a runner-up you cannot use commercially. Sixteenth of 129 when the closed models are left in. Forty-fifth overall. For a team that needs an MIT-licensed model to draw interfaces and posters, that is a strong case, stronger than the headline once licences are counted. For anyone reading "#1" as "best", it is 145 Elo short.

The Layer model and the skills are the more interesting half, and the less evidenced one. The only number for the Layer model belongs to an unpublished method with a different name, against a table that is mostly Qwen's own. The skills are careful, honest agent packages that, as shipped, call a hosted decomposition service the open weights do not reproduce, at a route and a model id that OpenRouter did not serve the day after release.

Sorting this article's claims by what they rest on. Reported is the arena data: every Elo, interval and appearance count is Artificial Analysis's own, read from its page on 23 September, along with its methodology and the Crello table's numbers. Measured is the parameter counts from every shard header; the SHA-256 identities; the 38,464-value DiT fingerprint and the smaller ones for the connector, language model and vision tower; the code overlap with diffusers' Z-Image; the alpha histograms of the three native samples; the 48-number match to Qwen's table; the 17 skill paths; and the OpenRouter listings and routes. Reasoned is the FLOP split, the layer-count cost, CLEAR's identity, the skills' dependence on a hosted service, and every licence consequence.

Sources, all read directly: the Hub repos inclusionAI/Ming-Image-0.1-Design at 1cd7fac and inclusionAI/Ming-Image-0.1-Design-Layer at 6504487 (every config, every shard header by range read, the LFS SHA-256s, LICENSE); the code at inclusionAI/Ming-Image at 62c6072; the skills at inclusionAI/ling-cookbook at 71d596e and PRs #5 and #6; for comparison, Tongyi-MAI/Z-Image, Tongyi-MAI/Z-Image-Turbo, inclusionAI/Ming-flash-omni-2.0, Qwen/Qwen-Image-Layered, Qwen/Qwen2.5-1.5B, Qwen/Qwen2.5-VL-72B-Instruct and inclusionAI/Ling-mini-2.0, each by a few kilobytes of range read, and diffusers v0.36.0's transformer_z_image.py; the Artificial Analysis text-to-image leaderboard and methodology, both on 23 September; the Qwen-Image-Layered paper, Table 1 and §4.1; OpenRouter's public model API; and vLLM-Omni PR #8021. The figures are the release's own, flattened and resized, except fig7, which is my own rendering of one of its samples; see NOTICE.txt beside them. I measured the alpha histograms myself.