AI app builder one-shot prototype limits: the seven clocks

Context window is the limit on how much the model can read and write inside a single response. For a one-shot prototype that produces a small React app or a standalone HTML file, you are nowhere near that ceiling on either side. The cap that bites first is something else: the request timeout on the route that wraps the model call. Every cloud platform draws that line somewhere. Cloud Run defaults to 60 minutes for a streaming response, but most app builders shorten it for cost reasons. mk0r sets it to 800 seconds, which is roughly thirteen minutes. Past that, the platform kills the connection regardless of how much context the model still has to work with.

Eight hundred seconds. The line is `export const maxDuration = 800;` in src/app/api/chat/route.ts at line 18. That is the budget a single one-shot turn has to boot the sandbox if needed, claim a session, send the prompt to the ACP bridge, stream the response, commit a git turn, and close the response. Anything that does not finish in 800 seconds becomes a 504 from the load balancer. The Quick mode path on a small app finishes in seconds; the VM mode path on a complex prompt usually finishes inside two minutes. The 800 second ceiling exists for the worst case, not the typical case.

TTFT means time to first token. mk0r runs a fifteen second timer (`const ttftMs = 15_000;` at src/app/api/chat/route.ts line 421) the moment a prompt is forwarded to the ACP bridge inside the sandbox. If the bridge does not emit any notification before the timer fires, the route assumes the session is wedged. It evicts the active session from the cache, sends a `chat_ttft_timeout` PostHog event, and closes the stream with the message `Agent did not respond within 15s. Please retry.` This is one of the limits no other guide writes about, because it is invisible until you hit a session that lost its ACP subprocess to a crash inside the sandbox.

One hour. `const E2B_TIMEOUT_MS = 3_600_000;` in src/core/e2b.ts line 33. That is the wall-clock lifetime of the sandbox process from when E2B starts it to when E2B reaps it, regardless of how active you are. The pool refreshes its 1h timeout window after every resume from pause, so an active session never hits this. Idle sandboxes do. If you open mk0r, prototype for ten minutes, walk away, and come back ninety minutes later, the original sandbox is gone and you get a fresh one out of the pool (or a cold boot if the pool was empty).

Ten minutes. `const DEFAULT_PAUSE_DELAY_MS = 10 * 60 * 1000;` in src/hooks/useSessionPause.ts line 5. After the tab is hidden for ten minutes, the client disconnects the websockets, unloads the preview iframe, and marks the session as paused. When you focus the tab again, it calls /api/vm/ensure-session which either resumes the paused sandbox or revives it if E2B already collected it. The pause is there to stop wasting browser resources on a tab no one is looking at; it is not the same thing as the sandbox dying. You can override it for testing with `?pauseDelay=10000` in the URL.

Yes, two of them, both visible in src/app/api/chat/route.ts. `const MAX_INLINE_IMAGE = 20 * 1024 * 1024;` (line 269) is the cap for inlining an image as a base64 block in the prompt, so the agent can see it. `const MAX_INLINE_TEXT = 10 * 1024 * 1024;` (line 270) is the cap for inlining a text or JSON file. Both files always get written to /app/uploads/ in the sandbox via writeFileToVm, so the agent can read them with its Read tool even when they exceed the inline cap. The cap only controls whether the bytes ride along with the prompt itself or whether the agent has to fetch them separately.

Forty-five minutes. `const POOL_MAX_AGE_MS = 45 * 60 * 1000;` in src/core/e2b.ts line 1849. The comment on the same line makes the relationship explicit: the sandbox timeout is one hour, so anything older than 45 minutes in the pool is considered stale and gets killed. The default pool target size is one (`process.env.VM_POOL_TARGET_SIZE || "1"` at line 1852), so the second concurrent prompt at any given moment usually pays a cold boot. The template is pre-baked and boots in about 2.5 seconds, so the cold start is small, but it is real.

Two thirty second timeouts, side by side at src/core/e2b.ts. The /initialize call uses `signal: AbortSignal.timeout(30_000)` (line 1184), and so does /session/new (line 1207). If either takes longer than 30 seconds, the route gives up, kills the sandbox, and surfaces an ACP-specific error. These are bridge-level limits, not model-level limits. Once initialize and session/new succeed, the prompt forwarding has the full remaining maxDuration budget to work with.

Sometimes, but not in the way you might expect. The chat route reads stop_reason from the ACP prompt_complete notification and passes it through as `send({ type: 'done', stopReason: ... })`. A stop reason of `end_turn` means the model finished cleanly; `tool_use` means it asked for a tool and the conversation continues; `max_tokens` means the response itself hit Anthropic's per-response token cap. For a one-shot UI build, max_tokens is rare because the agent splits work across tool calls. When it does happen, the page just gets the truncated text and the next user message can pick up where it stopped. That is the only model-side hard cap that ever shows up in a single turn.

Because they fire in nested scopes, and the smallest one always wins. In ascending order: TTFT watchdog at 15s, ACP initialize and session/new at 30s each, tab pause at 10 min, route timeout at 800s (~13 min), pool entry max age at 45 min, sandbox lifetime at 1 hour. If you understand the hierarchy you can predict exactly what will go wrong: a prompt that times out at exactly 15 seconds is a wedged ACP subprocess, not a slow model. A 504 around the 13 minute mark is the route timeout, not the sandbox. A fresh-looking sandbox after a long lunch is the pool serving you a different pre-warmed sandbox, not your original one.