OpenUI Lang 1.0: What Actually Shipped, and What Didn't

The Short Answer

OpenUI Lang 1.0 shipped on 12 October 2026, but only the language core and its React runtime reached 1.0. The Vue, Svelte and Angular runtimes stay on 0.x, and the system prompt your model receives is generated by a server package that must match the client. On ibl.ai you own all the code and the data, so every layer in that chain is yours to version.

Generative UI is the idea that an agent answers with an interface rather than a paragraph. It is a real shift, and the version story underneath it is the part nobody is reading.

What exactly shipped in OpenUI Lang 1.0 on 12 October 2026?

Two npm packages reached 1.0.0 on 12 October 2026: @openuidev/lang-core and @openuidev/react-lang, both released from pull request #1348 in the thesysdev/openui repository. A patch, 1.0.1, followed on 15 October 2026.

That is the whole of the 1.0. The thesysdev/openui monorepo publishes seventeen packages; two are at 1.0 and the other fifteen are pre-1.0.

The repository is MIT-licensed, written in TypeScript, and was created on 2 December 2024. As of 16 October 2026 it carried 11,252 stars and 757 forks.

The project's own documentation describes OpenUI Lang as "a compact language that lets models respond with live, interactive interfaces built from your own components, instead of only text."

Which OpenUI is this — the Thesys one or the Weights & Biases one?

There are two active open-source projects named OpenUI, and they are unrelated. This matters if you are about to send a star count to a procurement committee.

The one that shipped OpenUI Lang 1.0 is thesysdev/openui, maintained by Thesys, MIT-licensed, 11,252 stars, created December 2024. It is a UI language plus framework runtimes.

The other is wandb/openui from Weights & Biases, Apache-2.0, 22,611 stars, created March 2024, described as a tool that "let's you describe UI using your imagination, then see it rendered live." It is a design-time generator, not a runtime for agent output.

The more-starred repository is the one that did not release 1.0 — it has published no releases at all. Any claim about "OpenUI's" adoption needs to say which OpenUI.

Which OpenUI packages are actually at 1.0, and which are still 0.x?

Here is the real version matrix for the twelve packages a generative-UI integration touches directly, read from the npm registry's latest tag on 16 October 2026.

The five monorepo packages not in that table are all pre-1.0 too: devtools 0.3.0, observability 0.0.4, observability-cloud 0.0.3, assistant-ui 0.2.0, and a2ui 0.5.0.

One more package shares the npm scope without sharing the repository, and it is worth knowing about if you run agents on OpenClaw. @openuidev/openclaw-os-plugin 0.1.5 is MIT-licensed, published from thesysdev/openclaw-os rather than from the openui monorepo, and describes itself as an "OpenClaw plugin that turns agent responses into Generative UI and serves the claw-client at /plugins/openclawos."

It pulled 3,364 downloads in the trailing year — an early integration, not a stable one.

The release notes are explicit about the version split, and worth quoting rather than summarizing: "vue-lang, svelte-lang and angular-lang stay on 0.4 (OpenUI Lang 0.x). Keep @openuidev/lang-core ^0.4 for the prompts they render."

So three of the four framework runtimes are a major version behind the language they render, by design, and the maintainers said so.

That is good release hygiene. The ambiguity is in the name rather than the notes: the pull request itself is titled "OpenUI 1.0," so a buyer who reads the headline and not the changelog will reasonably assume the project reached 1.0 rather than two of its seventeen packages.

Why does an OpenUI version upgrade touch the model's system prompt?

This is the part that makes generative UI architecturally different from a normal frontend dependency, and it is spelled out in the 1.0 notes.

In generative UI the model does not return prose. It returns a short program in a UI language, referencing components from your library.

Something has to teach the model that syntax, and in OpenUI that something is the server package, which turns your component library into instructions for the model.

The consequence, verbatim from the release notes: "A 1.0 prompt teaches bare action steps (@ToAssistant("Hi") without Action([...])), which a 0.x client does not run."

The version of your frontend runtime is now a property of your model's output format. Mismatch them and the model emits syntactically valid output that your client silently declines to execute.

The notes chain that constraint across the whole stack. "react-ui 0.18 requires react-lang 1.0 (peer >=1.0.0 <2.0.0); upgrade them together." And: "server 0.3 uses lang-core 1.0 for autofix (parser and system prompt); stay on server 0.2 with a 0.x client."

There is a failure mode in there worth internalizing even if you never touch OpenUI.

A cut-off output "that never reached its root statement, or any statement calling the root component, now renders blank instead of a partial tree" — a half-streamed interface is a worse answer than no interface, so 1.0 chose to show nothing.

A generative-UI upgrade is therefore a coordinated change across four layers: the system prompt, the server that generates it, the client runtime, and the component library.

Two of those four are yours either way.

The client runtime is an npm package you pin in your own frontend, and the component library has to be yours or there is nothing for the model to compose from — the project's docs define the language as building interfaces "from your own components."

The asymmetry is in the other two.

