Generative UI: native vs CopilotKit vs OpenUI

The agent's generative UI can reach a browser three ways: the native React client over the native stream, or a third-party frontend over AG-UI. This page compares the three for generative UI only — tool-driven components, progressive rendering, model-composed layouts, model-written views, interactive components, persistence, non-visual surfaces, validation, DX and cost. Every cell comes from running the same agent behind three pages:

• Native — @adonis-agora/agent/react: <AgentProvider>, useAgentChat, <GenerativeUI>.
• CopilotKit 1.77 — the v2 API (@copilotkit/react-core/v2, CopilotChat) on agUiAdapter().
• OpenUI 0.17 — @openuidev/react-ui's AgentInterface on agUiAdapter().

The app is the frontends example (AdonisJS 7, SQLite, a scripted model, no API key). Its pnpm e2e drives every scenario on every page in headless Chromium and saves the screenshots its README shows. Versions: @adonis-agora/agent 0.66.0, @copilotkit/react-core 1.77.1, @openuidev/react-ui 0.17.0.

Why nativeCopy Anchor Link

CopilotKit and OpenUI are frontends: they draw in the browser and stop there. The native client is the browser half of a generative UI that lives on the server, and that is where it pulls ahead:

• The model designs in your design system, not someone else's. For what no component fits, the sandbox lets the model write the view, with your styles, your components and your providers through a sandbox kit — Tailwind, Bootstrap, plain CSS, shadcn, a customized MUI. A view it invents looks like the rest of your app. OpenUI's views look like OpenUI's library.
• The model writes behavior, not just layout. A calculator, a simulation, a slider that recomputes a chart: the sandbox runs the model's own code in an isolated frame with no network, and a button sends values back as the next turn through a checked bridge. A layout of fixed components cannot do that.
• Nothing reaches the screen unchecked. Every component's props, every ui__render tree and every sandbox's code is checked on the server before it is accepted. A mistake goes back to the model as a tool error and it fixes it. CopilotKit hands renderers unvalidated arguments; OpenUI drops invalid output without telling anyone.
• One answer, every channel. The same component is drawn in React, in React Native, as text on WhatsApp, Telegram or e-mail, or as a PNG or PDF — with per-channel conversions you choose, and the text the model writes knowing what was actually delivered. A UI that exists only as model text, or only as a browser renderer, has nothing to send a text channel.
• It is governed. UI tools declare an authorization ability like any other tool, approvals are part of the transcript, and every UI call is recorded as telemetry — first-try success, what the model got wrong, cost, time to first frame — on the dashboard's Generative UI page, metadata only by default.
• No glue. History, thread lists, approvals, tool-pushed components and skeletons work out of the box. Against this agent CopilotKit needs ~70 lines for history and OpenUI ~45 lines for history plus ~46 for approvals (see the matrix).
• And it still interoperates. The same agent serves AG-UI for CopilotKit and OpenUI and A2UI for Google's renderers, so choosing native closes no door.

The rest of this page is the evidence: the same agent behind all three frontends, every scenario run in a browser.

Three models of generative UICopy Anchor Link

They do not mean the same thing by "generative UI", and that drives most of the table below.

So on the OpenUI page the server must hand the model the library's prompt, and the model answers in OpenUI Lang; on the CopilotKit page the server's own components (agora.ui events) are ignored unless app code reads them. The example does exactly that — the OpenUI setup and the CopilotKit setup below show how.

The matrixCopy Anchor Link

Built in means the frontend's documented API does it against this agent. Glue is app code that bridges the frontend to this agent — the count is non-blank, non-comment lines in the example. No means the frontend has no way to do it.

Token counts use the o200k tokenizer on the exact system prompt and tool definitions the model received, and on the two outputs for the same dashboard. Rows 1–9 were run on all three pages. Rows 10–12 were run on the native page (the sandbox scenario) and in this library's tests; the CopilotKit and OpenUI cells there come from their documentation and showcase apps, not from the example's e2e.

Where each one winsCopy Anchor Link

Native with the sandbox is now the strongest at letting the model design the screen, and it designs it in your app's look. With a sandbox kit the model writes JSX with your own components, your styles (Tailwind, Bootstrap, Sass, plain CSS) and your providers (MUI, emotion), so a view it invents looks like the rest of the app, not like a third-party library. It can write behavior too — state, inputs, a calculation, a chart of a shape no component draws — which a composition of fixed components cannot. The code is checked before it is accepted (it parses, it has an App, it uses only the kit's components and the agent.send bridge), and a failure goes back to the model as a tool error, so it retries instead of failing silently. It streams in an order that is usable before it is finished — the reserved box, then styles, then markup, then behavior — and a text channel gets its title and summary. What it costs: the views run in an isolated frame with no network, the model writes more output than an OpenUI Lang statement for the same screen, and you set up a kit once (one Vite plugin, found through your build — no presets).

OpenUI is the quickest way to model-designed screens when you have no design system to bring. Its library is large and styled out of the box, the model composes it freely, what it writes renders as it streams, a component is one definition, and it spends fewer output tokens for the same UI. What it costs: a long prompt on every turn with its full library, a look that is OpenUI's rather than yours, layouts made only of its components (no behavior of the model's own), UI that exists only as model text — no fallback text, nothing for a text channel, no server render — and invalid output that fails silently. Interactive approvals and history need glue against this agent.

