HTML let any server talk to any browser. Markdown let any tool show any note. Generative UI has no equivalent yet: each library has its own output shape, its own error behaviour and its own idea of what a generated screen may do. This page argues that a shared format is worth having, and that GistUI Protocol v1 is a credible candidate.
What a shared format gives each party
App developers
- No lock-in. An answer is text in a documented format. Change the renderer, the framework or the library version and stored conversations still render.
- One safety model. What a generated UI can and cannot do is written down and testable, not discovered by reading a library’s source.
- Portable catalogs. A component set is a manifest. The same manifest drives the prompt, the parser and the validator, in any language.
Model providers and trainers
- One target. A model that writes the format well works with every conforming renderer. Fine-tuning or evaluating on it is not a bet on one vendor.
- Checkable output. “Valid” has a definition: a conforming processor reports no diagnostic. Benchmarks become comparable.
- Cheap output. Fewer tokens for the same screen is lower cost and less waiting, for every user of the model.
Tool and agent builders
- Composability. An MCP server, an agent framework and a chat client can pass a program between them without agreeing on a library.
- Second implementations. A parser in Python, Rust or Swift can be written from the specification and proven with the conformance suite.
End users
- Interfaces instead of walls of text, in any app, with the same behaviour: forms that validate, tables that sort, links that cannot do something unexpected.
- Accessibility as a requirement, not a feature of one component library.
What a standard for this has to get right
A format for model-written UI has requirements that a format for human-written UI does not.
| Requirement | Why | In v1 |
|---|---|---|
| Streamable | People watch it arrive. Waiting for a closing brace is a blank screen | Line-based; each statement is usable when its line ends; chunking never changes the result |
| Token-efficient | Output tokens are the cost and the latency | Positional arguments, bare enums and flags, data written once as tables |
| Error-tolerant, deterministically | Models slip. Different recoveries mean different screens | Numbered recovery rules; required diagnostics; same tree in every processor |
| Safe by construction | The author is a model that may have read hostile content | No code execution; read and write tools separated; URL policy; limits |
| Catalog-driven | Every product has its own components | The catalog is data: one manifest for prompt, parser and validator |
| Interactive without round trips | A filter should not cost a model call | Client-side state, expressions and queries, all bounded |
| Editable | The second request is usually a small change | Patches, appends and deletes addressed by id |
| Testable | A standard nobody can verify is a document | 149 conformance cases, each run whole and one character at a time |
| Transport-neutral | Stacks differ | A content format with separate bindings |
Why this format in particular
It is measured. On OpenUI’s own generative-UI benchmark (46 screens, 4 runs, the same catalog and model for both), it needs a smaller system prompt and fewer output tokens than OpenUI Lang, more answers are valid as written, and after its code-only repair every screen is valid. Rendering a streaming answer takes 2–6× less main-thread work. The numbers are in Comparison.
It defines recovery. This is the part other formats leave out. A JSON-based format has one recovery: fail. A DSL without recovery rules has as many as it has implementations. v1 lists each slip, the rule that repairs it and the diagnostic to report.
It treats the program as untrusted. Tools that read and tools that write are different things in the format itself. A renderer that conforms cannot be made to change data by showing a program.
It is small. The reference processor is about 16 KB gzip with no dependencies, and streams a typical screen in a quarter of a millisecond.
It does not replace what exists. It is a content format. It rides on HTTP streams, MCP tool results and AG-UI events, and it maps to A2UI. See Bindings.
What is not done yet
A candid list, because a standard is a promise.
- One implementation. The reference processor is the only complete one. A standard needs a second.
- Working Draft. Some behaviours were chosen where the implementation was silent; Appendix D of the specification lists them.
- Media type.
text/vnd.gistuiis not registered with IANA. - Runtime and renderer suites. Conformance cases cover processors. Runtime and renderer claims are made against the text.
- Governance. The specification lives in the GistUI repository under the MIT licence. There is no standards body behind it.
- Model coverage. Two models have complete benchmark runs.
How to take part
- Read the format and file issues where it is unclear: github.com/GistUI/GistUI/issues.
- Write a processor in another language and run the suite: Implement it.
- Add a model to the benchmark: Benchmarks.