OpenUI's component library is the model's whole vocabulary, and only React gets built-ins

The component library is the model's entire vocabulary

The whole design is one loop, and the repository draws it as a chain:

flowchart LR
    A["Component Library"] --> B["System Prompt"]
    B --> C["LLM"]
    C --> D["OpenUI Lang Stream"]
    D --> E["Renderer"]
    E --> F["Live UI"]

The numbered version underneath spells out the five steps: define or reuse a component library, generate a system prompt from that library, send that prompt to your model, stream OpenUI Lang output back to the client, and render it progressively with Renderer.

The security and behaviour boundary sits on the first link. The capability list says prompts are generated directly from the components you allow, which means the library is the model's vocabulary rather than a set of suggestions. Add a component and the model may start emitting it, so every library change invalidates the generated system prompt. The interactive version of the same loop is at https://www.openui.com/playground, where you can generate UI live against the default component library.

The only number in the README is a token saving with no baseline

There is exactly one quantitative claim in the project description: OpenUI Lang uses up to 67% fewer tokens than JSON. The hedge is already in the wording, and the sentence itself gives no baseline behind it. No model is named, no prompt shape is given, no message is reproduced, and nothing says whether the comparison holds for a short widget or a long streaming response.

There is a benchmarks/ directory at the repository root, so the project has somewhere to put that work, but the README's introduction does not point at a result file inside it. Treat the figure as a project claim to verify against your own workload rather than as an operating assumption.

The practical consequence is that token count does not belong in your OpenUI business case yet. If your model bill depends on a stream length estimate, measure it against the JSON encoding you have today before you commit to the migration, because a result from one comparison does not establish the saving for every production prompt.

The quick start scaffolds an app with the CLI

The documented first command is:

npx @openuidev/cli@latest create --name genui-chat-app

The README calls this the fastest way to start: the scaffolded app gives an end-to-end starting point with streaming, built-in UI and OpenUI Lang support, so you start from a ready-to-run example instead of wiring everything manually.

The npx invocation pulls @openuidev/cli at latest rather than a pinned version, which means the scaffolding you get changes without any change in your own repository.

Only the React runtime ships built-in component libraries

The capability list advertises built-in component libraries for charts, forms, tables and layouts, ready to use or extend. The package table then narrows that claim sharply. @openuidev/react-ui is described as prebuilt chat layouts, standalone UI primitives, and two built-in component libraries, and the introduction says React additionally ships built-in component libraries and ready-to-use chat interfaces.

The other three runtimes get bindings only. @openuidev/vue-lang is Vue 3 bindings for defining model-renderable components and rendering streamed output, @openuidev/svelte-lang is the Svelte 5 equivalent, and @openuidev/angular-lang is Angular bindings for defining component libraries and rendering. None of the three is described as carrying charts, forms or tables.

So a capability that reads as framework wide is React wide in practice. On Vue, Svelte or Angular you build the component library the model will speak with before anything renders, and the gap between a working React demo and a Vue port is the whole design system, not a binding import.

The no-build bundle brings React along with it

For teams without a build step, @openuidev/browser-bundle is described as a prebuilt browser bundle that ships the renderer, the UI library, React and styles as script plus stylesheet assets, for CDN, iframe and no-build embeds.

The cost is in that sentence. A no-build embed still loads React, so a page whose host application is already built on something else ends up carrying a second framework runtime, and you own the version that bundle was cut against. The same package is also the documented path for iframe embeds, which is the one case where shipping a second runtime is the point rather than an accident.

Four React packages cover overlapping layers of the same job

Picking a React package is the main architectural decision, and the descriptions overlap enough to blur. @openuidev/react-lang handles rendering runtimes: define component libraries, generate prompts, render streamed output. @openuidev/react-headless is for bring your own chat UI and covers headless chat state, streaming adapters and message format converters. @openuidev/react-ui is the prebuilt path with chat layouts, primitives and two component libraries. @openuidev/assistant-ui exists for wiring streamed OpenUI Lang into assistant-ui apps with tool UI renderers.

The dividing line is depth. The headless package is the one that holds message format converters, so protocol differences belong there rather than in the renderer. For agent side work, @openuidev/langchain is described as an agent transformer and server helpers that stream OpenUI through AG-UI.

The genuine trade-off is who owns the chat shell. Prebuilt layouts get you to a demo fastest and are harder to reshape; headless leaves the shell to you and makes you write the components the model is allowed to call.

The scaffold runs the least mature version line in the project

Three version numbers coexist and only one of them is what you install. The workspace root package.json carries version 1.0.1 with private true, so that number is never published. The latest releases are @openuidev/react-lang 1.0.2, @openuidev/lang-core 1.0.2 and @openuidev/cli 0.6.1, all released on 2026-10-27, and main received a push on 2026-11-02.

The asymmetry is the part to plan around. The CLI is the entry point for the quick start and for every new scaffold, so it is the line you depend on most often and it sits furthest from 1.0, while the version that looks finished, 1.0.1, is an internal workspace version nobody installs.

There is also an explicit warning in the README that OpenUI has no official cryptocurrency, token or coin, and that any asset using the name is unaffiliated. If a dependency review or a search result offers you an OpenUI token, that warning is the project's own statement about it.

Publishing is gated by a peer window script inside a pnpm workspace

The root package.json pins the toolchain: packageManager [email protected], and engines requiring node ^20.19.0 || >=22.12.0. Anything outside that node range is unsupported before a single line of OpenUI is involved.

The release path is a short script list, and one script runs twice:

    "test": "pnpm -r run test",
    "build:packages": "pnpm --filter \"./packages/**\" --workspace-concurrency=1 run build",
    "version:ci": "changeset version && node scripts/verify-peer-windows.mjs && pnpm install --lockfile-only",
    "release:publish": "node scripts/verify-peer-windows.mjs && pnpm run build:packages && pnpm changeset publish"

verify-peer-windows.mjs gates both versioning and publishing, so a peer range that would not resolve fails the release rather than your application. Package shape is checked by @arethetypeswrong/cli and publint in devDependencies. Examples and templates are managed through scripts/manage-starters.mjs with examples:install, examples:update, examples:verify and templates:update, which is why the examples/ tree holds agent-frameworks/, app-frameworks/, cookbooks/, design-systems/, harnesses/ and miscellaneous/ as starters that get verified rather than hand-edited.

Editorial conclusion

OpenUI fits a TypeScript team building a chat or copilot surface where the model should emit real widgets instead of prose, and a team willing to own the component allowlist and the wiring between an agent framework and a renderer. Read it as React first: the prebuilt chat layouts and two built-in component libraries exist only in @openuidev/react-ui, so on Vue, Svelte or Angular you supply the component library yourself. Before committing, confirm the CLI line you will live with, since the scaffold still runs @openuidev/cli at 0.6.1, and measure the 67 percent token-saving claim against your own workload rather than treating it as a budget.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. thesysdev/openui on GitHub