Thesys has published OUI-1, a specialised AI model that generates user-interface screens as openui-lang programs from a component library and a plain-language description. The company’s model card reports a score of 132 out of 184, or 71.7%, on its Generative UI Benchmark, compared with 24 out of 184, or 13.0%, for the underlying DiffusionGemma model.
The result comes from a publisher-run software benchmark rather than an independent or peer-reviewed evaluation. It also does not establish that generated interfaces will be reliable, accessible, secure or suitable for unsupervised use in production.
Contents
- What OUI-1 changes
- How the model generates an interface
- What the benchmark measured
- Deployment requirements and limitations
- What remains to be tested
What OUI-1 changes
Most general-purpose language models produce prose or conventional code. OUI-1 is adapted specifically to produce structured UI descriptions that can be rendered through OpenUI-compatible applications.
Thesys describes OUI-1 as the first diffusion model built for generative UI.
The model is a fine-tune of Google’s DiffusionGemma-26B-A4B-it. It has 26 billion total parameters and 4 billion active parameters. Its intended use is not general conversation, but generating screens for OpenUI-based applications where a small, self-hosted model and low latency are useful.
The workflow separates screen generation from screen rendering:
- A developer supplies the signatures of a component library in the system prompt.
- The user or application provides a natural-language description of the desired screen.
- OUI-1 writes an
openui-langprogram containing the requested components. - An OpenUI renderer uses the program and the component library to produce the interface.
A component library provides reusable elements and the properties they accept. Because the generated program refers to those elements and properties, the output must match what the renderer supports. The model card recommends parsing the result with the openui-lang parser and using a component library that checks component props before rendering.
openui-lang is declarative: it describes which interface components and relationships should exist rather than specifying every rendering operation step by step. This allows the same generation model to work with a library whose component signatures are supplied in the prompt, although the model card does not establish equal performance across arbitrary libraries.
How the model generates an interface
OUI-1 uses a diffusion-language approach rather than relying only on conventional token-by-token autoregressive generation. According to the model card, it generates a 256-token block at a time.
The process begins with noise and progressively commits tokens as they become sufficiently certain. In practical terms, this gives the model a fixed-size textual canvas for producing a UI program. The output is organised as one component per line, wired into a root component.
The model is available as merged BF16 safetensors and is also accompanied by a LoRA adapter. LoRA, or low-rank adaptation, fine-tunes an existing model by learning smaller updates to its weights rather than retraining every parameter. The model card says the adapter was merged into the base weights for the published checkpoint.
OUI-1 has a served context length of 16,384 tokens. The model card documents deployment through vLLM, Transformers, SGLang, Docker Model Runner and local applications. It can also be connected to OpenUI applications, while the component definitions remain part of the application’s prompting and rendering setup.
What the benchmark measured
Thesys evaluated OUI-1 using 46 screen briefs divided across five size bands. Each brief received four generations, producing 184 generated screens per model. The evaluation used one shared system prompt and the benchmark’s validator.
Under that protocol, the model card reports:
| Model | Validated screens | Score |
|---|---|---|
| OUI-1 | 132 of 184 | 71.7% |
| Base DiffusionGemma | 24 of 184 | 13.0% |
The comparison suggests that fine-tuning for the structured UI task substantially improved performance on this validator relative to the base model. It does not show that OUI-1 will generate usable screens for every design brief, component library or production data source.
The reported measurements used vLLM 0.24, FP8 numerical format, the checkpoint’s sampler at 48 denoising steps and one request at a time on an A100 80GB GPU. The model card reports latency of roughly one second for a light screen and three to six seconds for a dense screen under those conditions, including the prompt.
Thesys also reports a separate tool-calling test. OUI-1 selected the appropriate tool for 9 of 9 weather and stock-price requests and did not call a tool for 3 unrelated requests. The model card documents limitations in the vLLM tool-calling implementation: required or named tool choices are ignored, and an empty tool_calls field can appear alongside a tool_calls finish reason.
Deployment requirements and limitations
The checkpoint is intended for self-hosted use, but its resource requirements are significant. The model card reports approximately 25.8 GiB for FP8 weights under vLLM and about 52 GiB of peak GPU memory for BF16 inference with Transformers.
FP8 and BF16 are lower-precision numerical formats used to reduce memory use or accelerate neural-network inference, with hardware-dependent trade-offs. On the A100 configuration described by Thesys, FP8 reduces memory use but does not provide a compute-speed improvement because that GPU lacks native FP8 support. The reported latency should therefore not be generalised to consumer GPUs or other server hardware.
OUI-1 is not presented as safe to render without checks. Generated programs need to be parsed, their component names and properties need to be validated, and the resulting interface needs to be rendered through a compatible library. The source does not establish that this process guarantees secure, accessible or factually correct interfaces.
The model card also says that identical requests can produce differently worded screens because the sampler has no per-request seed plumbing. That makes exact reproducibility more difficult.
The model is distributed under the Gemma Terms of Use, and the model card says the base model’s use restrictions apply to the derivative model. The supplied page does not list a hosted inference provider, commercial price, service-level commitment or India-specific availability. It is available as a Hugging Face checkpoint for self-hosted use, subject to those terms.
What remains to be tested
The main open question is how well the benchmark result transfers to real applications. The supplied evidence does not establish performance on larger or more diverse interface tasks, arbitrary third-party component libraries, accessibility requirements, production data or long-term interface maintenance.
Independent reproduction of the Generative UI Benchmark would help determine whether the reported gap over the base model persists under external evaluation. More important for deployment would be testing whether generated screens remain valid when inputs are incomplete, stale or adversarial, and whether tool-grounded interfaces consistently display correct data.
Hardware testing outside the reported A100 setup is also needed. OUI-1’s total parameter count and memory requirements may limit local use, particularly where developers do not have access to large GPUs.