When a vendor runs the generation step, the server and the system prompt it produces sit on their side of the boundary, so their upgrade window sets yours — and per the release notes, a prompt and a client on different major versions do not work together.

Is OpenUI Lang really framework-agnostic, or is it a React standard?

The packaging says framework-agnostic: there are runtimes for React, Vue, Svelte and Angular. The download numbers say something narrower.

Across the trailing twelve months ending 12 October 2026, the seventeen monorepo packages pulled 7,114,178 npm downloads combined.

No single package is close to that: the largest, lang-core, is 2,179,663, or nearly a third of that total. Any one-figure "downloads" headline for OpenUI is a scope-wide annual sum, so check which packages it includes before repeating it.

The comparison that settles the framework-agnostic question is the four language runtimes against each other, because they occupy the same layer and do the same job. Over the same twelve months they pulled 2,052,418 downloads between them.

The three non-React runtimes together are 79,989 downloads, or 3.9% — a 24.7-to-1 ratio against the React runtime. Against Angular alone it is roughly 1,600 to 1.

One number it would be wrong to put on the React side of that ledger is lang-core's 2.18M.

It is the framework-agnostic parser, and the Vue, Svelte and Angular runtimes depend on it too — which is exactly why the release notes tell their users to "keep @openuidev/lang-core ^0.4 for the prompts they render."

So: an "open standard for generative UI" is, by adoption and by version parity, currently a React standard with three experimental ports.

That is a fine place for a December-2024 project to be. It is not what the phrase "open standard" implies when it reaches a procurement document.

The same reading applies to the project's token-efficiency claim. Its documentation states models generate OpenUI Lang "in less than half the tokens of JSON-based formats."

That is the project's own measurement, and it does publish a methodology — 46 interface briefs across six models and three formats.

Two things keep it from being an independent check: it is vendor-run, and its own methodology page says the validating parser is lang-core 0.2.16 — a pre-1.0 parser, so it does not measure the 1.0 language.

What does generative UI change for a K-12 district that already deployed a chatbot?

Take the clearest named ICP: a K-12 district that has already put an assistant in front of students.

Text is the interface almost everyone shipped first, and students have adopted it.

Pew Research Center's "How Teens Use and View AI," published 24 February 2026 from a survey of 1,458 U.S. teens and their parents fielded 25 September to 9 October 2025, found 57% of teens had used chatbots to search for information and 54% to get help with schoolwork.

That is adoption of a text box. A draggable number line, a labeled diagram a student can manipulate, a form that collects exactly the five fields a registrar needs — those are different artifacts, and a paragraph cannot be one.

Here is the governance consequence, and it is specific to generative UI rather than general AI worry.

When an agent answers with text, the thing you review is a string.

When an agent answers with an interface, the thing you review is a program that runs in a student's browser, composed from your component library, and that renders differently depending on which client version you shipped.

The review surface changed shape.

A district that can read the parser, pin the system prompt, diff the component library between terms, and keep a log of which program each student actually received is governing that surface.

A district consuming a hosted generative-UI feature is accepting whatever prompt-and-server combination the vendor is shipping that week.

This is the same boundary we wrote about in MCP as the USB-C of AI: a standard is an opportunity to own infrastructure or a way to plug your data into someone else's. Generative UI moves that question from the tool channel to the output channel.

What do you need to own to run generative UI on your own terms?

With ibl.ai you own all the code and the data.

That is not an abstraction in this case — it maps onto the two coupled layers a hosted generative-UI feature keeps on its own side.

The system prompt is a file in your repository rather than the output of a vendor's generation step. The server that builds it runs inside your perimeter, on a version you chose, upgraded when your term calendar allows rather than when a release train arrives.

It runs model-agnostic across any LLM, so the model that emits the UI program is a choice you keep.

It is usage-based with no per-seat pricing, so an interface a thousand students load does not multiply a license fee. And it deploys anywhere — your own cloud, on-premise, GovCloud, or a fully air-gapped network.

1.6M+ users across 400+ organizations run the platform this way, including NVIDIA, MIT, and Syracuse University.

ibl.ai is family-owned and operated from New York, NY — a U.S.-headquartered, domestically-owned long-term partner, not a vendor that sells licenses and moves on.

Generative UI is going to be a real capability, and OpenUI Lang 1.0 is a credible step toward it. The release notes are honest about what is stable and what is not. Read them before you read the headline.

Related reading: MCP as the USB-C of AI — the same own-it-or-plug-into-it question on the tool channel; and Open-source agent infrastructure: who governs the agents? — why giving the runtime away moves the governance question below it.

Sources: the 1.0 release date, the quoted upgrade constraints and the framework-runtime split from the @openuidev/lang-core@1.0.0 release notes and pull request #1348; the star count, fork count, license and creation date from the thesysdev/openui repository and the wandb/openui repository; the package versions and download totals from the npm registry; the language description and token claim from the OpenUI documentation; the teen survey figures, sample size and field dates from Pew Research Center.