OpenUI by W&B: Generate and Iterate UI Components from Plain-Text Descriptions

What OpenUI Does and the Problem It Addresses

OpenUI addresses the friction in prototyping UI components. Instead of writing HTML, CSS, and JavaScript from scratch to see whether a layout or interaction pattern works, a developer describes what they want in a sentence or a short prompt, and OpenUI generates HTML rendered in a live preview. The developer can then ask for adjustments, see the changes immediately, and convert the result to the framework of their choice.

The README describes its origin: it is a tool W&B built internally to test and prototype tooling for LLM-based applications. The project is openly described as similar to v0 by Vercel but open-source and less polished. That framing is useful because it sets expectations accurately: the output is an accelerant for initial mockups, not a production-quality component generator.

Converting the HTML output to React, Svelte, or Web Components is built into the tool. A developer can start with a plain HTML result and request conversion to a specific framework without leaving the application. The README does not document whether the conversion step preserves all interactivity or whether complex components lose fidelity in translation.

LLM Provider Support and How LiteLLM Extends the Options

OpenUI supports multiple LLM providers through environment variables. The README lists the following:

- OpenAI: set `OPENAI_API_KEY` - Groq: set `GROQ_API_KEY` - Gemini: set `GEMINI_API_KEY` - Anthropic (Claude): set `ANTHROPIC_API_KEY` - Cohere: set `COHERE_API_KEY` - Mistral: set `MISTRAL_API_KEY` - OpenAI-compatible endpoint: set `OPENAI_COMPATIBLE_ENDPOINT` and `OPENAI_COMPATIBLE_API_KEY`

For providers not in this list, LiteLLM acts as a compatibility layer. LiteLLM connects to a wide range of LLM services, and OpenUI auto-generates a LiteLLM configuration based on the environment variables it detects. A developer can override this with a custom `litellm-config.yaml` file placed in the current directory or at `/app/litellm-config.yaml` inside a Docker container. The `OPENUI_LITELLM_CONFIG` environment variable specifies an arbitrary path.

Ollama is supported for fully local inference. If Ollama is running at a non-default address, the `OLLAMA_HOST` environment variable overrides the default `http://127.0.0.1:11434`. Models available in Ollama appear in the application's model selector under LiteLLM once the instance is reachable. The README notes that when running in Docker, the Ollama instance on the host must be addressed as `http://host.docker.internal:11434` rather than localhost.

Running OpenUI with Docker

Docker is the recommended installation path according to the README. The image is published at `ghcr.io/wandb/openui` and runs the server on port 7878. A typical startup command forwards API keys from the shell environment:

export ANTHROPIC_API_KEY=xxx
export OPENAI_API_KEY=xxx
docker run --rm --name openui -p 7878:7878 -e OPENAI_API_KEY -e ANTHROPIC_API_KEY -e OLLAMA_HOST=http://host.docker.internal:11434 ghcr.io/wandb/openui

After the container starts, the application is accessible at `http://localhost:7878`. API keys are forwarded from the environment by name rather than hardcoded into the command.

For a setup that includes a local Ollama instance managed by Docker Compose, the repository ships a docker-compose.yaml that starts both an Ollama container and the OpenUI container. After starting the stack, a model needs to be pulled into the Ollama container:

docker-compose up -d
docker exec -it openui-ollama-1 ollama pull llava

The README warns that running Ollama in Docker is likely to be slow compared to running it natively, particularly on Mac hardware where native Ollama can use the M1 or M2 GPU. For local model use on Mac, the README recommends running Ollama natively and setting `OLLAMA_HOST` to point Docker to it.

A custom LiteLLM configuration can be injected into the container with a volume mount:

docker run -n openui -p 7878:7878 -v $(pwd)/litellm-config.yaml:/app/litellm-config.yaml ghcr.io/wandb/openui

Running OpenUI from Source with uv

The source installation uses uv, a fast Python package manager. The README assumes git and uv are already installed:

git clone https://github.com/wandb/openui
cd openui/backend
uv sync --frozen --extra litellm
source .venv/bin/activate
export OPENAI_API_KEY=xxx
python -m openui

