A 274.9 MB monorepo turns model text into registered components
Our measured checkout was 274.9 MB before dependencies, and its central idea is smaller than the repository. You define a component library with names, typed properties, and render functions. OpenUI turns that library into model instructions, parses OpenUI Lang as the response arrives, and renders only registered components. A model can request a chart, form, or table without returning executable React source. The application still decides which components and actions exist.
The 2,836-file checkout divides that loop into focused packages. lang-core handles parsing and prompt generation without a UI framework. React packages cover rendering, headless chat state, and prebuilt interfaces. Other packages handle email, LangChain or LangGraph, browser bundles, Vue, Svelte, scaffolding, and observability. The React renderer can receive ordinary async functions or an MCP-client-shaped tool provider for queries and mutations, so generated UI can show live application data instead of static model text.
What happened when we ran it
Our sandbox installed 1,669 pnpm packages in 114 seconds and used 1,662 MB on disk. We tested commit 8bd2e27 in an unprivileged Debian container with 3 CPUs, 8 GB of RAM, and no secrets. The installation succeeded without an error in the supplied log. That result is reproducible enough for evaluation, but the dependency footprint is large compared with a component library that a team might otherwise expect to add to one frontend.
The harness found no default build script or target, so it skipped the build step rather than recording a success or failure. Vitest then completed in 36 seconds with 11 passed and 0 failed of 11. The monorepo had 8 CI workflow files, no Dockerfile, no tests directory, and workspace configuration. Those facts do not describe every package's private check set; they state only what our standard root run could see and execute.
The 1,662 MB install leaves backend ownership with the application
Our 1,662 MB installed workspace is much bigger than the one-command scaffold suggests. The quick start asks for an OpenAI key, but self-hosting needs more work. Your server route must call the chosen model, preserve its streaming wire format, pass abort signals upstream, and close the stream. Persistent chat requires five storage operations for listing, creating, reading, updating, and deleting threads. OpenUI supplies client adapters and example routes, while your application owns the database and authorization.
Node 20.19 or Node 22.12 and newer are supported by the current root manifest, with pnpm 10.33.0 pinned for workspace development. The 1,669-package install covers many packages and examples, while adopters can install a narrower package set. Provider keys belong on the server. Optional Gateway, Autofix, and cloud observability add Thesys credentials and service calls. A team seeking a completely local stack should separate the open renderer from those hosted reliability products when estimating operations and privacy.
The 7-scenario token table supports compact syntax, not perfect output
OpenUI's repository benchmark uses 7 saved UI scenarios generated once with GPT-5.2, then projects the same parsed tree into other formats. Its table counts 4,800 tokens for OpenUI Lang, 10,180 for Vercel JSON-Render, and 9,948 for Thesys C1 JSON with the GPT-5 tokenizer. That is a useful format-size comparison under a documented fixture set. It is not our runtime benchmark, and it does not establish lower latency for every model, schema, or prompt.
The project's separate reliability page is candid about generation failure. It reports 2 blank screens across 1,104 runs, a 92.9% task completion rate for OpenUI, and a best model pairing at 99.5% rather than 100%. The proposed defenses are tighter component schemas, better prompts, repeated evaluation, validation, and correction. Some repair options are hosted services. Teams should keep an ordinary error or text fallback in the product instead of assuming a structured stream always finishes.
The 11 passing tests do not close streaming parser bugs
Our 11-test root run passed, but issue 1127 shows a semantic mismatch in completed output. When one statement ID is defined twice, the batch parser uses the last definition and the streaming parser keeps the first. The reporter reproduced the difference with whole, line-by-line, character-by-character, and split delivery. A final interface should not depend on whether network chunks arrived in one piece, so applications using incremental editing need a regression case for their own emitted language.
Issue 767 covers another stream-only failure: a truncated binding default can enter the store during recovery and remain after the complete value arrives. A reload fixes it because the store starts fresh. Issue 1128 says React UI 0.13 removed the practical path for a custom assistant component to render live tool activity during the tool-only phase. These are narrow reports, yet each touches a reason to adopt OpenUI: progressive rendering, reactive state, or message customization.
A September 11 push coexists with 157 open issues and pull requests
GitHub recorded 8,926 stars and a last push on September 11, 2026. Search results showed 58 open issues and 99 open pull requests, matching the repository's 157 combined open-item count. Issue updates on September 10 show live maintainer and contributor activity. The queue also asks adopters to pin package versions and search the exact parser, renderer, or adapter they use rather than treating repository-wide activity as proof of stability.
GitHub's latest-release endpoint returned no release, even though the root manifest says version 1.0.1 and individual packages remain on 0.x versions. The 8 visible CI workflows include package publishing and CLI checks, so absence of a GitHub release is not evidence that work stopped. It does mean GitHub's release page cannot tell a buyer which package set is the stable platform. Start with the smallest package surface that serves one tested generative UI flow.