OUI-1: The Diffusion Model That Builds UI Screens in One Second
OUI-1 is a 4B diffusion model that generates full UI screens in about a second. Here's what it is and how to run it locally with vLLM.
What is OUI-1?
OUI-1 is a diffusion model built specifically to generate user interface screens, and it works nothing like the text-generation models most developers are used to. Instead of writing output token by token, left to right, it starts from pure noise and refines an entire UI screen all at once, arriving at a finished result in roughly a second. It’s a fine-tune of Google’s diffusion Gemma line, with 4 billion active parameters, and it outputs a compact format called Open UI Lang rather than sprawling JSON or raw HTML/CSS.
That architectural choice is the whole story here. Autoregressive LLMs generate UI code the same way they generate an essay: one token waiting on the previous one. OUI-1 instead denoises the full screen simultaneously across a fixed number of steps (48 in the demoed run), which is why it can render a complete interface, layout, components, and all, before a typical chat model would finish streaming a comparable amount of text.
TL;DR
- OUI-1 is a 4B-parameter diffusion model fine-tuned from Google’s diffusion Gemma, purpose-built to generate UI screens instead of general text.
- It writes output in Open UI Lang, a compact UI description format, rather than verbose JSON or hand-written markup.
- Generation happens through iterative denoising (48 steps in testing) instead of token-by-token decoding, producing a full screen in about a second.
- Running it locally required roughly 77GB of VRAM in the demoed setup (including KV cache), with model weights alone taking about 28 to 29GB, served through vLLM.
- The Open UI CLI scaffolds a ready-to-run Next.js app that talks to a self-hosted OUI-1 endpoint, complete with chat interface, API routes, and an inspector panel.
- Simple, well-scoped screens (dashboards with one chart, contact forms, settings panels, product pages) render cleanly, while denser multi-component briefs (charts plus tables plus multiple data views) are more likely to throw parser or type-mismatch errors.
- The model can also drive functional UI elements tied to external tool calls, not just static mockups, as shown with a weather-lookup example.
Remy doesn't write the code. It manages the agents who do.
Remy runs the project. The specialists do the work. You work with the PM, not the implementers.
How does OUI-1 actually generate a UI?
The core mechanism is diffusion, the same family of technique behind image generators like Stable Diffusion, but applied to structured UI description text instead of pixels. Rather than predicting the next token conditioned on everything before it, the model starts with a noisy placeholder representation of the entire output and iteratively refines it over multiple passes until it converges on a coherent result. All tokens are being resolved together at each step rather than one at a time.
The practical effect is speed. In testing, a full screen (layout, components, styling) came together in about a second, regardless of how much of the screen there was to generate. That’s a fundamentally different scaling curve than autoregressive generation, where output length directly drives latency because every additional token requires another forward pass.
The output format matters too. OUI-1 doesn’t emit HTML, CSS, or a JSON tree describing a component hierarchy. It uses Open UI Lang, a purpose-built, compact syntax for describing screens. That compactness likely helps the diffusion process converge faster and more reliably than it would on bloated, deeply nested JSON.
What do you need to run OUI-1 locally?
The demoed setup used a single Ubuntu machine with one GPU carrying 80GB of VRAM, served through vLLM. Once loaded, the model consumed about 77GB of VRAM including KV cache, with the model weights themselves accounting for roughly 28 to 29GB. That gap between weights and total consumption is worth noting if you’re planning hardware: KV cache and runtime overhead can eat a large chunk of your available memory beyond the base model size.
The basic workflow looks like this:
- Install vLLM (standard installation, no OUI-specific fork required).
- Serve the OUI-1 model with vLLM using a standard serve command, pointing it at an open port (port 8000 in the demoed setup).
- Install Node.js if it isn’t already on the machine.
- Use the Open UI CLI to scaffold a complete Next.js project pre-configured to call a self-hosted model endpoint. This single command sets up the chat interface, API routes, and general plumbing needed to talk to your local vLLM server instead of a hosted API.
- Point the generated project’s configuration at your local vLLM endpoint.
- Run the standard install and start commands, then open the app on localhost (port 3000 in the demo).
The first load takes a moment, but after that, prompts return rendered screens in close to real time. Because the whole project is scaffolded locally with source code included, you end up with an editable Next.js app rather than a black-box demo.
What can OUI-1 actually build well?
In hands-on testing, OUI-1 handled a range of practical, everyday UI requests convincingly:
- An e-commerce analytics dashboard with total revenue, a line chart, and a top-selling-products list.
- A contact form with name, email, and a dropdown field.
- An account settings screen with profile fields, notification toggles, and a dark mode switch.
- A product page for a physical good, complete with an add-to-cart button.
- A simple single-chart dashboard.
- ✕a coding agent
- ✕no-code
- ✕vibe coding
- ✕a faster Cursor
The one that tells the coding agents what to build.
Beyond static screens, the model also demonstrated functional tool-calling behavior. Asked whether it would rain in a specific location over the weekend, it returned a working UI element tied to that query rather than just a mock layout, suggesting OUI-1 can be wired into pipelines where the generated interface needs to reflect live or dynamic data, not just placeholder content.
Where does OUI-1 break down?
Pushed harder, the model’s limits show up quickly. When asked to generate something denser, like a dashboard combining a bar chart and a table in the same screen, it produced output but also threw multiple parser errors: a missing required field, a type mismatch between components, and general trouble reconciling two different data-display components in one shot.
The built-in inspector panel (visible alongside the generated UI) surfaces these errors directly, which makes debugging straightforward but also makes the model’s current ceiling obvious. The pattern that emerged: simple, well-defined, single-purpose screens render reliably, while dense, multi-component briefs that ask for several distinct data visualizations at once are more likely to produce broken or partially invalid output. That’s consistent with an early-stage model still maturing at compositional complexity, even if the core one-shot generation trick already works.
Is OUI-1 worth running locally right now?
For anyone prototyping UI ideas quickly, or exploring diffusion-based approaches to structured generation beyond images, OUI-1 is a legitimate technical curiosity with real practical upside. Generating a usable front-end scaffold in about a second, versus waiting for a token-streamed response from a conventional LLM, is a meaningful workflow difference if you’re iterating on many screen ideas in a row.
The catch is hardware and scope. A 4B-parameter model shouldn’t sound demanding, but the demoed run needed 80GB of VRAM headroom once KV cache was factored in, which puts it out of reach of most consumer GPUs without quantization or a smaller serving configuration. And the model’s sweet spot right now is clearly single-purpose screens (forms, settings panels, simple dashboards, product pages) rather than dense, multi-widget interfaces. If your use case is generating individual, well-scoped UI components fast, it’s worth testing. If you need a one-shot generator for complex dashboards with multiple chart types and tables, expect to hit parser errors and plan for manual cleanup.
Frequently Asked Questions
What is Open UI Lang?
It’s the compact output format OUI-1 uses to describe generated UI screens, designed to be far less verbose than raw JSON or hand-written HTML/CSS, which likely helps the diffusion process converge to a valid screen faster.
How is OUI-1 different from asking ChatGPT or Claude to write UI code?
Standard LLMs generate code token by token, autoregressively, so output length directly affects response time. OUI-1 is a diffusion model that refines an entire screen simultaneously over a fixed number of denoising steps, producing a complete result in about a second regardless of screen complexity.
How much VRAM does OUI-1 need to run locally?
In a demoed setup using vLLM, the model consumed about 77GB of VRAM total (including KV cache), with the model weights themselves taking roughly 28 to 29GB on an 80GB GPU.
Can OUI-1 build functional UI, or just static mockups?
It demonstrated at least basic functional behavior, including a working UI element tied to an external tool call (a weather query), suggesting it can support dynamic data rather than only static layouts.
Other agents ship a demo. Remy ships an app.
Real backend. Real database. Real auth. Real plumbing. Remy has it all.
What kinds of UI requests does OUI-1 struggle with?
Dense, multi-component requests, such as a dashboard combining a bar chart and a table in one screen, were more likely to produce parser errors, missing fields, or type mismatches. Simpler, single-purpose screens performed more reliably.