OpenGenerativeUI: a CopilotKit demo for agent-generated HTML, SVG and 3D

What OpenGenerativeUI actually solves

Most chat interfaces return prose. When a user asks how binary search narrows an array, or what a BFS frontier looks like step by step, prose is the wrong medium and a static image is the wrong medium too, because the answer changes with the input. OpenGenerativeUI exists to close that gap: the agent returns a live component, rendered as HTML and SVG inside a sandboxed iframe, with light and dark theming and responsive sizing handled by a shared design system.

The audience is narrow and specific. This is a demonstration repository for engineers building on CopilotKit who want to see generative UI wired end to end, including the streaming path, the sandbox bridge and the skill-loading scheme. The README describes it as an open-source showcase, and the package.json name is copilotkit-langgraph-template, which tells you how to read the project: it is a template you study and fork, not a dependency you add to package.json and forget.

The streaming path from prompt to sandboxed iframe

The mechanism is the interesting part, and the README lays it out as six steps. A prompt arrives through the CopilotKit chat UI. A Deep Agent decides whether to answer in text, call a tool, or render a component, consulting skill documents as needed. If it renders, the canonical tool is generateSandboxedUi, exposed by the CopilotKit runtime when openGenerativeUI is enabled.

That tool does not receive one HTML blob. It receives ordered streaming parameters: initialHeight, then placeholderMessages, then css, then html, then jsFunctions, then jsExpressions. The order matters because the frontend can start drawing before the document is complete. OpenGenerativeUIMiddleware in the runtime translates the streaming tool call into open-generative-ui activity events, and the demo's activity renderer, registered through renderActivityMessages, morphs each update into a preview iframe with Idiomorph so nothing flickers. Only when streaming finishes does the final websandbox iframe boot with the shared design-system CSS and a CDN importmap injected.

Two details are worth noting because they shape what you can build. First, the generated UI talks back to the host through Zod-validated sendPrompt and openLink sandbox functions, so a button inside generated HTML can send a new prompt. Second, a ResizeObserver inside the iframe reports content height continuously, which is why the frame grows with the visualization instead of scrolling. Both are host-side contracts you inherit if you copy the pattern.

Skills as SKILL.md files instead of one giant system prompt

The agent is built with create_deep_agent from LangChain Deep Agents, and its instructions live in three SKILL.md files under apps/agent/skills/: advanced-visualization, master-playbook and svg-diagrams. Rather than concatenating every visualization rule into the system prompt, the agent loads a skill on demand. The README calls this progressive disclosure, and it is the same idea as documentation that is fetched when needed rather than pasted into context at the start.

The practical consequence is that adding a new visual style means adding a skill document, not editing a prompt string. It also means the quality of your output depends on writing those documents well, since the agent's decisions about charts versus SVG diagrams come from them. The README includes a decision matrix mapping user intent to output type and technology, for example physical explanations to SVG, abstract explanations to HTML with inline SVG, and process descriptions to flowcharts.

Installing it and rendering your first widget

Setup is a Makefile target. make setup installs dependencies and creates a .env template, and the README notes that you must edit apps/agent/.env with your real Anthropic API key before starting anything.

make setup    # Install deps + create .env template
# Edit apps/agent/.env with your real Anthropic API key
make dev      # Start all services

After make dev, the README says the app is at http://localhost:3000 and the agent at http://localhost:8123. The Makefile also exposes narrower targets (dev-app, dev-agent, dev-mcp) and the same scripts are reachable through pnpm, for example pnpm dev:agent, which runs uv sync and then uvicorn main:app on port 8123 with reload enabled.

Model selection happens in the environment file. The default is claude-fable-5, with claude-opus-4-6 listed as a strong alternative, and setting LLM_MODEL to a gpt-* name routes to OpenAI instead, which requires OPENAI_API_KEY.

ANTHROPIC_API_KEY=
LLM_MODEL=claude-fable-5
RATE_LIMIT_ENABLED=false
RATE_LIMIT_WINDOW_MS=60000
RATE_LIMIT_MAX=40

Those last three keys come from .env.example and control per-IP rate limiting, which is off by default. The README is explicit that the model tier is not negotiable: smaller or weaker models produce broken layouts, missing interactivity or incomplete visualizations. That is a cost decision disguised as a configuration decision, and it is the first thing to price out.

