Replit vibe coding starts from a cold Repl. mk0r starts from a pool.

The thing every Replit vibe coding tutorial leaves out

Every walkthrough on this topic covers the same loop. Sign in to Replit. Pick or create a Repl. Open the Agent panel. Describe the app. Watch files appear. The prose is correct but it hides the thing that actually defines the user experience: the boot wait between "I have an idea" and "the model is generating." That wait is the sum of account gating, Repl creation, dependency install, and dev-server start. You cannot prompt your way out of it; it has to be designed out.

mk0r designs it out with a pool. The landing page is coded to ping the pool on mount, the server tops the pool up to a target size, and every first prompt claims a ready sandbox. Replit's model assumes you are a Replit user, so the Repl is tied to your account and cannot be pre-created anonymously. mk0r is session-keyed by a UUID in localStorage, so the pool can be fully anonymous.

That useEffect block is the entire client-side contract. Nothing in it blocks the UI. The fetch is fire-and-forget; it returns before the user has finished reading the hero. On the server, the ping invokes topupPool(), which looks at current pool size, subtracts ready and warming entries from the target, and kicks off prewarmSession() calls in parallel for the gap.

The three constants that define the pool

The pool is a tiny amount of code doing a specific job. Three constants govern it. The collection name tells Firestore where to store entries. The max age tells cleanup when to kill a sandbox that has been warming too long. The target size tells topup how many ready entries to maintain.

The 45-minute cap is the one worth pausing on. E2B sandboxes have a 1-hour timeout. If a sandbox sat in the pool for 59 minutes before claim, the claimer would inherit a sandbox about to expire. The 45-minute cap means stale pool entries are killed by cleanupStalePool() with 15 minutes of headroom so the claimer always gets real runtime.

What boots before your first keystroke

Pre-warming is not just "start a sandbox in the background." It is a five-phase pipeline that mirrors the hot path so that on claim, only the user-specific step needs to re-run. Here is the actual body of prewarmSession() with the comments the author left in place.

How the claim actually happens

When your first prompt arrives, getOrCreateSession() tries three things in order. It checks for a live session tied to your session key. It tries Firestore for a paused session it can resume. Then, and this is the part most vibe coding tools do not have, it tries to claim a pre-warmed sandbox from the pool. Only if those three miss does it fall through to a cold boot.

The void topupPool().catch(() => {}) on success is the bit that keeps the experience good at scale. The claimer does not wait for the refill. The next user still gets a warm sandbox because the pool refills in the background the moment the current claim returns.

Pool claim flow, end to end

Four actors, six messages. The landing page pings on mount. The API route tops up the pool. E2B boots a real sandbox. The ACP bridge inside the sandbox initializes. Firestore holds the status transition. When you finally press enter, the claim pulls from Firestore instead of booting.

What the pool collapses into at runtime

The architecture is easier to see as a fan-in. Many inputs contribute to a single ready sandbox on the left. Many outputs fall out of that sandbox on the right. The hub in the middle is the pool entry.

Watching a pool entry from the inside

The pool exists on disk as Firestore documents and as live E2B sandboxes. If you tail the logs during a prewarm, you see the state transitions in order. This is one warm-start as it appears in the [e2b] log stream on Cloud Run.

What Replit does first, and what mk0r does instead

Both flows end with an AI agent writing code against a natural language prompt. They start at very different places.

A more honest side-by-side

Both are real products with real tradeoffs. Replit has things mk0r does not, including hosting, a multi-file editor, a marketplace, and full team features. mk0r trades breadth for a very narrow thing: the shortest possible path from a URL to a working AI-built app.

When Replit vibe coding is still the right answer

Two cases. First, when you want the full IDE surface: a proper file tree, multi-file editing, Replit's deploy pipeline, and long-lived hosted Repls with uptime. mk0r is a creation loop, not a hosting platform. Second, when you are teaching. The DeepLearning.AI and DataCamp courses walk through Replit Agent in detail and the screenshots line up with what you see on screen.

If what you want is the shortest possible path from idea to agent is writing code, the pool is the answer. It is not a Replit-shaped answer; it is a different answer.

What ships in the stack either way

The pre-warm is invisible to the user, but the moving parts are concrete and can be listed out.

Try it as the Replit Agent user you already are

The easiest sanity check is the stopwatch. Open two tabs. Log in to Replit, create a new Repl, and start a new Agent chat with a simple prompt like "build me a habit tracker with email reminders." In the other tab, open mk0r.com and type the same prompt. Time from tab activation to first streamed token. That delta is almost entirely the pool.

The 0-minute pool lifetime, 0 default target size, and 0 boot phases that finish before you type are why the stopwatch comes out the way it does.