The AI prototype tool that tests its own prototype
Every other tool stops when the code is generated. mk0r boots a real Chromium, opens the prototype, takes a Playwright DOM snapshot, reads the console, and only then hands the app back to you. No account. No local setup.
Generation is the easy part
Every AI prototype tool on the market can emit a component tree that typechecks. The hard part is the gap between a file that compiles and a page that renders. A missing CSS import, a hook that bailed out, a stray hydration error, a provider that never wrapped the root; any of these produces a blank page that still passes a build.
mk0r closes that gap by running the prototype inside the same sandbox the agent is writing it in. The agent is not guessing whether it worked. It navigates to the preview, reads the DOM, and reads the console. If the page is blank, the agent sees that the page is blank.
What is actually running inside the VM
The loop the agent is instructed to run
The text below is verbatim from the system instructions handed to the Claude agent that lives inside every mk0r VM (source: src/core/vm-claude-md.ts). No other AI prototype tool ships its agent with a rule that says “do not report completion until the browser shows the expected result.”
What that looks like in practice
Navigate
Agent calls browser_navigate to http://localhost:5173, the Vite dev server on the VM.
Snapshot
Agent takes a Playwright DOM snapshot. The text is structured, not a PNG, so the agent can reason over what is actually on screen.
Read console
Agent calls browser_console_messages and scans for runtime errors and warnings.
Fix or ship
If the DOM is empty or an error fired, the agent edits files and re-runs. Only when the rendered output matches the prompt does the session report success.
The anchor fact: a real browser, not a preview iframe
When the VM starts, it does five things before the agent gets control. It launches an X virtual framebuffer at 1600x900, spawns Chromium with CDP bound to port 9222, starts Playwright MCP on port 3001 attached to that CDP endpoint, starts Vite on port 5173, and boots the ACP bridge that lets Claude run inside the VM. That is the sequence from src/core/freestyle.ts, lines 513 to 573.
Why not just run a preview in the browser?
Because the browser doing the rendering and the agent doing the fixing would be two different machines. The preview tab in your laptop browser cannot tell the agent that a React error boundary tripped. The agent would have to ask you. mk0r puts both on the same side of the wire, so the loop closes without a human in the middle.
There is also a persistence angle. The VM keeps a Chromium profile at /root/.chromium-profile, so cookies and logged-in sessions survive across agent turns. When the agent is building a page that depends on auth, it can log in once and stay logged in.
0 seconds
from opening mk0r.com to typing your first prompt
How mk0r compares to other AI prototype tools
| Feature | Typical AI prototype tool | mk0r |
|---|---|---|
| Account required before first prompt | Yes | No |
| Runs the prototype in a real Chromium | No, preview iframe only | Yes, headful via Xvfb |
| Agent reads its own console errors | No | Yes, via Playwright MCP browser_console_messages |
| Agent takes DOM snapshots before shipping | No | Yes, browser_snapshot each iteration |
| Watch the agent live | Final result only | CDP screencast + noVNC, streamed to browser |
| Output format | Proprietary format or vendor-locked project | Real HTML/CSS/JS or a Vite + React + TS project |
When to pick a self-testing prototype tool
If you are making a static landing page, self-testing is overkill; most tools will get you there. Where it matters is when the prototype has any of the following:
- Client-side state that only breaks on interaction, not on first render.
- A third-party script or API call that can silently fail (a map tile, an auth redirect, a CORS-blocked fetch).
- Tailwind or CSS-in-JS where a missing import produces a styled-looking-but-empty page.
- Multi-screen flows where the agent needs to navigate between routes to confirm the second screen exists.
For those cases, the difference between “AI wrote code that compiles” and “AI wrote code and verified it works” is the difference between a demo you have to debug and a prototype you can hand to a PM.
Frequently asked questions
What makes mk0r different from other AI prototype tools?
mk0r actually runs the prototype it generates. Every VM session boots a headful Chromium on a virtual display (Xvfb at 1600x900), exposes CDP on port 9222, and runs Playwright MCP so the agent can navigate to localhost:5173, take a DOM snapshot, and read browser_console_messages. The agent is instructed not to report completion until the browser shows the expected result. Most competing tools generate code and show you a preview; they do not verify the preview works.
Do I need to sign up to try the prototype tool?
No. Open mk0r.com, type your idea, and the prototype starts streaming. Quick mode (Claude Haiku, single-file HTML/CSS/JS) returns in about 30 seconds with zero account. VM mode (Vite + React + TypeScript + Playwright) boots a sandbox and is free to try without signup as well.
How fast does the VM actually start?
The first boot of a fresh configuration installs Node 20, Chromium, Xvfb, x11vnc, websockify, @playwright/mcp, and scaffolds a Vite React+TS app; that takes roughly five to ten minutes. After that, mk0r snapshots the running state and keys the snapshot by a hash of the setup scripts. Every subsequent VM restores from the live snapshot, so the full stack (Chromium, CDP, Playwright MCP, ACP bridge, Vite dev server, proxy) is up in seconds, not minutes.
Can I watch what the agent is doing?
Yes. The VM exposes a CDP screencast WebSocket and a noVNC WebSocket. mk0r proxies both through the browser, so you watch the agent move the Chromium cursor, click, type, and take snapshots live. It is not a mock preview; it is the real browser inside the VM.
What does the output look like when I am done?
In Quick mode, you get a standalone HTML file you can download and open anywhere. In VM mode, you get a full Vite + React + TypeScript project in /app with Tailwind configured, HMR wired for HTTPS proxy use (clientPort 443, wss), and a real Chromium profile at /root/.chromium-profile so logged-in sessions persist inside the sandbox.
Why does the agent test in a real browser instead of just checking types?
Typecheck passes do not mean the UI rendered. A component can compile, mount, and still produce a blank page because a CSS import is missing, a hook bailed out, or a hydration error fired. mk0r's agent is told to navigate, snapshot the DOM, read the console, and loop until the rendered output matches the request. That is the difference between a prototype that looks plausible and a prototype that is actually running.
Which Playwright MCP version is running inside the VM?
@playwright/mcp@0.0.70, pinned. It runs at http://127.0.0.1:3001 inside the VM, attached to Chromium via CDP on 9222. The Claude agent inside the VM receives it as an MCP server, so tool calls like browser_navigate and browser_snapshot are first-class to the agent.
Try the prototype tool that runs its own prototype
No signup. Describe your app, watch the agent build it, then watch a real Chromium render it before it reaches you.
Start building