#The problem with waiting for the end

When a model answers with UI instead of text, drawing it isn't the hard part. The hard part is what to do with the bits that are wrong while the answer is still arriving.

And models get UI wrong all the time. They invent a component your app doesn't have, add an attribute that doesn't exist, or close a tag with its parent's name. With a JSON format you usually find out at the end, when the whole thing fails to parse, and the reader has been looking at a spinner the whole time.

#Why one line at a time

The model writes Markdown with a few tags. Here's a short answer, and what the reader sees:

## Weekend in Lisbon
<Columns>
<Stat label="Budget" value="$330" />
<Stat label="Per day" value="$165" />
</Columns>
<Chart type="bar" title="Where it goes">
| Item | USD |
|---|---|
| Stay | 180 |
| Food | 90 |
| Trams | 60 |
</Chart>

Models already write Markdown well, and a tag per line is easy for them to get right. It also means half an answer is always a valid start of the whole one. There's no closing bracket to wait for, so the page draws the heading and the first stat before the model has written the second.

#What happens to each line

The checking happens in a small Rust core, no_std, compiled to WebAssembly for the browser (about 219 KB compressed) and linked natively for SwiftUI and Compose. It knows the app's catalog: 75 built-in components in packs, plus whatever the app registers itself.

#Lenient where the intent is clear

Plenty of mistakes have an obvious meaning, and the core reads them that way instead of failing. Here a model wrote tone="error" where the component says danger, and type="column" where it says bar:

<Callout tone="error" title="Payment failed">
The card was declined. Try another one.
</Callout>
<Chart type="column" title="Sign-ups this week">
| Day | Sign-ups |
|---|---|
| Mon | 12 |
| Tue | 18 |
| Wed | 9 |
</Chart>

The core reads error as danger and column as bar, and notes both. The answer is still valid, so nothing goes back to the model.

#Strict where it isn't

When the intent isn't clear, the line gets a diagnostic with a class, tied to the line it's on. A made-up <Weather city="Lisbon"> is a hallucinated-component: it's sent for repair, and until then its words are drawn as plain text, so nothing the model said disappears.

None of what the model writes ever runs: no scripts, no inline styles, and pictures only from hosts the app allows.

#Repair, only where it's needed

When a line breaks a rule, the API sends the model just the broken lines with what's wrong with each and asks for those lines again. Everything else stays as it streamed. Broken nesting is mended with no model at all, and the most common problem, an answer that left its tags open, gets its closing lines appended in place, so nothing on the page is swapped.

#Testing it

Streaming bugs tend to live exactly at chunk boundaries. So every recorded answer we have, 3,371 of them, is fed to the core split at every possible point, and each split has to give the same tree as the whole answer.

A parser that reads untrusted text from a model should never panic either, so the core runs under a fuzzer for 24 hours at a time:

#Try it

The web SDK is one package:

npm install @morphscreen/web

Or start from a working React chat, with the server route and the page already wired:

gh repo create my-chat --template morphscreen/starter-react --private --clone

The core, the format and the SDKs are open source under Apache-2.0 at github.com/morphscreen/morphscreen. Validation and repair in the docs has every rule, and the benchmark has the numbers above with every raw answer.

If you're building something where a model answers with UI, I'd like to hear what breaks for you.

#Why their benchmark

When you build something in a space that already has a known project, the obvious question is "why not just use that?" For generative UI, that project is OpenUI. So instead of writing my own benchmark, I ran theirs.

Thesys publishes generative-ui-bench for OpenUI. I used the same briefs, the same models and providers, and the same rules for what counts as valid, and ran MorphScreen next to the open-source OpenUI library. Everything is on morphscreen.com/benchmark: the method, every raw answer and every row.

One thing up front: this is the open-source library, not Thesys's hosted OpenUI Cloud. I haven't measured that, so nothing here says anything about it.

#How a row counts

A lead only counts when it isn't chance. Where a row counts answers, a two-proportion test has to put the gap below p = 0.05, and timings within 10% of each other are even.

#What each format looks like

The same brief, a newsletter sign-up card, answered by DeepSeek V4 Flash in each format. These are the raw answers from the benchmark, unedited.

<Card title="The Week in Product" subtitle="One email, every Friday, with the best product thinking.">
  <Form name="newsletter-signup">
    <Input label="Email address" name="email" type="email" placeholder="you@example.com" required="true" hint="We'll never share your email" />
    <Button>Subscribe</Button>
    <Button variant="tertiary">No thanks</Button>
  </Form>
</Card>

root = Card([header, form])
header = CardHeader("The Weekly Build", "One email every Friday — a short rundown of the best product, design, and engineering reads we found this week. No fluff, no spam, unsubscribe anytime.")
form = Form("newsletter-signup", formButtons, [emailField])
emailField = FormControl("Email address", emailInput, "We'll only send you the newsletter, never anything else.")
emailInput = Input("email", "you@example.com", "email")
formButtons = Buttons([subscribeBtn])
subscribeBtn = Button("Subscribe", null, "primary")

OpenUI Lang names each piece and wires them together, so a component can be used before it's written. MorphScreen nests tags in the order they're drawn, so each line can go on the page as soon as it's finished. The demo draws both from the same answers side by side.

#Where we lose

All four of OpenUI's wins are answer length. With reasoning off and every component on, our answers run longer. Markdown with tags is less compact than OpenUI Lang, which was designed to be short, and you pay for that in output tokens on every answer.

#Where it's even

Validity before repair, on the default setup (DeepSeek V4 Flash, reasoning off, every component): 87.0% each. On a capable model, both formats come out right most of the time.

#Where we're ahead

Small models. Nemotron 3 Nano 30B wrote a valid MorphScreen answer 66.3% of the time and a valid OpenUI one 31.5%, on the 46 briefs twice each. Models already know Markdown, so there's less to learn.

The prompt. With every component on both sides (our 75, the 63 in OpenUI's chat library), ours is a fifth the size. It goes with every call, so this is a cost on every answer.

After repair, 100% valid (184 of 184) against 84.8%. OpenUI's open-source SDK has no repair step, so this row is really "with repair against without".

Accessibility: 0 axe violations across 20 answers in Chrome, against 599. And in the browser, less work:

#Which to pick

If your answers are short and your model is big, the difference is small and OpenUI is a fine choice, especially if you want everything self-hosted. MorphScreen pulls ahead with small or cheap models, long prompts with many components, and pages that have to pass an accessibility check. Generative UI SDKs compared puts both next to CopilotKit, the Vercel AI SDK, A2UI and others.

#Check it yourself

The benchmark code and every raw answer are in the repository, and the benchmark page has each row with its method. If you think a row is measured unfairly, open an issue and I'll rerun it.