Twenty-four hours. That's the time a group of developers took to reconstruct the logic of ChatGPT's new generative interface starting from what the browser exposes to anyone. They had no access to OpenAI's internal code: they observed the traffic of the web application and the JavaScript served publicly by chatgpt.com. The result isn't a clone, but a technical map of the 'intelligent UI', the feature that lets the model stop responding only with text or Markdown and compose interactive elements in real time.

The technical starting point deserves clarification. Generative UI isn't a single technique. On one side there are systems that let the model choose ready-made components; on the other there are approaches that let it generate HTML/React code and run it inside an iframe. ChatGPT intelligent UI, OpenUI, Vercel's json-render, Google's a2ui: each sits along this spectrum with different trade-offs in flexibility, reliability, performance, and degrees of freedom.

The interesting part isn't only the speed. It's that the reconstruction happened entirely through publicly observable behavior. In the write-up the team explains that the observations come from ChatGPT accounts, from the traffic generated by the web app, and from the public JavaScript. This lowers the barrier to entry for anyone who wants to understand how a generative UI works without agreements with the vendor.

The team then released Open Intelligent UI, a name that is also a jab at OpenAI's idea of being 'open'. The openui.com domain belongs to them, a detail that makes the provocation more concrete. The technical proposal is clear: use the framework to recreate similar experiences inside your own applications, with a model of your choice.

Here is where the part that interests AI-RADAR enters. OpenUI is model-agnostic, so it can be connected to local models via Ollama or LM Studio. It's not a one-click reconstruction of the ChatGPT experience: anyone who has read the documentation knows that integration, structured output management, and testing are needed. But the building blocks for building a similar experience running entirely locally are there.

Structurally, the signal is twofold. First, generative UI is shifting from a proprietary feature to a composable pattern; value tends to migrate from the model endpoint to the definition of the contract between model and interface. Second, for those evaluating on-premise deployment, the question isn't only the model: it's also the computational cost of generating UI components reliably. Structured output generation adds overhead and latency, and with smaller local models the trade-off between responsiveness and interface quality becomes the knot to untie.

Those who lose in this dynamic are platforms that use the interface as an exclusive advantage. Those who gain are teams that already manage self-hosted pipelines and can reuse the framework without moving data elsewhere. There is no guarantee that a local LLM produces the same visual quality as a frontier model; but the point isn't to imitate ChatGPT, it's to shift control.

In the end, the open question is whether generative UI is a useful direction or another fascinating demo that doesn't hold up in the real world. The speed of the reverse engineering suggests the technology is less esoteric than it seems. For those working with local LLMs, the boundary between consumer and self-hosted has become a little thinner, even if the distance between 'the pieces are there' and 'it works in production' remains exactly what separates a prototype from a system you have to maintain.