LLaDA-UI Quietly Ships: inclusionAI's Diffusion GUI Agent Is Now Downloadable

LLaDA-UI — a roughly 16.7-billion-parameter mixture-of-experts GUI agent from inclusionAI — appeared on Hugging Face on September 6, 2026, with no announcement attached. What makes it worth a second look is not the silence but the mechanism underneath: instead of writing its next action one token at a time the way the autoregressive vision-language models that dominate computer-use research do, LLaDA-UI denoises an entire block of action tokens per step, diffusion-style, and only then commits to the answer. The vendor bills it as a practical, open-weight diffusion GUI agent. Everything below is labeled for what it is: repository facts you can check yourself, technical-report claims that nobody outside the lab has reproduced, and gaps — a missing license chief among them — that are still genuinely unresolved.

The release frame matters because this is now a pattern. inclusionAI is the Ant Group-affiliated lab behind the LLaDA family of diffusion language models, and the same week it published the LLaDA-Image and LLaDA-Image-Turbo image checkpoints (September 4) and the LLaDA2.2-mini agent model (September 5), it created the inclusionAI/LLaDA-UI repository on September 6. Three model families in three days, none of them preceded by a launch post. For LLaDA-UI specifically, the evidence of an actual release is the repository itself: the safetensors weights are present and loadable, the inference code and an SGLang serving recipe ship alongside them, and a technical report and project page exist. What is not present is any vendor announcement, any license, or — at the time of writing, with downloads still in single digits — any sign that the wider world has noticed it yet.

Shipped, but not announced

The inclusionAI/LLaDA-UI repository was created at 05:08 UTC on September 6 and is a complete, self-contained model drop rather than a placeholder. Twenty-one files are in the tree: seven BF16 safetensors shards that sum to about 16.9 billion parameters (the model card rounds to ~16.7B total), the tokenizer and config files, and — importantly — the model's own Python source (modeling_llada2_vl_moe.py and configuration_llada2_vl.py). The architecture registers as LLaDA2MoE_VLForConditionalGeneration under a llada2vl model type, and because those files ship inside the repo this is not a stock-Transformers architecture: loading it means pulling the custom code, either by cloning the repo or through the hub's remote-code path.

What the repository does not carry is just as informative. There is no license tag on the model card and no LICENSE file in the tree, so the standard question a commercial team asks first — what am I allowed to do with these weights? — has no answer yet. The paper is a technical report distributed as a PDF inside the GitHub repository and linked from a project page; it has not appeared on arXiv (the page still says "SOON"). And no inference provider we can find is serving the model: the Hugging Face card reports no deployed inference provider, which means that for now LLaDA-UI is a download-and-self-host release, not something you can call through an API. We do not host it either — nothing in this piece should be read as a claim that we do.

A GUI agent that decodes like an image model

The design is the story, so it is worth being precise about how LLaDA-UI differs from the autoregressive GUI models it is measured against. A conventional computer-use model — Qwen2.5-VL-7B or Qwen3-VL-8B, say, or the VLM behind a hosted computer-use product — takes the screenshot and the instruction, then predicts one token at a time, left to right, until the action string is complete. Latency therefore scales with the number of tokens in the answer. LLaDA-UI instead treats the entire response as a block that is initially masked and progressively denoised: each decoding step refines many tokens in parallel, and after a fixed number of steps (the reference script uses 32 steps with a block length of 32) the full reasoning-plus-action string is revealed. That is the same conceptual move the lab made with image generation, applied to GUI actions.

Under the hood the stack is: a native-resolution vision encoder, a spatial projector, and a diffusion language model. The vision encoder is a ViT initialized from SigLIP, given 2D rotary position embeddings, and run at the screenshot's native aspect ratio — the card sets an IMAGE_MAX_PIXELS of 12,845,056, so roughly 12.8 megapixels of input before downscaling, which matters for small click targets on dense desktop UIs. Its output is grouped spatially four-to-one and passed through a two-layer MLP projector into a language backbone that is the LLaDA2.0-mini MoE diffusion language model. So the "17B params" the Hugging Face sidebar shows is a mixture-of-experts model; only a fraction of parameters is active for any given forward pass, which is part of why the latency story below is even plausible.

The training recipe is worth noting because it is unusually economical on paper. According to the technical report, the multimodal backbone was pre-trained on roughly 145 billion tokens in a three-phase curriculum — a short projector-only alignment phase, then perception-heavy and reasoning-heavy full-model phases — before a GUI-agent supervised fine-tune on more than six million samples drawn from the UI-Venus project, spanning more than 100 Chinese mobile applications, more than 70 English mobile applications, plus desktop and web data. The vendor's framing is that 145B tokens is a fraction of what autoregressive peers consumed (the report cites 4.1T for Qwen2.5-VL and 2.2T for Qwen3-VL). Treat the token counts and the data mix as the lab's own account; what is independently checkable is only that the model exists and runs.

