Thesys releases OpenUI 1.0 so agents can stream your own components instead of text

What Thesys released as OpenUI 1.0

On 15 October 2026, Thesys's Rabi Shanker Guha wrote on X that the team was “releasing OpenUI 1.0 bringing it to every other agent.” His framing was explicit: ChatGPT had just shown what model-generated interfaces look like, and OpenUI wants the same pattern to be available to any agent, on any model. The post repeats two project numbers, 10K+ GitHub stars and 6M+ downloads since the code was open-sourced roughly six months ago. The star count is checkable; on 16 October the repository listed about 11,200 stars and 750 forks. The download figure is Thesys's own claim.

The dated code objects are on GitHub. @openuidev/react-lang 1.0.0, released on 12 October, carries the changelog line “OpenUI Lang 1.0” and lists the breaking changes. Patch releases including @openuidev/lang-core 1.0.1 followed early on 15 October with README updates that point to the new documentation, and the CLI moved to 0.6.0 later the same day. So the public announcement came three days after the core packages shipped, which is common for open-source projects that want docs and starters in place before the launch post.

OpenUI is maintained under the thesysdev organization on GitHub and documented at openui.com. Thesys also sells hosted pieces around it, including a gateway and reliability monitoring, but the language, parsers, renderers and component libraries in the repository are under the MIT license.

How OpenUI turns model output into an interface

The core idea is that your component library, not the model, defines what can appear on screen. You describe components such as cards, tables, charts, forms and buttons with typed schemas. OpenUI generates a system prompt from that library, the model answers in OpenUI Lang, and a streaming renderer turns each line into live UI as tokens arrive. The README draws the pipeline as component library, system prompt, LLM, OpenUI Lang stream, renderer, live UI.

OpenUI Lang itself looks like a short program of named statements. A response might declare a root card, then a title, a table and a button, each a call to a component the developer registered. Because the format is line-oriented rather than one large JSON object, the client can parse and render partial output while the model is still writing, instead of waiting for a closing brace.

The repository ships a framework-agnostic core (lang-core), React rendering (react-lang), prebuilt chat layouts and component libraries (react-ui), bindings for Vue, Svelte and Angular, a browser bundle for no-build embeds, an A2UI client, LangChain and assistant-ui integrations, and a CLI that scaffolds a working chat app with one command. Thesys says the stack works with any model, including local ones; when it open-sourced its take on generated chat interfaces on 12 October, Guha specifically mentioned models running on Ollama. For a sense of how quickly this pattern is spreading, compare CopilotKit's Open Intelligent UI release, which landed days earlier.

What is new in the 1.0 language

The What's New in 1.0 page groups the changes around one goal: letting a component library grow beyond the built-ins.

• Custom functions: defineFunction adds @-functions the model can call, such as a percentage formatter, with arguments checked like component props and a failed call evaluating to null instead of breaking the page.
• Custom actions: defineAction lets a generated button trigger the host app's own code, for example copying an order ID, with typed parameters delivered to an onAction handler.
• Lighter actions: a single action no longer needs an Action([...]) wrapper; several steps still do, and @ToAssistant can now pass arbitrary context back to the host.
• library.extend: derive a library from an existing one by adding, overriding or removing components, functions and actions.
• Entry rule: the statement named root is the entry point; without it, the first statement that calls the library's root component is used and a no-root warning is raised.
• Message format: buildMessage and parseMessage store responses between ]]>openui: marker lines, optionally with form state, so a saved answer can be rendered again later.

What breaks when you upgrade

The 1.0 changelog is blunt about compatibility. The react-lang 1.0.0 release notes say lang-core, react-lang and the server that generates the system prompt must be upgraded together, because a 1.0 prompt teaches bare action steps that a 0.x client does not run. react-ui 0.18 requires react-lang 1.0, the browser bundle 0.2 packages both, and server 0.3 uses lang-core 1.0 for its autofix parser. Teams still on a 0.x client are told to stay on server 0.2.

Several runtime behaviours also change. A program whose root statement arrives last now shows nothing while it streams, so the prompt asks the model to write root first. A cut-off generation that never reaches its root renders blank rather than as a partial tree. A program with no root and no call to the root component no longer falls back to rendering its first component. On the TypeScript side, ACTION_NAMES and the old BUILTINS exports are removed, and the ActionStep union gains a custom_action variant, so code that switches over action types needs a new case.

The biggest practical limit is framework coverage. The Vue, Svelte and Angular packages stay on OpenUI Lang 0.4 and must be paired with lang-core 0.4. The 1.0 language features, including custom functions, custom actions and single-step actions, need the React renderer for now.

Token and reliability claims, and who measured them

Thesys's README claims OpenUI Lang uses up to 67% fewer tokens than equivalent JSON. Its table, measured with the tiktoken GPT-5 encoder across seven interface scenarios, totals 4,800 tokens for OpenUI Lang against 10,180 for Vercel's JSON-Render format and 9,948 for Thesys's own older C1 JSON format, roughly 52% fewer in both cases. Methodology and samples sit in the repository's benchmarks folder, so the count can be reproduced, but the scenarios were chosen by the vendor.

The Reliability page adds a second vendor benchmark: six models, 46 prompts and four generations per prompt, or 1,104 runs per format. OpenUI Lang completed 92.9% of tasks with 2 fully blank screens; A2UI completed 92.4% with 53 blank screens; json-render completed 81.3% with 9. Thesys stresses that no format was error-free and that its best model pairing reached 99.5%, not 100%. It also reports that one prompt rule lifted a model's completion rate by 13 percentage points, while a wrong example caused double-digit regressions.

Those are useful signals about where generated interfaces fail, but they are Thesys's measurements of its own format against rivals. AI Lookout has not run the benchmark or built an app with 1.0.

Where OpenUI sits next to Intelligent UI, A2UI and json-render

OpenUI's pitch leans on OpenAI's move. When ChatGPT began composing interactive Intelligent UI answers with GPT-6, it showed users charts and forms instead of markdown. Thesys published a reverse-engineering write-up of that system on 8 October and now offers OpenUI as the version any developer can host.

The comparison table in the README places OpenUI next to Vercel's json-render, Google's A2UI and CopilotKit's generative UI, claiming lower token use and latency and a built-in chat UI. Like the benchmarks, that table is Thesys's own assessment. Notably, OpenUI does not try to replace A2UI outright: the repository includes an A2UI client that carries OpenUI Lang component payloads, a hedge for teams that standardize on Google's protocol.

The broader shift is that agent output is becoming a product surface. Whichever format wins, the hard parts look the same: a component catalogue the model can choose from reliably, validation for when it invents a prop, and a way for generated buttons to call real application code without opening a security hole.

What to check before you build on it

For teams already on OpenUI, the upgrade is a coordinated move: client packages, server prompt generation and any stored responses need to change together, and React is the only path to the new language today. Custom actions are where most care is needed, because they connect model output to your own handlers. The docs say a step with invalid arguments becomes a no-op and that action-prop restrictions currently shape the prompt and schema only, so the runtime does not yet enforce which actions a slot may take. Treat onAction as an API boundary and validate there.

For newcomers, the useful test is narrow: take a handful of real screens from your product, register those components, and run your own prompts repeatedly across the models you actually use. Watch completion rate, blank renders, latency and token cost, and compare against plain text or a JSON tool-call approach. That will tell you more than any vendor table about whether generated UI is ready for your users.