AI app builder state limits, in four layers

The four layers, ordered by where they break first

When someone says “AI app builder state limits” they usually mean one of these four things, but they don’t say which. The ceilings are very different.

1. 1. Component state (React)

   Ceiling: none. This is just useState and useReducer.

   Lives for the page load. Resets on refresh. The agent uses this for the first version of any prototype: the active screen, form values, the selected item. If your app forgets things on refresh, you are looking at this layer and you want the next one.

2. 2. Browser storage (localStorage / IndexedDB)

   Ceiling:the browser’s default quota (typically 5 to 10 MB for localStorage, hundreds of MB for IndexedDB).

   Survives refresh, tab close, and reboot. Cleared when the user clears site data. Per-device. Useful for personal todo lists, drafts, settings. Useless for anything that needs to be shared between users or read from another device.

3. 3. Sandbox session (the agent’s VM)

   Ceiling: 3,600,000 ms idle, then pause. This is the only hard wall in the whole system.

   The sandbox is where your project files live during agent edits. Every successful turn calls commitTurn and lands as a real git commit; the SHAs are pushed onto an unbounded historyStack array (line 100 of src/core/e2b.ts). After one hour idle, the sandbox pauses. When you come back, it resumes from the same disk and the same git HEAD. Nothing is lost; you just wait a few seconds for the reconnect.

4. 4. Database (Neon Postgres, pre-provisioned)

   Ceiling:whatever Neon’s plan limits are. Effectively none for a prototype.

   This is the layer most articles claim doesn’t exist for AI app builders. It exists. Every project that mk0r generates in VM mode has a Postgres connection string pre-wired into /app/.env from turn zero. The agent reads it, writes migrations, inserts rows. Data lives outside the sandbox; it survives the 1-hour pause, the project being abandoned for weeks, and the user moving between devices.

The .env that gets written when the sandbox boots

You can verify layer 4 yourself. The instruction file at docker/e2b/files/app/CLAUDE.md tells the agent which services are pre-provisioned. The values are written into /app/.env before the agent reads its first prompt. A redacted version of what you’d see in a real session:

That’s a real Postgres URL, a real Resend API key, a real PostHog project, and a real GitHub remote. The agent does not have to ask you for credentials, and you do not have to sign up for any of them. Your app’s data layer exists from the first prompt.

The one constant that matters

Layer 3 is the only layer with a builder-imposed ceiling, and it is a single number. Below the ceiling: nothing about your project state is capped. The undo history is a plain array, not a circular buffer. The turn log is not truncated. The transcript is not summarized. Every turn is a real commit on a real git history you can pull and read.

What survives a sandbox idle pause

The 1-hour idle timer sounds scary if you read it as a deadline. It isn’t one. When the sandbox pauses, this is what you keep:

The pause is not a deletion event. It’s a hibernation. The sandbox VM goes cold, the disk image is preserved, and the next time you send a prompt the runtime calls Sandbox.connect and re-arms the timer. From your perspective: the editor reloads, the preview comes back, the chat history is intact, the git log shows the same SHAs in the same order. The agent does not have to be told what you were working on; the working tree is already there.

Where the “AI apps can’t keep state” framing comes from

The framing is a true sentence about a different category of tool. One-shot HTML generators (Claude Artifacts, the Quick mode in mk0r, most chat-based code outputs) really don’t have layer 3 or layer 4. They produce a single self-contained HTML file with no execution context. Anything beyond what fits in localStorage is gone on refresh. For that category, “no real database” is accurate.

Sandbox-based builders are a different shape. They give the agent a real Vite + React project, a real filesystem, a real git history, and (in mk0r’s case) a real Postgres URL on day one. The state ceiling is one constant in source, the database is in a different service that survives independently, and the failure mode of a long idle period is “wait three seconds for the reconnect”, not “your data is gone”.

When someone reads the genre-level claim (“AI app builders can’t persist”) and applies it to every tool in the space, they end up overestimating their problem and reaching for heavyweight tools they don’t need. The honest position is: ask which of the four layers you’re hitting. If it’s 1 or 2, you’re fine. If it’s 3, you’ll wait a few seconds on resume. If it’s 4, the connection string is already in your .env.

When you actually outgrow this

A builder that has all four layers is enough for prototypes, internal tools, hobby apps, demo backends, and the first few users of a real product. It is not enough for a production multi-tenant system with strict row-level security, paid SLAs, complex permissions, and many concurrent writers. At that point the handover is straightforward: pull the GitHub repo down, point a production Postgres instance at the same schema, deploy the React app somewhere with a real CI pipeline. The state model you’ve been using all along (component, browser, database) maps cleanly onto whatever you migrate to. The sandbox layer is the only one you’re leaving behind, and you don’t need it once the agent isn’t doing your edits.

Frequently asked