The MCP server, and why it is the most reusable piece

Alongside the web app, the repository ships a standalone Model Context Protocol server that exposes the design system, the skill documents and an HTML assembler to any MCP-compatible client, including Claude Desktop, Claude Code and Cursor. Its assemble_document tool wraps HTML fragments with the full design system CSS and bridge JS and returns an iframe-ready document. It also serves skills as resources under skills://list and skills://{name}, plus prompt templates for widgets, SVG diagrams and advanced visualizations.

For Claude Desktop the README gives a stdio configuration pointing at dist/stdio.js with a cwd of apps/mcp. For HTTP clients you start the server with pnpm dev inside apps/mcp and register http://localhost:3100/mcp in .mcp.json. This is the part of the repository with the least CopilotKit coupling: if you already use an MCP client and only want the design system and the document assembler, you can run this server without adopting the frontend or the agent. Full configuration, Docker deployment and an API reference are said to live in apps/mcp/README.md.

Where the design breaks down

The clearest limitation is model dependence, and the README states it rather than burying it. Generating well-structured HTML and SVG in a single pass is a hard task, and the project's own guidance is that weak models fail visibly. If your deployment needs a small local model, or a cheap hosted one, this architecture is the wrong tool and no configuration flag fixes it.

Provider flexibility is the second constraint. Anthropic and OpenAI are handled through LLM_MODEL, but the README says other providers require swapping the chat model in apps/agent/src/model.py. That is a source edit, not a setting, so provider portability is a maintenance cost you take on.

The third is that this is a demonstration repository. The repository lists no releases, so there is no versioned artifact to pin and no changelog to read before upgrading. The README does not document rollback behaviour for the streaming renderer, and it does not describe what happens when a generated document throws inside the sandbox beyond the existence of the bridge functions. If your team needs a supported upgrade path, treat the code as a reference to reimplement rather than a component to depend on.

How it differs from CopilotKit's own useComponent approach

CopilotKit supports generative UI in more than one way, and the README's pattern table makes the contrast concrete. The useComponent hook renders predefined React components, so the model chooses which component to show and what props to pass, but the component itself was written by you ahead of time. useFrontendTool, useHumanInTheLoop and useDefaultRenderTool cover other interaction shapes.

OpenGenerativeUI sits at the opposite end. Nothing is predefined: the model emits HTML, CSS and JavaScript that no developer reviewed, and the sandbox plus the Zod-validated bridge exist precisely because that code is untrusted. The trade is control for range. A useComponent pie chart will look consistent and fail predictably; a generated dashboard can express something you never anticipated and can also arrive malformed. If your visual vocabulary is small and stable, useComponent is the lower-risk choice and this repository is overkill. If the whole point is that you cannot enumerate the visuals in advance, the sandboxed streaming approach is what makes that safe enough to ship.

Licence, maintenance and what an upgrade costs

The repository is MIT licensed, which permits commercial use and modification provided the copyright notice and permission notice are retained. That is a statement about the licence text, not legal advice; if you redistribute a modified version, have your own counsel confirm the notice requirements.

Maintenance signals are mixed and worth reading plainly. The repository is not archived, and the last push was on 2026-06-10, roughly three months before this writing. There are no retrieved releases, so there is no tagged version to upgrade between. In practice that means upgrades happen by diffing the repository against your fork: the middleware, the activity renderer and the three SKILL.md files are the surfaces most likely to move, and any of them changing can alter output quality without changing your code. Budget for re-reading the streaming parameter order and the bridge function signatures whenever you pull, because those are the contracts your own frontend will depend on.

Editorial conclusion

Adopt it if you want a working reference for the generateSandboxedUi streaming pattern and are willing to read the three apps rather than import a package: the MIT licence makes copying the middleware and renderer into your own CopilotKit app the realistic path. Do not adopt it if you need a supported library with versioned releases, a documented rollback story, or a cheap model, since the README states that weaker models produce broken layouts and the repository lists no releases. Verify two things before committing: that your provider can drive the model named by LLM_MODEL, and that apps/agent/src/model.py is the file you are prepared to edit for any provider other than Anthropic or OpenAI.

Frequently asked questions

Official sources

1. CopilotKit/OpenGenerativeUI on GitHub
2. Issues
3. License: MIT
4. Project website
5. README