Instant AI App Builder: How mk0r Has a Sandbox Ready Before You Type

The thesis: removing signup is what makes the parallelism possible

When you load mk0r.com, three things start at the same instant: a Firebase anonymous sign-in spins up in the background, a fetch to /api/vm/prewarm fires fire-and-forget, and the input box renders. By the time you have read the example prompts and decided what to build, the server has booted a real cloud sandbox, initialized an agent session inside it, set the model to Haiku, and provisioned a git repo. The sandbox is sitting in a Firestore collection named vm_pool, waiting for your browser to claim it atomically.

None of that can run in parallel if you put a signup wall in front. A builder that asks for an email first has to wait until you have created an account before it can spend money booting a sandbox. By the time you finish entering a password and confirming an email, the cold-boot clock has not even started. Anything that promises "instant" on a signup-gated flow is using a different definition of instant than the one in the dictionary.

The rest of this page is the latency math, the file paths, and an honest section on the tradeoffs.

What happens at t = 0

Open the browser DevTools network panel and load mk0r.com. Inside the first frame after React mounts, you can watch three independent timelines start.

The first three messages start in the same animation frame in a real browser. They are not awaiting each other. The Firebase anonymous sign-in and the prewarm POST are started by separate useEffect hooks, both with empty dependency arrays, and they do not block paint.

The exact lines that make this work

This is not a marketing claim, it is six lines of code. The prewarm fire lives inside the landing page component:

// src/app/(landing)/page.tsx
useEffect(() => {
  fetch("/api/vm/prewarm", { method: "POST" }).catch(() => {});
}, []);

That is the entire mount-time hook. There is no await on the result. There is no auth header. The dependency array is empty, so it runs once on mount, before any other effect that touches the session key, before the auth provider has resolved anonymous sign-in, before the user has scrolled.

The endpoint that receives it is equally permissive. In src/app/api/vm/prewarm/route.ts, the auth check is opt-in:

function checkAuth(req: NextRequest): boolean {
  const required = process.env.POOL_ADMIN_TOKEN;
  if (!required) return true;
  const header = req.headers.get("authorization") || "";
  const token = header.startsWith("Bearer ") ? header.slice(7) : header;
  return token === required;
}

On the public site, POOL_ADMIN_TOKEN is unset, the function returns true, and any browser can nudge the pool. The only side effect is that the server tops up to its target size if it is below it, which costs one (idle) E2B sandbox at most. The full topup logic, including pool inspection, stale cleanup, and fire-and-forget spawning, lives in topupPool() in src/core/e2b.ts.

What is in the pool

When the server warms a sandbox, it does not just reserve a slot. It walks through five real bootstrap steps inside prewarmSession() and only writes a Firestore document when all of them succeed:

1. Boot a fresh E2B sandbox from the mk0r-app-builder template.
2. Send POST /initialize to the in-VM agent client protocol bridge, with the shared API key. This is the slowest call in a cold start.
3. Send POST /session/new with cwd: "/app", the MCP servers config, and the default app builder system prompt. This is the second slowest call.
4. Set the active model to Haiku via POST /session/set_model.
5. Provision a git repo for the session and capture its repoId, identityId, and gitToken.

All of that is paid for and complete by the time the document is marked status: "ready". When you press send, claimPrewarmedSession runs a Firestore runTransaction that filters status == "ready" and specHash == currentSpecHash, reads the first match, deletes it, and hands the live sandbox to your session key. A second visitor cannot claim the same row because the transaction is atomic.

The only remaining cost on your side is one ACP /initialize with your real credentials (which restarts the agent subprocess inside the VM if needed) and a quick echo ok liveness probe. The cold-boot work, the hard part, is already done.

Why a signup gate would break this

Picture the same diagram with an email/password screen between page mount and prewarm. Now the server cannot start a VM until it has a verified user, because every cold sandbox is a real cloud cost and you cannot let strangers DOS your bill. The timeline becomes serial.

The point is not that signup-gated builders are wrong. They make a different tradeoff: lower idle cost, slower first build. We picked the other side. We trade a small steady-state cost (one idle E2B sandbox at any given time, by default) for a build experience that starts the second you finish typing.

The boundaries of this argument

Three things this page is not claiming.

First, the pool is small on purpose. The default VM_POOL_TARGET_SIZE is 1. If two strangers land on the homepage in the same second and both press send before the topup re-fires, the second one falls back to a fresh boot. The fast path is the common path, not a guarantee. For most traffic shapes a target of 1 is the right tradeoff because 95% of arrivals never press send.

Second, the pool only helps the very first build. After that, your sandbox is yours. Subsequent prompts re-use the same VM via session reuse, not the pool. The pool is only the on-ramp.

Third, generation itself still takes time. Once the agent inside the VM starts working, it is bounded by Haiku's streaming throughput and whatever tools the agent invokes. "Instant" means the runway from press-send to first-token, not from press-send to done-building. We measure roughly 30 seconds for a Quick mode HTML app and 1 to 3 minutes for a VM mode React project, which matches what the homepage stat band on mk0r.com says.

The honest version of the claim: removing the signup gate buys you about five seconds of latency that would otherwise be unavoidable. Five seconds is not magic, but it is the difference between a builder that feels alive and one that feels like a queue.