CopilotKit draws a layout while the model is still writing its arguments with no setup, from the raw partial arguments (unvalidated; renderers have to survive half-written props), and it speaks AG-UI interrupts natively (useInterrupt, resume), so approvals work with no glue. It ships more framework targets. Against this agent it needs glue for history, a thread list, and the components tools push.

Native is also the strongest where the server matters: one validated, versioned catalog as the source of truth, the same output on a text channel, an image or a PDF, and persistence, approvals and interactive components with no glue. With streaming: 'partial' it draws a layout while the model writes it, with stable nodes, an incomplete flag for skeletons and only the validated tree stored, and a tool can show its component's skeleton before it reads (Loading states and skeletons). Its catalog builtins have no visuals, so you write those renderers and their skeletons, and its exact ui__render schema costs more prompt than a generic one.

ChoosingCopy Anchor Link

• Your own app, and the same agent behind WhatsApp, Slack or e-mail — native. Components are validated once on the server and degrade to text or images on every other surface (per channel).
• Open-ended, model-designed screens in your own design system (calculators, simulations, dashboards, explorations) — native with the sandbox and a kit: catalog components for what you planned, the sandbox for the rest.
• Model-designed screens with no design system of your own, where only the web matters — OpenUI, with a component library of your size to keep the prompt down.
• An app already on CopilotKit, or that needs its Vue/Angular/React Native components — CopilotKit over agUiAdapter(); budget the glue for history and pushed components.

Sandboxed views and A2UICopy Anchor Link

Two more pages of the example go past the matrix:

• A sandbox scenario on the native page: with genui({ catalog, sandbox: true }), the model answers a request no catalog component fits (a bill splitter) with a sandboxed view — the placeholder at its declared height, the styled preview while the markup streams, then the live view in an isolated iframe, whose button sends the values back as the next turn through GenuiActionProvider and sendUiAction.
• An A2UI page: the same agent served by a2uiAdapter(), its JSON Lines read into @a2ui/web_core's MessageProcessor and drawn with the official React renderer, @a2ui/react (A2uiSurface, basicCatalog). The builtins arrive mapped onto A2UI's basic catalog, previews grow the same surface, and an approval is an Approve / Reject pair of A2UI buttons. What it gives up next to the native client (no custom renderers without your own A2UI catalog, the sandbox as text) is listed in Known gaps.

Setting up CopilotKitCopy Anchor Link

CopilotKit's v2 API takes an AG-UI HttpAgent directly. Point it at the AG-UI route, and add shield's CSRF header (the session cookie rides by default):

import { CopilotChat, CopilotKitProvider, HttpAgent, useRenderTool } from '@copilotkit/react-core/v2'
import '@copilotkit/react-core/v2/styles.css'
import { z } from 'zod'

const csrfFetch: typeof fetch = (input, init = {}) => {
  const token = document.cookie.match(/(?:^|; )XSRF-TOKEN=([^;]*)/)?.[1]
  const headers = new Headers(init.headers)
  if (token) headers.set('X-XSRF-TOKEN', decodeURIComponent(token))
  return fetch(input, { ...init, headers, credentials: 'same-origin' })
}

const agent = new HttpAgent({ url: '/agent/ag-ui', fetch: csrfFetch })

export default function Page({ threadId }: { threadId: string }) {
  return (
    <CopilotKitProvider agents__unsafe_dev_only={{ default: agent }}>
      <Renderers />
      <CopilotChat threadId={threadId} />
    </CopilotKitProvider>
  )
}

function Renderers() {
  // A server tool's call, drawn from its result.
  useRenderTool({
    name: 'list_orders',
    parameters: z.object({}),
    render: ({ result }) => (result ? <OrderList {...JSON.parse(result)} /> : <p>Loading…</p>),
  })
  return null
}

• agents__unsafe_dev_only is CopilotKit's name for an agent the browser calls itself. For production CopilotKit expects a CopilotRuntime (@copilotkit/runtime/v2) in front of the agent; it then calls <path>/ag-ui server to server, and has to forward the session cookie and the CSRF header (forwardHeaders).
• Approvals and questions arrive as AG-UI interrupts. useInterrupt({ render }) draws them, and resolve({ approved: true }, interrupt.id) sends the resume the interrupt section describes.
• Components a tool pushes arrive as agora.ui custom events; read them with agent.subscribe({ onCustomEvent }), keyed by toolCallId. History: subclass HttpAgent and implement connect() to replay GET <path>/threads/:id as a MESSAGES_SNAPSHOT. Both are in the example.
• @ag-ui/client 1.0.2 refuses a run that leaves an open interrupt unanswered ("pending interrupt(s) not addressed by resume", read in its code): answer the interrupt before the next message.

See alsoCopy Anchor Link

• OpenUI — the OpenUI setup: the library prompt on the server, custom components, threads, approvals.
• AG-UI — the route both third-party pages use, and its interrupt and resume contract.
• A2UI — the A2UI route, the builtin mappings, and A2UI over AG-UI.
• Sandboxed generated UI — the sandbox component and its security model.
• What AG-UI costs you — every capability, native stream vs AG-UI.
• Generative UI, Builtin components and Loading states and skeletons — the native side.