Optional OpenUI input for html_render

[Trevor-Compaytence]

Note

Drafted by Claude Opus 5.5 in Claude Code (via T3 Code); reviewed and posted by @Trevor-Compaytence.

Problem

Maintainers pointed LaTeX requests to html_render, and HTML renders work well for rich content. This proposal keeps rich content on that path and adds a compact input format for the most common visuals: tables, stat tiles, status badges and simple charts.

Today each of those is a full HTML page the agent writes from scratch. That has two costs:

1. Output size. A new render repeats layout and styling the agent wrote last time. Let html_render and html_preview reuse a previewed page instead of resending its HTML #18533 and Let an HTML render be reused with fresh data instead of rewritten #17466 are about reusing an existing render; this is about how much the agent has to write for a new one. See also [Bug]: html_render can't reuse a previewed page, so agents re-emit the full HTML on every call #17798.
2. Styling. Each agent makes its own cards, tables and badges. A shared component library would keep common visuals consistent with T3's theme.

Proposal

Let html_render and html_preview optionally take OpenUI Lang instead of html. OpenUI is an open, MIT-licensed format for model-written UI: the agent writes a few lines naming components, and the client draws them. An illustrative example, using a component library T3 would define:

root = Stack([stats, invoices])
stats = Stack([Stat("Open", "7"), Stat("Overdue", "2", "oldest 12 days", "cancelled")], "grid")
invoices = Card("Invoices", [Table(["Client", "Amount", "Status"], [["Acme", "$1,200", Badge("Overdue", "cancelled")]])])

T3 would draw it with components themed by T3's own tokens.

In one invoice example in my own app, I measured 827 characters of OpenUI against 5,797 characters of generated HTML body, and the HTML also needed about 29 KB of CSS. Those are source sizes, not token counts. OpenUI's README claims up to 67% fewer tokens than JSON, which is a different comparison.

Smallest useful scope

• An optional openui input for html_render and html_preview; HTML input stays as it is. The aim is to reuse the current frame, attachments and mobile path, which would need checking.
• Display-only components: cards, tables, stats, badges, lists, simple bar and line charts, progress, callouts, links. No actions, forms, queries or model-defined state in v1. Input checks, size limits, link handling and isolation would still need review.
• Anything outside the library falls back to showing the source as text.

OpenUI ships a React renderer (@openuidev/react-lang) and a framework-agnostic parser (@openuidev/lang-core). In lang-core, runtime telemetry is opt-in (OPENUI_RUNTIME_TELEMETRY_ENABLED=1), but the package also runs install-time telemetry by default unless OPENUI_TELEMETRY_DISABLED=1 or DO_NOT_TRACK=1 is set. That would need a look before taking the dependency.

Prior art

I added this to my own local assistant: a ```openui block in a reply draws from a fixed, display-only component list, and anything outside it falls back to source text. It took a small parser and renderer, checked against the spec's conformance fixtures. Most of the work went into limits (output budgets, positional data with gaps, streaming), not parsing. Happy to share what we learned.

The ask

Would maintainers consider an optional OpenUI input for html_render and html_preview, limited to a fixed library of display-only components? I'd like a yes or no on direction before anyone builds it.

[kvnloo]

Note

Drafted by Claude Opus 5.5 (Hermes, running in T3 Code); reviewed and posted by @kvnloo.

We prototyped this on a fork and measured generation time. The results support the proposal, with one difference in shape that is worth a maintainer decision.

What we built (fork branch experiment/openui-chart-catalog, not a PR):

• A small OpenUI catalog: Board holding Treemap (drill-down and Back), BarChart, StackedArea and Heatmap. These cover the chart families in Theo's Oct 6 T3 Code visualization post: code/churn treemap, model-usage stacked area and activity heatmap.
• Bounded inputs (64 KiB, row and column caps), cross-field checks such as one value per category and one count per cell, and no tools or actions. Interactions stay local.
• The agent writes a fenced openui-v2 block in its normal reply. Web draws it with SVG/HTML themed by T3's tokens. Android draws it with native views, not a WebView.

Measured A/B. Same model (gpt-6.1-sol), same harness (hermes chat), same data; only the answer format changed. Five cases, two reps each, with the order alternated.

	OpenUI board	Self-contained HTML page
Median turn time	20.9 s	52.8 s
Median time after first text	1.8 s	32.4 s
Median output tokens	294	2,867
Median artifact size	638 chars	8,925 chars
Data check passed	10/10 (exact values, parsed)	10/10 (weak check: every number appears in the page)

Per case, OpenUI vs HTML median turn time: repo treemap 17 s vs 54 s, stacked area 22 s vs 41 s, 3×4 heatmap 23 s vs 44 s, disk treemap 21 s vs 63 s, 7×24 heatmap 21 s vs 60 s.

About 17–19 s of every turn is shared time before the first text arrives, so the format difference is almost entirely output length. OpenUI pays for it on the input side: the catalog prompt adds about 4 KB.

Inside T3. In 9 of 9 live turns in one thread, the board parsed and carried the exact supplied data, including a sparse heatmap, a 7×24 grid and nested paths. A pie-chart request, which the catalog doesn't support, came back as bars with a note saying so. Screenshots from the Android build:

The shape question. This discussion proposes OpenUI as an alternative input to html_render. We used a fenced block in the assistant message instead. That way it streams with the reply, stays readable as text on clients without the renderer, and needs no tool call, so the page is never written twice (the cost #23303 measures). Either shape keeps the same catalog and the same savings. If maintainers prefer one, we can align the prototype with it.

Not covered: iOS, and a full visual pass on web; the web side has typecheck and tests only.