What it actually emits

LLaDA-UI has two output modes, and the difference matters for how you would wire it into a pipeline. In grounding mode the model returns a single point: integer coordinates normalized to a [0, 999] range for the target, e.g. [742, 186], which the reference script also prints as a 0-to-1 fraction to multiply by the screenshot's width and height. If the requested target is not present in the image, the model is trained to answer [-1, -1] rather than hallucinate a location — a small but important reliability property for an agent loop. In agent/navigation mode the model emits a reasoning tag followed by a structured action:

<think>The search bar is at the top of the page, below the logo.</think><action>Click(box=(742, 186))</action>

The action vocabulary is defined per platform — mobile, desktop, and web — and despite the field name, box holds a single interaction coordinate rather than a rectangle. The think/action split is what lets the model ground its decision in the current screen before committing to a click, and the coordinate-based output is what keeps the result machine-parseable rather than a free-form instruction a separate parser has to interpret.

The benchmark claims, labeled

The technical report's headline results are a set of claims about a diffusion GUI model beating autoregressive ones at their own game. Reproduced here exactly as the vendor reports them, from the technical report and project page — none of this has been independently reproduced, and the numbers below are LLaDA-UI versus Qwen3-VL-8B unless noted:

• ScreenSpot-Pro (grounding) — LLaDA-UI 52.9 vs Qwen3-VL-8B 52.7, a narrow edge.

• AndroidWorld (mobile agent) — LLaDA-UI 53.5 vs Qwen3-VL-8B 47.9.

• MobileWorld (mobile agent) — LLaDA-UI 25.6 vs Qwen3-VL-8B 9.4, the largest gap on the board.

• WebVoyager (web agent) — LLaDA-UI 56.9 vs Qwen3-VL-8B 45.2.

Those are four of the six reported GUI benchmarks; the report is candid that LLaDA-UI does not clear Qwen3-VL-8B on the other two — ScreenSpot-V2 is close, and OSWorld-Verified remains a gap, which the authors attribute to degradation on very large screenshots with small targets. Against the older Qwen2.5-VL-7B the claim is unconditional: wins on all six reported benchmarks. There is also a speed claim, measured by the lab on paired non-cached serving runs on identical hardware: 4.8 to 6.4 seconds per response for LLaDA-UI versus 17 to 53 seconds for Qwen3-VL-8B, quoted as mean speedups of 3.58x on web inputs, 6.83x on desktop, and 8.95x on mobile — while generating more tokens per call, the report says, because parallel block decoding wins on wall-clock even when the answer is longer.

Read the latency claim with the same skepticism as the accuracy numbers. Diffusion decoding's parallel-block advantage is mechanistically real, and the direction of the effect — fewer sequential steps per response — is consistent with how the architecture works, but 3.6x-to-9x speedups were measured by the people who built the model on hardware of their choosing, and they have not been replicated. The accuracy gaps matter too: OSWorld-Verified is the closest thing the field has to a realistic desktop-agent test, and that is precisely where the authors say the model struggles, on large screenshots with small targets. A GUI agent that nails mobile and web but slips on dense desktop UIs is a specific strength profile, not a general one.

How to run it, and what is still missing

If you want to try LLaDA-UI yourself, the path is weights-first. The checkpoint is about 32 GB in BF16. The reference environment is Python 3.10, PyTorch 2.5.1, Transformers 4.51.0, and FlashAttention 2.7.4.post1, and the quick-start runs a single-image grounding pass with --gen-length 32 --steps 32 --block-length 32. Serving is possible through SGLang, but only via the lab's own launcher: the repository ships a serve_llada_ui.sh and a client script that assume LLaDA-UI-specific multimodal diffusion patches, and the model card is explicit that it cannot be started from a stock SGLang installation. Large screenshots may also require raising the default --max-length of 8192. This is a model for people comfortable cloning a repo, building FlashAttention against their CUDA setup, and debugging a diffusion decode — not yet a one-command API call.

Four things would change what a reader can do with LLaDA-UI, and none of them has happened as of this writing. A declared license would settle the commercial question that currently has no answer. An arXiv entry would turn the in-repo technical report into something citable and peer-scrutinizable. An independent reproduction of the ScreenSpot-Pro through WebVoyager numbers would separate the architecture's real capability from its authors' evaluation. And a provider actually serving the model would make it testable without a 32 GB download and a GPU. If and when that last step happens, the routing question becomes routine — one API key across the model catalogs, provider list prices passed through with no markup, and automatic failover so a three-day-old checkpoint never sits on a production path by itself. Until then, LLaDA-UI is an unusually interesting open weights to watch: a diffusion GUI agent with real benchmark claims, a specific and honestly disclosed weakness, and none of the legal or operational scaffolding that would let most teams adopt it today. Watch the repository for the license and the paper, in that order.