Vibe coding retention limits are four clocks, not one

Why this is four questions, not one

When someone types this topic into a search bar they usually mean one of two things. Either they want to know whether their work is safe (will my project still be there tomorrow?) or whether they will run out of runway mid-build (does the AI keep talking to me, or does it forget partway?). Those are different stacks of state on different clocks, and the answer depends on which one you are asking about.

A vibe coding session in mk0r has at least four retainable things, and each one has a different lifetime, a different eviction trigger, and a different recovery path:

1. The live sandbox VM. The Linux container running your Vite dev server, Chromium, and the ACP agent. This has the strictest clock and the most visible effects when it dies.
2. The pre-warm pool slot. An idle, fully-booted sandbox sitting in a Firestore-tracked pool, waiting for the next visitor to land on the homepage. This clock exists only because the sandbox clock exists.
3. The conversation transcript. The list of prompts and AI responses that the agent uses for context on the next turn. Held by the ACP agent inside the VM, but reconstructible from a Firestore document.
4. The per-turn git history. An ordered stack of commit SHAs, one per prompt, that lets the user undo back to any earlier version of the file tree.

The interesting thing is that every single one of those clocks has a different value, and the source for each value is verifiable in a single file. Below are the constants.

Layer 1: the live sandbox (1 hour, refreshed on every interaction)

The hard number is E2B_TIMEOUT_MS = 3_600_000, 3.6 million milliseconds, one hour. The E2B sandbox runtime interprets this as the maximum idle time before it pauses your VM. Pause is not death; the file system stays around, the snapshot stays around, and a future call to Sandbox.connect() with the same sandbox id will resume it.

The clock resets on every reconnect. That is the part most people do not think about. As long as you keep sending prompts, the one-hour timer never gets a chance to fire, because the reconnect path runs await sandbox.setTimeout(E2B_TIMEOUT_MS) and pushes the deadline back by another full hour.

What this means in practice: a casual session where you send a prompt every few minutes will run forever (until you close the tab or hit a real rate limit). A session where you walk away for over an hour will come back to a paused sandbox, which auto-resumes on your next prompt. The auto-resume usually takes a couple of seconds. If E2B has actually killed the underlying VM, the connect-or-create logic falls through to a fresh sandbox and rehydrates the conversation transcript from Firestore.

Layer 2: the pre-warm pool slot (45 minutes max)

The pool exists so that the first prompt of a new session gets a ready sandbox instead of waiting for one to boot. Unclaimed pool entries are tracked in a separate Firestore collection called vm_pool, and they have their own retention clock: POOL_MAX_AGE_MS = 45 * 60 * 1000. That is 45 minutes, deliberately shorter than the 1-hour sandbox timeout so the sweeper can kill the entry before E2B does.

The sweeper itself is a function called cleanupStalePool. It runs as a side effect when prewarmSession is called, which means it is gated on traffic, not on a cron. That is fine in steady state and slightly leaky on a weekend with no visitors, which is acceptable because E2B kills the underlying VMs anyway after their own 1-hour timer.

Layer 3: the conversation transcript (indefinite, Firestore-backed)

This is the layer most people are actually asking about when they ask about retention. Will the AI remember what I asked it yesterday? In mk0r the answer is yes, as long as the Firestore document for your session is still around.

The transcript itself lives inside the ACP agent process, on the sandbox file system. When the sandbox dies and a fresh one boots, the code calls POST /session/load with the original sessionId and a cwd of /app, and the agent rehydrates its conversation history from disk. The session document in the Firestore collection app_sessions is the durable handle on all of this. As long as it exists, the transcript can be brought back.

The Firestore document is deleted in two situations: the user explicitly resets the session, or an exec probe against a previously-known sandbox returns failure (meaning the sandbox is unreachable beyond what reconnect can fix). The relevant guard sits inside the session-resolve path; on probe failure the doc is deleted with a swallowed-error .delete().catch(() => {}) and the next prompt creates a fresh session.

There is no time-based eviction on the transcript. Idle sessions do not expire on their own. If you come back in two weeks, the transcript is still there.

Layer 4: the per-turn git history (unbounded)

Every prompt that produces a file change runs through commitTurn. That function does a git add -A of the working tree, a git commit, reads git rev-parse HEAD for the new SHA, and pushes it onto an array called session.historyStack. There is no maximum length. The array grows for the life of the session document.

The only place the array is shortened is when you commit on top of an undo. If your activeIndex is mid-stack and you make a new change, the redoable tail gets chopped off by slice(0, activeIndex + 1), then the new SHA is pushed. That is the same behavior git itself uses internally for branch divergence.

What the sandbox itself loses on a sleep-wake cycle

The four retention layers above are about durability across time. There is a fifth thing worth naming: what survives a sandbox pause and resume, and what does not. The file tree, the git history, and the on-disk ACP transcript all survive untouched. The runtime processes started by /opt/startup.sh do not. Specifically: the Vite dev server on port 5173, Chromium with CDP on 9222, the residential proxy on 3000, and the Xvfb virtual display on :99 are all gone after a wake.

The ACP bridge on 3002 stays alive because it is what receives the wake-up call from outside the VM. So the recovery looks like this: on wake, the server-side code probes port 3000 with a one-second TCP check, sees DOWN, and re-runs startup.sh in the background under nohup. Then it polls port 3000 for up to 30 seconds waiting for it to come back up. The function that does this is ensureVmServices and it runs on every reuse of an existing sandbox. So the user never sees the wake; they just see a slightly slower first prompt after a long idle.

What this means for how you should think about a vibe coding session

If you treat a vibe coding session like a chat window, the only retention that matters to you is the transcript, and that one is indefinite. Close your laptop, come back next week, your context is still there. The sandbox underneath has been recycled four or five times by then, but the rehydration is invisible.

If you treat it like a development environment, you care more about what survives a sandbox restart. The answer is: the file tree, the git history, and the transcript. The dev server processes do not, but they are restarted automatically. Anything you write to the file system in your generated app is durable across pause and resume; anything you keep in memory in the dev server process is not.

If you treat it like a database, the right answer is to not. The sandbox is a runtime, not a data store. If your generated app actually needs to keep user data, it needs to be wired up to a real database (Neon is provisioned for new projects), and that data lives outside any of the four retention clocks above.