Vibe coding state limits, expressed as one number and one stack

The number, and what it covers

The honest move when somebody asks about a tool’s state limit is to give them the literal constant. Most pages on this topic punt and say something like “state can be tricky in AI builders.” Here is the constant and what it actually buys you.

Some context for those numbers. The 1-hour ceiling is set on the sandbox itself: when the SDK calls sandbox.setTimeout(E2B_TIMEOUT_MS) (line 337 of src/core/e2b.ts), E2B starts a clock; if no work happens for an hour, the sandbox pauses. The pause is recoverable. The clock is reset on every activity, including a reconnect after wake.

The other three numbers are the absence of additional limits. There is no second constant for “maximum turns to keep,” no LRU policy on historyStack, no “summarize older turns” step. You can read the type at line 100 to confirm: it is just an array of strings.

What lives where

To say where state breaks, you need a clear map of where state lives. On mk0r there are exactly three places that hold pieces of your project, and each one has a different lifetime.

The interesting consequence of that map: even when the sandbox is gone, the historyStack is not. If E2B reaps your VM (rare, only after extended pause), the next session can boot fresh and the history of what you built is still readable in Firestore. The disk is gone. The list of SHAs is not. Practical implication: if you were going to ship something, hit publish before you walk away for the night.

One turn, end to end, with the actual shell script

The whole “state on each turn” mechanism is one bash script and one Firestore write. Reading the actual commands that run inside the VM at the end of every turn is the fastest way to see why state is durable here. The script below is a copy of what commitTurn (src/core/e2b.ts:1635) executes:

Two things matter in that sequence. First, git add -A captures the entire working tree at once, so multi-file edits land atomically. There is no per-file checkpoint that can drift out of sync with the rest. Second, the SHA returned by git rev-parse HEAD becomes the only thing the server needs to remember about that turn. The transcript is not what holds state. The disk is.

Undo across many turns

If turns are commits, undo is checkout. The function at line 1731 of src/core/e2b.ts reads historyStack[activeIndex - 1], passes that SHA into revertToSha, and runs the same five-line script that puts you back to that turn:

Two reasons this matters more than it sounds. The first is that the model is not consulted. Most builders implement undo as a re-prompt: drop the last user message from the transcript, replay the older prompts, regenerate. The model is non-deterministic so the “undone” project is similar but not equal. mk0r’s undo never asks the model anything; it asks git. Zero token cost, zero variance.

The second is that the new SHA written by undo is appended to the stack, not substituted. So you can also redo. And when you change your mind and start typing in a different direction, line 1676 in the same file slices everything past the active pointer off the stack before pushing the new turn. That single line is the difference between a trustworthy iteration loop and one that starts feeling weird around turn fifteen because abandoned futures keep coming back.

Idle, pause, wake: what a one-hour gap actually does

You leave the tab open while you go to lunch. The sandbox sees no activity for 60 minutes and pauses. You come back, hit refresh, type a new prompt. Here is the trace.

What does the user see? A short pause on first prompt after lunch while the sandbox wakes up, then nothing else. Files are where they were. Undo still walks back through everything you did this morning. The 1-hour ceiling is real, but it is not where state dies; it is where state pauses and resumes.

Where state actually does have a hard edge

Honesty matters more than marketing here. There are two real edges on this state model and you should know both before you build anything you cannot afford to lose.

The mk0r sandbox state is byte-exact undoable. External-service state is not. For a prototype this is almost always the right tradeoff: the parts of the project that you want to mash on (layout, components, copy, logic) are reversible, and the parts that touch the world (rows, emails, repo commits) you usually want to keep anyway. For a production app where you do need rollback of side effects, that is the moment to bring in a developer or write code yourself; no vibe coding tool replaces a real migration story.