OUI-1: The First Open Model Built for Generative UI

Thesys published OUI-1 on 8 September 2026, calling it the first model built specifically to generate user interfaces. It is a finetune of Google's DiffusionGemma with 26B total and 4B active parameters, the weights are on Hugging Face, and it scores 71.7% on the Generative UI Benchmark against its base model's 13.0%. That is a 5.5x improvement on a task where nothing at this size was previously usable.

The number the launch post does not put beside it is the rest of the leaderboard. On Thesys's own public board, which now lists 31 models, 71.7% places OUI-1 twenty-first. Eight hosted models beat it while charging under a cent per screen, and one of them, DeepSeek V4 Flash, scores 85.8% at $0.0004 per task.

Both facts are true and neither cancels the other. What follows is what OUI-1 actually gives you, what the published measurements were taken on, and the three behaviours in the shipped model card that will surprise anyone who wires it into an app this week.

What OUI-1 is

OUI-1 does not write React, HTML or CSS. It writes openui-lang, a declarative language where one component goes on each line and the lines are wired into a root. Given a component library's signatures in the system prompt and a plain-language brief, the model returns a screen as a short program. Thesys says the language costs up to 67% fewer tokens than the equivalent JSON and streams, so a screen begins appearing before generation finishes.

The base model choice is the interesting part. Autoregressive models emit one token at a time and are bottlenecked on memory bandwidth. DiffusionGemma writes a 256-token block at once, starting from noise and committing each token as soon as its entropy falls below a bound. Google reported over 1,000 tokens per second on a single H100 for the base model, which is why we covered it as Google's 4x faster open text model when it launched.

The licence is a Gemma derivative, not Apache or MIT. The model card is explicit: the Gemma Terms of Use apply, and so do the base licence's use restrictions. Anyone planning to ship OUI-1 inside a commercial product should read those terms rather than treat "open weights" as a synonym for "unrestricted".

Two more constraints sit in the card and matter for integration. Context is 16,384 tokens as served, which has to hold the entire component library signature block plus the brief. And the model is described as "not a general chat model", with the recommendation that outputs be validated by the openui-lang parser and rendered through a library that checks its props.

Where 71.7% actually sits

The Generative UI Benchmark is public and unusually well documented for a vendor benchmark. The protocol is 46 screen briefs across five size bands, four generations each, thinking off, one shared system prompt for every model, scored by the benchmark's own validator. A screen counts as valid only if it parses, has a root, every reference resolves, nothing is orphaned or invented, and no prop is missing or out of range. Base DiffusionGemma completed 24 of 184 runs. OUI-1 completed 132.

Thesys publishes both a narrow table, open-weight models up to 31B active, and the full 31-model board. The narrow table is the one in the announcement, and on it OUI-1 loses only to Alibaba's dense Qwen3.8 27B. The full board tells a different story.

Twenty models score higher. Thirteen of those twenty cost under two cents a screen, and eight cost under one cent. The board's own footnote is worth quoting because it is the honest version of the pitch: "Self-hosted cost is unknown, not zero."

So OUI-1 is not the accuracy play and it is not obviously the cost play either, once a GPU-hour is priced in. It is the locality play. Nothing leaves the machine, there is no network round trip in the interaction loop, and there is no per-call meter. Whether 71.7% is enough depends entirely on whether your renderer treats an invalid screen as a retry or as a crash.

The RTX 5090 line and the A100 numbers

The announcement says OUI-1 "can run on consumer grade GPU (RTX 5090, at FP8)". The model card, read next to it, complicates that in three ways worth knowing before anyone orders hardware.

First, every published timing came from an A100 80GB. The card states the serving settings plainly: vLLM 0.24, FP8, the checkpoint's own sampler at 48 denoising steps, one request at a time. On that machine a light screen takes about a second and a dense one three to six seconds, prompt included. No RTX 5090 timing is published anywhere in the release. Google's own figure of over 700 tokens per second on a 5090 is for base DiffusionGemma, and OUI-1 emits 28% more tokens than the base model does.

Second, the memory fits but not spaciously. The weights take 25.8 GiB at FP8. NVIDIA specifies 32 GB of GDDR7 on the RTX 5090, which leaves roughly six gigabytes for KV cache at a 16,384-token context. The card warns that vLLM fills the rest of the card with KV cache by default, so --gpu-memory-utilization is not optional on a shared or tight GPU.

Third, and most easily missed: the card notes that Ampere has no native FP8, so on the A100 vLLM falls back to weight-only FP8 through Marlin, where "the memory saving is real, the compute speedup is not." A Blackwell card like the 5090 does have native FP8, so the arithmetic could go better there while the far lower memory bandwidth pulls the other way. The result is genuinely unknown rather than merely unpublished, and the claim that this thing runs on a laptop, which circulated widely after launch, is not supported by a 25.8 GiB weight file.

Running it, and three things that will catch you out

The path from download to first screen is short. Generate a system prompt from your own component library with npx @openuidev/cli generate <library.ts> --out system-prompt.txt, or borrow the benchmark's reference prompt to try it unmodified. Serve it with vLLM 0.24 or newer, then call it as an ordinary OpenAI-compatible chat model. Render the result with @openuidev/react-lang, or the Vue and Svelte renderers, and validate with @openuidev/lang-core. Mac users have no official route, though one community project, diffgemma, is aimed at exactly that gap.

Three documented behaviours will break naive integration code.

Sampling is not controllable and not reproducible. The card states that temperature and seed are ignored, because the sampler runs the checkpoint's own schedule and no per-request seed is plumbed through. Two identical requests can return differently worded screens. Any test suite that asserts on exact output, and any product that promises a user the same screen twice, needs a different strategy.

