GistUI vs OpenUI, measured

1. Rendering a streaming answer

The question that matters to a person watching: how much work does the page do while the answer streams in? Both libraries ran in the same React 19 page in Chrome, production builds, each with its own default components. Each was fed the same screen at the same pace, and Chrome counted the main-thread time: parsing, rendering, layout and style.

• The screens are OpenUI's own seven samples, updated to its current syntax, with matching GistUI versions; both parse with no errors. The eighth puts all seven in one long answer.
• The stream grows by 4 characters every 10 ms, about 100 tokens a second, on a fixed clock: a busy page receives several chunks at once, as it would from the network.
• Each number is the median of 3 runs, each in a fresh page.

Main-thread time, normal CPU

Main-thread time, CPU slowed 4× (a mid-range phone)

A fast model, about 1,000 tokens a second, normal CPU

Result: 2–6× less work on these screens. The gap grows with the length of the answer: 6.0× less on the longest one. Both stayed smooth: no task blocked the page for more than a few milliseconds, and no frame took longer than 67 ms. GistUI shows the first content sooner on every screen. Part of the difference is the format itself: GistUI's version of each screen is about a third shorter, so there is less text to process.

2. The parsers alone

Inside that work, the parser. Here each parser read the same screens in chunks, and after every chunk produced an up-to-date result, as a renderer needs. OpenUI re-reads the whole answer on every chunk, so its time grows with the square of the answer's length; GistUI reads each new character once.

Times are OpenUI / GistUI, in milliseconds, for the whole screen. Read all at once, the two are about as fast. Streamed, the difference is large on long answers, but it is a small part of the total: rendering the components, above, costs much more than parsing.

3. Accuracy and tokens with real models

On generative-ui-bench, the benchmark OpenUI publishes: 46 screens, 4 runs each, the same 70-component catalog, examples and settings for both formats. Only the language differs. A screen counts as valid when it parses, every component and prop is valid, nothing is left dangling, and it has the components the brief asks for.

The repair

GistUI's repair is plain code in the library: no second model call, nothing to pay for, and it runs once when the stream ends, in about a millisecond. It fixes each mistake where it points, keeps everything the model wrote that can be kept, and lists every change. OpenUI repairs with a second model call in OpenUI Cloud, which its benchmark does not include; the OpenUI numbers here are as the model wrote them, like GistUI's “as written”.

A small model shows why the repair matters: gpt-5-nano writes few screens that are valid as written in either format, about 22%, and GistUI's repair takes it to 99.5%. What the repair cannot fix is an answer the model never finished: code cannot add what was never written.

4. What the browser downloads

The renderer plus the default component library, minified and gzipped, React excluded: 74 KB for GistUI and 699 KB for OpenUI (@openuidev/react-ui 0.16.3). GistUI loads charts, tables, slides and other heavy parts only when an answer uses them.

Limits

• The model test covers two models, gpt-oss-120b and gpt-5-nano; more will follow.
• Each model figure is one run at temperature 0.7, so a few points are noise. With gpt-oss-120b, three GistUI runs with slightly different prompts scored 86.7% to 87.9% (the best is reported) against 84.6% for OpenUI's one run: read it as slightly ahead, not settled.
• The rendering test compares each library with its own components, which is what you get by default. A different component library changes the numbers.
• Run it yourself: bench/render (rendering and parsers) and bench/genui (the model test) in the repository.