OpenUI 1.0 review: your agent should stream your components, not a text box

The short verdict

Around October 15, 2026, Thesys announced OpenUI 1.0: an open standard so an agent can stream interactive interface, not only prose, and render it from components you already own.

The pitch is simple. For thirty years software turned information into interfaces. Chat agents mostly went the other way and put everything back into a text box. OpenUI Lang is a compact, streaming-first language the model writes; your client turns those lines into your buttons, forms, tables and charts while tokens are still arriving.

Our verdict, up front. If you are building an agent product inside a web app you control, and you have a React design system you trust, OpenUI 1.0 is a strong starting point for generative UI. If your agent only needs to answer in text, or your team lives in Vue, Svelte or Angular and needs the newest language features today, wait or stay on the 0.x path the docs still support for those frameworks. This is engineering tooling, not a store theme.

What you actually get

At the center is OpenUI Lang. It is not JSON. Each line names a component and how it nests, so the page can paint while the model is still talking. You define which components the model may use, generate prompt instructions from that library, and render as the stream arrives.

First-party runtimes cover React, Vue, Svelte and Angular. The marketing site also lists common model providers and agent stacks (OpenAI, Anthropic, Gemini and others; Vercel AI SDK, LangChain, LangGraph and similar). You keep your model and your agent code; OpenUI sits in the presentation layer.

Version 1.0, documented on the project's what's-new page, adds custom functions and custom actions (defineFunction, defineAction), library.extend so you can derive a product-specific library from a base one, a message format for storing responses, and shorter action syntax for a single action. Those 1.0 language features currently need the React renderer. Vue, Svelte and Angular packages remain on the 0.x language line for now.

Thesys also sells OpenUI Cloud pieces around the open source core (Gateway to repair invalid output while streaming, Observability for what users saw). The framework itself is free and open source. Cloud pricing is something you evaluate separately if you want hosted repair and monitoring.

What it costs and what it asks of you

The library is free. The cost is product ownership.

Someone has to decide which components the model may emit, keep that library in sync with design, upgrade lang-core and react-lang together when you take 1.0, and test what happens when a stream cuts off before a root statement. The 1.0 notes are explicit: a cut-off program that never reaches root can render blank. That is better than painting a half-broken tree, and it means your team needs streaming tests, not only happy-path demos.

You also need a real design system. Generative UI only helps if the model is allowed to use the same components your designers already trust. If every answer invents a new layout from scratch, you have traded a text box for visual noise.

And you need an application that can host the renderer. OpenUI is not a Shopify app and not a no-code agent builder. It assumes developers.

Where it falls short, and the alternatives

Framework lag on 1.0. If your product is Vue- or Angular-first and you need custom actions and library.extend now, the docs say those features need React for the moment. Plan for that, or stay on 0.x until parity lands.

It does not invent product judgment. Streaming a comparison table of three hotels is only useful if your backend can supply trustworthy rows. OpenUI renders; your systems still decide truth.

Vendor claims are not your SLA. The site publishes speed and token comparisons against JSON UI formats. Treat those as vendor figures until you measure your own screens.

Alternatives are plain. Stay text-first if the job is explanation, not interaction. Use a proprietary generative-UI path from a single model vendor if you are already locked to that stack and do not need an open language. Build a fixed UI the agent fills through tools if your flows are few and stable. OpenUI earns its keep when the shape of the answer should change with the question, using your chrome.

Who should use it

Use it if you ship copilots or agent surfaces inside a product you own, you already talk about a component library in design reviews, and React is an acceptable home for the generative surface.

Wait if you are still deciding what the agent is allowed to do. Permissions and tools first; presentation second. We have written about giving an agent a job rather than a personality.

Skip it if you needed a merchant-facing “AI storefront” button. That is a different problem (catalog, checkout authority, theme apps). OpenUI will not merchandise your SKUs.

Before you commit, pick three real jobs your agent already fails at in text—comparing options, collecting a structured request, showing status—and sketch which of your existing components would answer each job. If you cannot name the components, you are not ready for generative UI.

If you do move ahead, treat the first month as instrumentation, not a redesign. Log which components the model actually emits, which streams fail before root, and which answers users abandon. Those three numbers tell you whether generative UI is earning its keep better than any vendor chart.

Also be honest about chat. Some jobs should stay in a thread. OpenUI is strongest when the next useful thing is a control the user can act on—pick a plan, confirm a row, adjust a filter—not when the next useful thing is another paragraph.

Put this into practice

List the ten components you would allow a model to emit next quarter. Write the ones you would forbid. That allow-list is the real product decision; OpenUI is how you enforce it in the stream.

Then decide who owns upgrades when 1.0 pulls React forward and other frameworks trail. Put that name next to the repo.

We build web applications where agents, APIs and interfaces stay aligned. If you are weighing OpenUI against keeping a text chat, talk to us.

Related work: Howcast.