Post-UI

Wed, 15 Jul 2026 17:27:00 GMT

I’ve been thinking a lot about “post-UI”, whatever that means. It's been rattling around in my head for months, "do we even need to ship a frontend?". If the client can understand the shape of a response and the response has enough context, why can't it build its own interface?

The idea isn’t new. HATEOAS has been around since the early days. A response could details how to move through an application alongside the current state, letting the client discover the system as you move through it. And I think we're on the cusp of this becoming reality, as local models grow in capability while shrinking in size.

The first build

The first attempt was garbage. I can't even really call it mine. With all the fuss around Fable and Codex oneshotting tasks I gave each LLM a rough PRD, and let them run. Got a lot of code that looked vaguely related to the prompt, including one version that had prebuilt layouts wrapped around prettified JSON, which... no. Missed the mark and burned my usage limits.

Archived those two and simplified to a Vite SPA with a hello world, and soon switched to Svelte while the idea was still small enough to hold in my head.

The shape

From there I started replacing assumptions with a contract.

The host fetches a JSON object and reduces it to a typed silhouette. Keys and nesting stay intact. Arrays use the shape of their first item, so a week of forecast data costs about the same prompt space as a single day.

An abbreviated weather response becomes this:

{
  latitude:n,
  longitude:n,
  current:{time:s,temperature_2m:n,weather_code:n},
  daily:{time:[s],temperature_2m_max:[n],temperature_2m_min:[n]}
}

The model gets the silhouette, route context, a little steering, and some libraries it can use. It does not get Los Angeles, the current temperature, the forecast, or anything else.

The runtime response stays on the left. The model received only its typed silhouette.

I started with a Shadow DOM. Fine for CSS, but not for JavaScript. So I switched to an iframe . The host builds the document and gives the generated code root, data, and explicitly allowed libraries. Imports, fetch, eval, dynamic loading, nested frames, and external styles are rejected by the contract unless explicitly allowed.

There is still plenty of authored client code wrapping everything. Svelte fetches data, passes the shape to an LLM, handles routing, caching, and the iframe. It just doesn't know what weather, a Pokémon, or an earthquake page should look at first.

Testing it

Once weather worked, I threw a few public APIs at it. Hacker News, an OpenAPI document, earthquake data, and PokéAPI. Different shapes, different amounts of nesting, and no agreement about what an interface should look like.

Some tests got steering. The earthquake prompt asks for an interactive globe and gives the model Three.js. That is enough to aim the model without hiding a globe component in the prototype.

The response provides the events. The steering supplies a direction, not a globe component.

Walking an API

PokéAPI was the first test where a link mattered. Activating a relation in the collection renderer makes the iframe send an intent back to the host. The host fetches the next object, infers the shape, then generates or reuses another renderer.

Collection, creature, and species are three different systems discovered while moving through the API. This is the part I was actually trying to get to. The response carries the next move alongside the current state, and the client discovers another system by following it.

Each navigation changes both the response and the generated system: collection, creature, then species.

The wait

Once the renderers worked, I timed them. A run ended when the iframe had a document, reported that it was no longer busy, and lost the loading overlay. The model stayed fixed at gpt-5.6-sol, reasoning none, on the fast service tier.

Shape	Runtime JSON	Data	Generation	Cold total
Weather	1.6 KB	0.8 s	42.8 s	44.0 s
Hacker News	8.4 KB	0.4 s	26.6 s	27.8 s
OpenAPI	3.2 KB	0.6 s	30.9 s	32.1 s
Art Institute	6.4 KB	0.2 s	31.6 s	32.4 s
Earthquakes + Three.js	200.6 KB	0.2 s	55.3 s	56.8 s
Pokédex cold stages	28.9 KB	0.5 s	116.2 s	118.3 s

Those are selected results, with three cold runs behind each row. Enough to find the bottleneck, not enough to pretend this is a population-level benchmark. Across the full 27-run set, navigation to ready averaged 38.7 seconds, which is pretty abysmal.

Kimi

To check whether I'd tuned the contract around Sol, I sent the same first-pass prompts to moonshotai/kimi-k3 through OpenRouter. The application's first-pass prompt hashes matched for all nine shapes.

Profile	Ready	Ready-time figure
Sol	27 / 27	38.7 s across all 27
Kimi K3	3 / 11	219.5 s for the 3 successes

The Kimi number is the flattering version because it only includes the three renderers that finished. Their matching Sol samples averaged 32.7 seconds. Successful Kimi runs were 6.7 times slower before counting the other eight attempts that never produced anything usable.

When it got through, the work was good. Kimi turned the art response into a quiet collection wall and the 151 Pokémon into a searchable field guide.

This is one of the Kimi requests that made it through. The values stayed browser-side here too.

The 11 browser attempts made 61 OpenRouter HTTP attempts. Some died on repeated 429s in about 34 seconds. Others sat pending until the 235-second request deadline and produced no usable renderer. Species got one after 207.8 seconds, failed a static-style check, and entered repair. The browser's 240-second cutoff got there first.

The responses logged at least $0.409 in cost, including that unusable species renderer. Calls that failed without usage data may have added more. No second same-model endpoint was visible. Maybe that was temporary capacity trouble. It was still the path the browser had to deal with.

I went into that pass thinking generation speed was the bottleneck. Kimi split it into admission, generation, and repair. Completion rate belongs next to latency or the number is mostly fiction.

Local

I want this to be local. In my head, that is the end goal, the ultimate realization of this idea, the thing that just isn't possible yet. Local models are progressing with leaps and bounds and they still fall flat on their face when you task them with anything complex. And this leads to another assumption I'm making — specialized local models with distinct training sets are going to reach the OS level (hi radiant.computer), handling background tasks like rendering and file management. 7mb embedding models like Ternlight are already available, and then there is stuff like Ternary Bonsai, which can run comfortably on webgpu with Transformers.js

I tried a few quantized Gemma models and some of the smaller Ternary Bonsai models first. The ones that fit could begin the job. Finishing it was another matter.

Bonsai 1.7B was the first one that "worked". Kinda. Not really. Asking for a complete renderer in one go was too much, so I had to break it into a few smaller tasks. That was enough to get a rough page.

Same shape-to-renderer path, this time without a remote model.

I tried that same page with Transformers.js and BitGPU. Two runs each, hardly science, but enough to get a feel for where the wait was coming from.

Runtime	First token	Full page
Transformers.js	2.6–3.9 s	34.8 s
BitGPU	1.0–1.1 s	50.1 s

BitGPU got to the first token about two seconds sooner, then finished the page about fifteen seconds later. I care about when the page exists, so Transformers.js won this very small test.

The weird part is that I expected the model to be the failure. Bonsai understood the contract well enough to make a rough browser-status page from the silhouette. Waiting was worse. Thirty-four seconds warm is bad. I cleared the browser cache and got 73.4 seconds, which I only tolerate because I built the thing.

I think the mistake might be asking a general model to do this. Rendering a page from one of these shapes is a narrow job, and the contract is already doing a lot of the work. A small model trained specifically for this shape-to-renderer loop would have less to figure out each time. I don't have that model, but Bonsai got close enough to make me want one.

The remote models are staying for now because waiting half a minute makes every contract change miserable to test. They let me keep working on the shape, walking APIs, and steering while the local path sits beside them. I mostly keep refreshing it to see how much of that minute I can remove.

iammatthias — #user-interface