Forced tool calls fail silently. The model keeps Gemma 4's native tool-call format and calls tools well: in Thesys's test it picked the right tool with the right arguments on 9 of 9 relevant asks and called none on 3 unrelated ones. But tool_choice must stay on auto. Setting required or naming a function is accepted and then ignored, and the response comes back carrying finish_reason: "tool_calls" while the tool_calls array is empty. Branching on finish_reason alone will send an agent down a path with no call to execute. vLLM has no structured outputs for diffusion models yet, which is the underlying reason.

Streaming arrives in blocks, not tokens. Because the model writes a 256-token canvas at a time, stream=True delivers one canvas per chunk. A screen that fits in a single canvas arrives as one lump. Progressive-reveal UI built for autoregressive token streams will look broken rather than fast. On the same theme, the denoising step cap is set through --diffusion-config and not through --hf-overrides, whose keys the card says are not read at all. Thirty-two and forty-eight steps score identically on the benchmark; sixteen breaks the reference graph.

How the score went from 13% to 71.7%

The training write-up is more useful than the model, and it is the part most likely to be copied by other teams this year.

Supervised finetuning alone did not work. Roughly 700 examples across seven component libraries, LoRA on a single A100, brought the loss down and the benchmark score with it, because the model learned to write longer, denser programs that almost never parsed. Narrowed to the single library the benchmark uses, the score rose from 13.0% to 28.8%, but the two error classes traded places run after run: one pass cut wiring errors from 66 to 40 while schema errors rose from 78 to 112, and the next reversed it. Worse, generation slowed from 1.6 seconds per output to 4.3, because a model writing real names and values needs about twice the denoising steps of one writing generic filler.

The unlock was noticing that openui-lang has a verifiable reward. The parser can say whether a program is structurally valid and name the exact defect when it is not, which lets the model teach itself: generate a few hundred programs, keep the ones the parser accepts, send near-misses through a repair pass that fixes only the listed defects and rejects any edit that rewrites or invents, have a judge check each survivor against its brief, then retrain on what is left. Five hundred steps, an hour or two on one A100, and the resulting model writes the next batch.

That loop stopped the see-saw. Schema errors fell from 292 to 76 and wiring errors from 971 to 484 in the same model, the benchmark reached 57.1%, and generation time came back down from 4.3 seconds to 1.9 despite longer outputs. Defect density across the three checkpoints reads 35.3, then 16.4, then 3.8 per 100 statements. Repeating the recipe across 27 component libraries produced the released model, and it generalised: on an AppLess component library never seen in training, 60 unseen briefs yielded 55 valid outputs against base DiffusionGemma's 23. The technique is rejection-sampled self-training with a parser as the reward function, related to published work on self-distillation through time for diffusion language models, and it applies to any output format with a strict validator. We looked at the same underlying speed argument from a different angle in our comparison of diffusion LLMs for agents.

Who this is actually for

Not, on this evidence, a designer looking for a Figma replacement. OUI-1 does not produce visual design, it produces a valid component graph, and how that graph looks is entirely a function of the component library you point it at.

The real fit is narrower and more interesting: software whose interface has to be assembled at the moment of use, from context that should not be sent to an API. One-off dashboards answering a question nobody anticipated. Agent turns that need to hand back a form rather than a paragraph. Task-specific panels stripped out of an application too large to navigate. Thesys's own AppLess project is the demonstration, and the milestone the release is really claiming is that AppLess previously required Gemma 4 running on Cerebras hardware and now runs on an open 4B-active checkpoint.

If that shape describes something you are building, the evaluation is cheap and concrete. Point the CLI at your existing component library, run twenty briefs that look like your real ones, and count how many parse clean. Twenty-eight points of validity is what you are trading away against a hosted call; whether that trade is affordable depends on how gracefully your renderer handles the misses.

Frequently asked questions

Can OUI-1 run on a consumer GPU?

On memory, yes: the FP8 weights are 25.8 GiB and an RTX 5090 has 32 GB. On performance, unknown. Every timing Thesys published was measured on an A100 80GB, and no 5090 benchmark appears in the release. Expect to pass --gpu-memory-utilization, because vLLM claims the remaining VRAM for KV cache by default.

Is OUI-1 free to use commercially?

The weights are downloadable but the licence is the Gemma Terms of Use, applied as a derivative, so the base licence's use restrictions carry over. It is not Apache or MIT. Read the terms before shipping it in a product.

How does it compare to just calling an API model?

Worse on validity and, on the published board, worse on price once you count the GPU. Twenty models on the same 31-model leaderboard score higher, thirteen of them for under two cents per screen. What you get instead is local execution: no round trip, no per-call meter, and no data leaving your machine.

Why a diffusion model instead of a normal LLM?

Latency. Generative UI has to produce an interface inside the interaction, not after it. A block-diffusion model writes a 256-token canvas at once rather than one token at a time, which removes the per-token memory-bandwidth bottleneck. The cost is that streaming arrives one canvas at a time and sampling controls like temperature and seed do nothing.

What is openui-lang and do I have to adopt it?

It is a declarative language where each line is one component and the lines wire into a root, designed to cost fewer tokens than JSON and to stream cleanly. Yes, you have to adopt it to use this model: OUI-1 writes nothing else. You supply your own component library's signatures, so the components stay yours, but the output format does not.

Does it work with tool calling?

Yes, using Gemma 4's native format with the gemma4 parser, and it tested at 9 of 9 correct calls with no false positives on 3 unrelated asks. Leave tool_choice on auto. Forcing a call is accepted and ignored, and returns an empty tool_calls array alongside a tool_calls finish reason.