OUI-1 is a finetuned DiffusionGemma model that writes user interfaces in openui-lang. It is 26BA4B model that can run on consumer grade GPU (RTX 5090, at FP8), and the weights are on Hugging Face under Apache 2.0, the same license as the base model.
\nAgent-driven interfaces are the future of software. But getting there comes down to three constraints. Interfaces must be generated in under a second. They must be reliable enough to use as software. And the models must be small enough to run locally on consumer hardware.
\nWith AppLess, we explored that experience using Gemma 4 on Cerebras. But it depended on specialized hardware in the cloud. Moving it onto the device means solving a harder problem: preserving responsiveness with dramatically less compute, without sacrificing the quality or correctness of the generated interface.
\nOUI-1 is our first step toward solving that problem: an open-weight model built to generate reliable interfaces on consumer hardware. The ambition is reliable, agent-driven interfaces generated locally at the speed of traditional software.
\nThe protocol was already in place. OpenUI Lang costs up to 67% fewer tokens than JSON and streams, so the interface starts appearing before the model has finished generating it. The harder part was finding a model with the right speed and hardware profile.
\nThat is why we chose DiffusionGemma. Autoregressive models generate 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 the moment it is sure of it. Google reports over 1,000 tokens per second on a single H100 and over 700 on an RTX 5090[1].
\nDiffusionGemma gave us the speed we were looking for. But speed alone does not make software: the interfaces also have to work. That was the gap we needed to close.
\nThe benchmark made the gap concrete. DiffusionGemma scored 13.0% on the Generative UI Benchmark. It had the speed and hardware profile we wanted, but not the reliability.
\nThe OpenUI Lang parser made those failures easy to see. A schema error is a wrong enum, a missing required prop, or an invented component. A wiring error is a name used but never defined, or a section defined but never attached to the root.
\nheader = CardHeader("Spending", "last 7 days")
\ntotal = Heading("$24,180", "h9")// schema: h9 is not a heading level
\nchart = AreaChart(days, [spend], "wavy")// schema: "wavy" is not a curve type
\nfooter = TextContent("Updated today")// wiring: defined, never attached to root
\nroot = Card([header, total, chart, summary])// wiring: summary is never defined
\nThat became our north star: bring both kinds of error down without giving up speed.
\nThe training unfolded in two stages. First, we taught DiffusionGemma to write OpenUI Lang through supervised fine tuning. Then we used self-distillation to recover its speed and improve its reliability. Once that worked on one component library, we repeated the process across 27.
\nWe started with about 700 OpenUI Lang examples written by larger models, spread across seven component libraries, and ran a LoRA fine-tune on one A100. The loss went down. But the benchmark score went down with it. The model had learned to write longer, denser programs, and almost none of them parsed cleanly.
\nWe narrowed the problem to a single component library: the one used by the benchmark. The score rose from 13.0% to 28.8%, but progress came with a tradeoff. One run reduced wiring errors while increasing schema errors; the next did the reverse:
\n| run | schema errors | orphaned sections |
|---|---|---|
| n | 78 | 66 |
| n + 1 | 112 | 40 |
| n + 2 | 51 | 65 |
The two error types moved like a see-saw. We were well ahead of the base model, but no run brought both down together. We assumed we had reached a capacity limit of the LoRA: it could learn one discipline at a time, and a full fine-tune would resolve the tradeoff later.
\nWhere the errors went
\n2802DiffusionGemma24/184 runs complete\n35.3 defects per 100 statements
\n1263after supervised finetuning53/184 runs complete\n16.4 defects per 100 statements
\n20313.8× fewerOUI-1132/184 runs complete\n3.8 defects per 100 statements
\nschema errorswiring errors: undefined names and orphaned sections
\nThen we found a second problem: the model had become slower. We had expected fine tuning to make it faster. The sampler commits a token once its entropy falls below a bound, so a model that knows the language should become certain sooner. Instead, on the same 20 light briefs, generation time rose from 1.6 seconds per output to 4.3.
\nThe base model was fast because its outputs were short and generic, averaging 22 tokens per statement. The fine-tuned model wrote real names and values, averaging 32 tokens per statement, and needed about twice as many denoising steps to commit each token. We had taught it to produce more useful interfaces, but lost the speed that made DiffusionGemma interesting in the first place.
\nSeconds per output, before and after supervised finetuning
\nSame 20 light briefs, one request at a time, same serving settings for both rows: vLLM, FP8, one A100.
\nDiffusionGemma1.6s
\nafter supervised finetuning4.3s
\nThe finetuned model writes longer outputs and needs about twice the denoising steps per token: it is committing real names and values where DiffusionGemma commits short, generic ones.
\nThe breakthrough was realizing that OpenUI Lang has a verifiable reward. The parser can tell us whether an interface is structurally valid and identify the exact schema or wiring errors when it is not. That meant the model could become its own teacher: generate programs, keep or repair them using the parser's feedback, and learn from the result. Self-distillation also offered a path to recovering speed because it is a known way to reduce the denoising steps used by diffusion language models[2][3].
\nOur version uses rejection-sampled self-training with repair. The model writes a few hundred OpenUI Lang programs, and the parser keeps the ones it accepts. Near-misses go through a repair pass that fixes only the defects reported by the parser; we reject any edit that rewrites or invents. The median repair changes one statement. A judge then checks whether each surviving program matches its brief. Those programs become the training set for the next run: 500 steps, taking an hour or two on one A100. The resulting model generates the next batch, and the loop begins again.
\nSelf-distillation: generate, verify, retrain
\n1 · generatethe model writes a few hundred openui-lang programs
\n→
\n2 · verifythe parser keeps the ones that pass clean; a judge checks each against its brief
\n→
\n3 · repairnear-misses fixed by an LLM, listed defects only, rewrites rejected
\n→
\n4 · retrainthe survivors become the next training set
\neach pass trains the model that writes the next batch
\nThe speed came back: on the same 20 light briefs, generation time fell from 4.3 seconds per output to 1.9, even though the outputs contained 28% more tokens than DiffusionGemma's. Then the see-saw stopped. The benchmark score reached 57.1%, schema errors fell from 292 to 76, and wiring errors fell from 971 to 484 in the same model. Every earlier run had traded one error type for the other; self-distillation improved both.
\nIn effect, this is reinforcement learning in its simplest form: rejection sampling with the parser as the reward. Our hypothesis—which we have not isolated—is that training on the model's own text keeps the loss low almost everywhere, concentrating the gradient on the few things that changed: repaired statements and sampled choices pushed toward the mode. The first teaches the wiring fix; the second sharpens the model so the entropy bound can commit tokens earlier. Teacher-written data spreads that gradient across an entirely different writing style.
\nThe one-library result left us with another question: had the model learned to generate interfaces, or had it learned one component library? We applied the same recipe—supervised fine tuning followed by self-distillation—across 27 component libraries.
\nThe result was OUI-1. On the Generative UI Benchmark, it scored 71.7%, up from DiffusionGemma's 13.0%. Every open model with up to 31B active parameters scored lower, including Gemma 4 31B at 46.7%, with one exception: Qwen3.8 27B at 78.8%. Qwen3.8 is a dense model that uses 27B parameters on every token, compared with OUI-1's 4B active parameters. Nothing at 4B active parameters or below scored higher; the next step up in score required a dense 27B.
\nGenerative UI Benchmark, open-weight models up to 31B active
\nView data
\n| model | active params | OpenUI score |
|---|---|---|
| OUI-1 (DiffusionGemma, finetuned) | 4B | 71.7% |
| DiffusionGemma | 4B | 13% |
| Qwen3.8 27B | 27B | 78.8% |
| Qwen3.6 27B | 27B | 68.5% |
| Qwen3.6 35B-A3B | 3B | 61.4% |
| Gemma 4 31B | 31B | 46.7% |
| Phi-4 14B | 14B | 44% |
| Gemma 4 26B-A4B | 4B | 29.9% |
| Ministral 8B | 8B | 27.2% |
| Granite 4.1 8B | 8B | 14.7% |
| LFM 2.5 2.6B | 2.6B | 3.3% |
The gain also generalized beyond the benchmark library. On the AppLess library, we tested 60 asks that the model had never seen during training. OUI-1 produced 55 valid outputs; DiffusionGemma produced 23.
\nValid outputs on the appless phone library
\n60 asks written independently of every training file, one output each, counted valid when it parses clean: no schema errors, every name defined, at least three statements.
\nDiffusionGemma23 / 60
\nOUI-155 / 60
\nA different component library from the benchmark's, with its own signatures in the system prompt. None of these asks or outputs were trained on.
\nOUI-1 did more than bring us back to where we began. AppLess had relied on Gemma 4 running on Cerebras; it now runs on OUI-1. On the benchmark, OUI-1's 71.7% surpassed both Gemma 4 31B at 46.7% and Gemma 4 26B-A4B at 29.9%. The experience that first required specialized inference hardware can now be powered by an open-weight, 4B-active model built to run on consumer hardware.
\n[Model release
\nDownload the open-weight model from Hugging Face.
\n26B parameters · 4B active · FP8View model weights](https://huggingface.co/thesysdev/OUI-1)[Open evaluation
\nReview the scoring code and raw generations on GitHub.
\n71.7% Generative UI BenchmarkView benchmark](https://github.com/thesysdev/Generative-ui-bench)
\nThree directions matter from here:
\nGoogle, [DiffusionGemma: faster text
generation](https://blog.google/innovation-and-ai/technology/developers-tools/diffusion-gemma-faster-text-generation/)
Deschenaux and Gulcehre, [Beyond Autoregression: Fast LLMs via Self-Distillation Through
Zhang et al., [T3D: Few-Step Diffusion Language Models via Trajectory Self-Distillation with
Direct Discriminative Optimization](https://arxiv.org/abs/2602.12262)