Live artifacts are three different architectures
A sandboxed page with a versioned link, a full dev environment in a browser tab, and real production component code all get called the same thing, and each trades control against containment differently.
“Live artifact” names three different things. The term gets used for a rendered sandbox inside a chat interface, for a full development environment running in a browser tab, and for production-grade component code that deploys to a real host. These share a surface feature: the output renders rather than displaying as text. The underlying architectures are genuinely different, and they trade off different things.
The first pattern: an AI chat platform renders generated HTML, React, or markdown inside a sandboxed frame, assembled from the model's full context — the codebase, connected tools, the conversation thread. When you iterate, the platform republishes in place. Durability here comes from “publish again, same link, new version.” The link is stable because the URL is versioned, not because a new one is minted each time. Call this the sandboxed-page pattern.
edit
rendered — live
This paragraph is the artifact
Edit the text on the left. It re-renders immediately on the right — no refresh, no round trip to a server.
That loop is the whole trick behind every piece in this section. They're artifacts too.
nothing here touches a server — the state lives in this tab, and a refresh reverts it. Publish doesn't write anywhere either; it just bumps the number, the way a real version bumps against a link that never changes.
The second pattern runs a full Node.js environment compiled to WebAssembly, entirely inside the browser tab. No remote VM, no server-side execution. A virtual filesystem, a virtualized network stack, an install step that actually works, a terminal, a real dev server — all client-side. This is the approach behind tools built on WebContainers. A model operating here controls an entire environment, not just a rendered output. That's a meaningful difference, not a cosmetic one.
The third is generative UI: real React, Tailwind, and component-library code, iteratively edited inside the platform, optimized for production-realistic reuse rather than a sandboxed preview or a full in-browser OS. The artifact here is closer to a deployable component than a live demo. The point isn't the preview. It's the code that ships.
The three patterns diverge on security, and the divergence is intentional. OS-level sandboxing — Linux bubblewrap, macOS Seatbelt — wraps every subprocess a coding agent spawns, combining filesystem and network isolation into one boundary, which in practice cuts permission prompts dramatically. A microVM-per-execution model, purpose-built for AI-agent and code-generation workloads, assumes process isolation can't be taken for granted and gives each run its own machine instead. The plain web-platform CSP and iframe sandbox directive, underlying most live-preview-in-an-iframe tools, disables scripts, forms, and popups by default and re-enables them token by token.
The design decision underneath all of this is how much control you hand the model versus how contained the blast radius is if it's wrong. A full in-browser OS gives the most control and the least containment. A CSP iframe gives the least control and the most containment. The sandboxed-page pattern sits in the middle, and that middle position is intentional. It's the same tradeoff every piece in this Thinking section is quietly making — they're artifacts too, durable at a stable link, editable, live, running inside exactly this kind of sandbox.
I picked the control-versus-containment balance the same way anyone does — by deciding how much I trust the model, and how much I'd rather not find out.