{"id":559443,"date":"2026-10-05T05:53:41","date_gmt":"2026-10-05T05:53:41","guid":{"rendered":"https:\/\/webkul.com\/blog\/?p=559443"},"modified":"2026-10-05T05:53:49","modified_gmt":"2026-10-05T05:53:49","slug":"oui-1-the-generative-ui-model","status":"publish","type":"post","link":"https:\/\/webkul.com\/blog\/oui-1-the-generative-ui-model\/","title":{"rendered":"OUI-1: The Generative UI Model That Taught Itself"},"content":{"rendered":"\n

Most AI <\/a>models generate text. In contrast, OUI-1 <\/strong>generative UI model from Thesys, generates something different: entire user interfaces. Give it a plain-language brief, and it writes back a working screen \u2014 a dashboard, a form, a card layout \u2014 as structured code, ready to render in React<\/a>, Vue, or Svelte. Thesys calls it the first open-weight model built specifically for generative UI, and its training story is as interesting as the model itself.<\/p>\n\n\n\n

\"OUI-1<\/figure>\n\n\n\n

Image source: OpenUI \u2014 Introducing OUI-1<\/a><\/em><\/p>\n\n\n\n

What Is OUI-1 generative UI?<\/h2>\n\n\n\n

OUI-1 is a fine-tune of Google’s DiffusionGemma 26B-A4B, a 26-billion-parameter diffusion language model that only activates about 4 billion parameters per token. Specifically, Thesys built it to write OpenUI Lang<\/strong>, the declarative language behind their OpenUI framework. Released on September 8, 2026, under Apache 2.0, it runs on a single consumer GPU \u2014 Thesys, for instance, specifically points to an RTX 5090 at FP8 precision.<\/p>\n\n\n\n

Instead of one general-purpose model trying to do everything, OUI-1 does one job well. In fact, as the Hugging Face model card puts it plainly: “Not a general chat model.” Rather, it exists purely to turn a brief and a component library into a valid, renderable screen.<\/p>\n\n\n\n

Why Thesys Built OUI-1 generative UI<\/h2>\n\n\n\n

Agent-driven interfaces \u2014 screens an AI assembles on the fly, rather than ones a developer hand-codes in advance \u2014 depend on three things happening at once. First, generation has to finish in under a second. Additionally, the result has to be reliable enough to actually ship as software. And finally, the model doing the generating has to be small enough to run locally, not in a data center.<\/p>\n\n\n\n

Thesys had already tested this idea with AppLess<\/strong>, a “no-app phone” demo where every screen gets generated on demand instead of loaded from an installed app. Early versions ran on Gemma 4 via Cerebras hardware \u2014 fast, but tied to specialized cloud infrastructure. Consequently, moving that experience onto an actual device meant finding a model that kept the speed without the specialized hardware.<\/p>\n\n\n\n

How OUI-1 generative UI Generates a Screen<\/h2>\n\n\n\n

DiffusionGemma gave Thesys the speed profile they needed. Specifically, rather than writing tokens one at a time like a typical chat model, it denoises a 256-token block all at once, using bidirectional attention to commit each token as soon as it becomes confident. As a result, Google reports over 1,000 tokens per second on a single H100, and over 700 on a consumer RTX 5090.<\/p>\n\n\n\n

However, speed alone doesn’t make working software. The base DiffusionGemma model, for example, scored only 13.0% on Thesys’s own Generative UI Benchmark \u2014 fast, but unreliable. OpenUI Lang’s own parser made the failure modes easy to name: schema errors (an invented component, a wrong enum value) and wiring errors (a section defined but never attached to the screen’s root). Therefore, closing that gap, without losing the speed, became the actual engineering problem.<\/p>\n\n\n\n

The Training Story: When Fine-Tuning Made Things Worse<\/h2>\n\n\n\n

Here’s where it gets genuinely interesting. Thesys’s first attempt \u2014 a straightforward supervised fine-tune on roughly 700 hand-written OpenUI Lang examples \u2014 backfired in two ways at once.<\/p>\n\n\n\n

First, the model’s two error types moved like a see-saw. One training run would reduce wiring errors while increasing schema errors; then, the next run would reverse the trade rather than fixing both together. Second, and less expected, the model got slower<\/em>. Specifically, generation time on light briefs rose from 1.6 seconds to 4.3 seconds, because the fine-tuned model wrote longer, more specific outputs and needed roughly twice as many denoising steps to commit each token.<\/p>\n\n\n\n

The breakthrough, however, came from a simple realization: OpenUI Lang has a verifiable reward<\/strong>. The parser can tell, mechanically, whether a generated screen is structurally valid, and it can point to the exact defect when it isn’t. As a result, that turned the model into its own teacher. Thesys calls the approach rejection-sampled self-training with repair<\/strong>:<\/p>\n\n\n\n

    \n
  1. The model generates a batch of OpenUI Lang programs.<\/li>\n\n\n\n
  2. The parser keeps the ones that pass cleanly.<\/li>\n\n\n\n
  3. Near-misses go through a targeted repair pass \u2014 fixing only the reported defect, never rewriting freely.<\/li>\n\n\n\n
  4. A judge checks whether each surviving program actually matches its original brief.<\/li>\n\n\n\n
  5. The survivors become the training set for the next round.<\/li>\n<\/ol>\n\n\n\n

    This loop, repeated across 500-step training runs on a single A100, is what actually closed the gap. As a result, speed came back \u2014 down to 1.9 seconds per output \u2014 and, crucially, the see-saw stopped. Consequently, schema errors and wiring errors dropped together for the first time, instead of trading off against each other.<\/p>\n\n\n\n

    Results<\/h2>\n\n\n\n

    After extending the same recipe across 27 different component libraries, the final model \u2014 OUI-1 \u2014 reached 71.7% on the Generative UI Benchmark, up from DiffusionGemma’s 13.0%. In other words, that’s a 5.5x improvement.<\/p>\n\n\n\n

    Model<\/th>Active Params<\/th>Generative UI Score<\/th><\/tr><\/thead>
    Qwen3.8 27B (dense)<\/td>27B<\/td>78.8%<\/td><\/tr>
    OUI-1<\/strong><\/td>4B<\/strong><\/td>71.7%<\/strong><\/td><\/tr>
    Qwen3.6 27B (dense)<\/td>27B<\/td>68.5%<\/td><\/tr>
    Qwen3.6 35B-A3B<\/td>3B<\/td>61.4%<\/td><\/tr>
    Gemma 4 31B (dense)<\/td>31B<\/td>46.7%<\/td><\/tr>
    Phi-4 14B (dense)<\/td>14B<\/td>44.0%<\/td><\/tr>
    Gemma 4 26B-A4B<\/td>4B<\/td>29.9%<\/td><\/tr>
    DiffusionGemma (base)<\/td>4B<\/td>13.0%<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

    Notably, no other model at 4B active parameters or below scored anywhere close. The only model that beat OUI-1 outright, Qwen3.8 27B, is a dense model using 27 billion parameters on every single token \u2014 nearly seven times OUI-1’s active parameter count.<\/p>\n\n\n\n

    Furthermore, the gain held up outside the benchmark, too. On AppLess’s own component library \u2014 a different library from training, with 60 prompts the model had never seen \u2014 OUI-1 produced 55 valid outputs against DiffusionGemma’s 23.<\/p>\n\n\n\n

    From Research to Real Product: AppLess<\/h2>\n\n\n\n

    OUI-1 isn’t just a benchmark exercise. As of mid-September 2026, for example, Thesys moved AppLess itself onto OUI-1, replacing the Cerebras-hosted Gemma 4 setup entirely. The pitch is a phone with no installed apps: every screen \u2014 checking weather, tracking a package, viewing a bank balance \u2014 gets generated live from a natural-language request instead of opening a pre-built app.<\/p>\n\n\n\n

    On top of that, Thesys open-sourced both the AppLess client and the OpenUI framework under MIT, so developers can fork the demo and build their own agent-driven interface experiments on top of it.<\/p>\n\n\n\n

    Running OUI-1 generative UI Yourself<\/h2>\n\n\n\n

    For developers who want to self-host, OUI-1 is designed to fit realistic hardware budgets:<\/p>\n\n\n\n