The `uv sync --frozen --extra litellm` step installs all backend dependencies including the optional LiteLLM extras and locks the versions from the lockfile. The `--extra litellm` flag is required to enable the LiteLLM integration, which covers providers beyond the natively supported OpenAI, Anthropic, and Groq APIs.

To start the backend in development mode with auto-reload, the README uses `python -m openui --dev`. The frontend is then started separately:

npm run dev

The frontend development server runs on port 5173. Changes to both the frontend and backend code reload automatically in this configuration. The README recommends this setup for contributors and developers who want to modify the tool.

For using LiteLLM with a specific custom endpoint from source, the alternative installation path is:

pip install .[litellm]
export ANTHROPIC_API_KEY=xxx
export OPENAI_COMPATIBLE_ENDPOINT=http://localhost:8080/v1
python -m openui --litellm

HTML to Framework Conversion and the Iteration Workflow

The core workflow is iterative. A developer types a description, OpenUI generates HTML, and the preview renders it live. From there, they can type follow-up instructions to adjust the result, such as changing a color, adding a button, or modifying layout. The HTML updates in the preview without a page reload.

When the HTML reaches a satisfactory state, OpenUI can convert it to React, Svelte, or Web Components. This conversion step is requested through the same text interface. The README describes it as a built-in capability, though it does not document the conversion's fidelity for complex components or the extent to which JavaScript interactivity survives the conversion.

The tool can also accept images as additional input. Codespace installs Ollama and the llava model by default, and llava is one of the Ollama models that supports image inputs. This allows a developer to paste a screenshot of an existing UI and ask OpenUI to recreate or modify it.

The resulting HTML or framework code is intended as a starting point. The README does not present it as production-ready; the description of the project as less polished than v0 implies that manual review and editing are expected as part of the workflow.

Output Quality, Model Dependency, and the LLM Ceiling

OpenUI's output quality is determined by the LLM it calls. The same prompt sent to GPT-4o versus a small Ollama model will produce substantially different HTML. This creates a practical constraint: the tool is only as capable as the model behind it, and smaller or weaker models will generate simpler, less accurate, or structurally broken components.

The README does not document which LLMs produce the best results or provide guidance on prompt patterns that improve reliability. A developer evaluating OpenUI for a specific use case should test their intended LLM before committing to the tool.

The project uses image inputs for context, but the README warns that Ollama in Docker is likely to be very slow for image-capable models like llava due to CPU-only inference. On a Mac, native Ollama is the recommended path for image-enabled models.

Since the output is HTML rendered by the browser, the quality ceiling for interactive components is also limited by how well the underlying LLM understands JavaScript and CSS. For components that require complex state management, accessibility attributes, or framework-specific idioms, the conversion from HTML to React or Svelte may require significant manual correction.

v0.dev as the Named Alternative and When It Fits Better

The README explicitly positions OpenUI against v0 by Vercel, calling it similar but less polished. v0 is a hosted service that uses Vercel's infrastructure and LLM backend; it generates React components with Tailwind CSS and integrates directly into Vercel deployment workflows.

The practical difference is control. OpenUI is self-hostable, works with any LiteLLM-supported model including local Ollama instances, and does not require a Vercel account. v0 offers higher output polish, tighter framework integration, and a hosted experience that requires no local infrastructure.

For teams already on Vercel's platform and primarily working in React with Tailwind, v0 avoids the setup cost of running OpenUI. For teams who want to use a specific LLM provider, who are working with non-React frameworks, or who cannot send their prompts to a third-party cloud service, OpenUI is the option that allows local or self-hosted inference.

The dev container configuration in the repository, along with Codespace and Gitpod support, lowers the barrier to getting OpenUI running without managing a local Python and Node environment. The Codespace path preconfigures Ollama with llava and starts the server automatically, though it requires at least 16 GB of RAM per the README's note on the Ollama configuration.

Editorial conclusion

OpenUI suits developers who want to iterate on UI component ideas quickly using an LLM of their choice and who prefer a self-hostable tool over a paid SaaS. It is not a replacement for a production component library and the README acknowledges it is less polished than v0. Anyone evaluating it should run it against their specific LLM provider first, since output quality depends heavily on the underlying model. The last push was on September 10, 2026.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. Project website
4. README
5. wandb/openui on GitHub