The limits of agent demos, written in the source of a live agent product

Gate one. The 15 second time-to-first-token watchdog.

When a real user submits a prompt and waits, the most common failure is not a wrong answer, it is no answer at all. The ACP subprocess inside the sandbox accepts the request, then returns nothing. From the browser's perspective the stream is alive but idle. The user is looking at a blinking cursor.

At src/app/api/chat/route.ts:539, a setTimeout fires 15 seconds after the request begins. If no notification has come back by then, the code evicts the session, fires the chat_ttft_timeout telemetry event, and sends the user this:

The cost: a user who would have gotten a response on the 18th second sees the error on the 15th. The win: a user staring at a wedged box is told, and the next request boots a fresh VM. A demo cuts this entire window. The live product has to pick a number, and 15 is what the code currently says.

Gate two. The 800 second per-turn ceiling.

At line 25 of the same file, export const maxDuration = 800 tells the platform that this route is allowed at most 13 minutes 20 seconds of wall time per request. After that, the underlying runtime kills the response. The agent does not get to finish.

13 minutes is long for a chat turn and short for a fully autonomous run. The shape of the ceiling tells you the shape of the product: this is a synchronous chat turn, not a fire-and- forget worker. Anything that needs to run longer (a scheduled build, a multi-step refactor, a Playwright test suite) belongs on the scheduler MCP that ships in the VM at /opt/scheduler- mcp.js, where the timeout structure is different.

Agent demos love to imply unbounded runs. The trick is they usually run on a different transport (no HTTP request waiting), or they run for two minutes and edit the rest. Live products that hold a synchronous connection open need a number.

Gate three. The classified-error UI.

The expensive part of a live agent product is not the happy path, it is the error path. When the SDK throws, the live product has to figure out which kind of failure happened so the next action makes sense. mk0r's answer is a discriminated union at line 48:

type ErrorKind =
  | "credit_exhausted"
  | "auth_required"
  | "invalid_request"
  | "image_error"
  | "stale_session"
  | "generic";

Each kind is a separate branch in the stream handler (route.ts:585 to 657). credit_exhausted forwards the SDK's reset-time message so the user can see when service resumes. auth_required tells the UI to re-authenticate, not retry the same prompt. image_error surfaces inline instead of being swallowed by a generic toast. stale_session is the only kind where retry helps, and it retries exactly once, only when no text has streamed yet (route.ts:621).

A demo is allowed to throw all five of those into a single "something went wrong" toast, because the demo author will rerun the take. A live product cannot, because the user has nowhere to rerun from. The discriminated union is the cost of being honest about which failure happened.

Gate four. The 1 hour sandbox TTL.

The agent does not live in your browser, it lives in an E2B sandbox. That sandbox is configured to pause itself one hour after the last activity:

// src/core/e2b.ts:33
const E2B_TIMEOUT_MS = 3_600_000; // 1 hour

A demo finishes in two minutes, so this never matters. A real user who walks away for lunch comes back to a paused VM. There is a reload path that brings the git history back (the timeline is not destroyed), but the live HMR session is. The reload UI, the resume code, and the "paused" visual state all had to be written. None of that exists in any demo clip.

The honest version of "your agent has its own VM" is "your agent has its own VM until you stop using it, at which point we pause it to keep the unit economics sane." You can debate the number. You cannot avoid having one.

Gate five. The 6 turn anonymous cap.

No signup means no identity to throttle. So the only abuse gate left on the anonymous loop is a per-turn counter:

// src/app/api/chat/route.ts:23
const ANON_TURN_LIMIT = 6;

On the 7th anonymous prompt, the route returns 403 sign_in_required. A demo never hits this because the demo author is logged in. The live anonymous user does, and a sign- in modal pops up where the next response would have streamed. That modal does not exist in any demo of an "account- less" agent product. It exists in the live one because the live one had to pick between "no signup ever" and "the cluster gets eaten by a single tab." It picked the cap.

The same flow, demo-side and live-side

Put the five gates on one axis and the demo path on the other, and the gap is mechanical, not philosophical:

The right column is not bragging. It is the bill the left column never paid. Every row is a place where the live product had to write either a watchdog, a classifier, a recovery path, or a cap. The demo author chose which rows to render and which to cut. The live product renders all of them, every time.

What the failure path actually looks like, top to bottom

Reading the gates as a sequence is more useful than reading them as a list, because in production they fire in a partial order. The TTFT watchdog can win the race against prompt_error. The stale_session retry is allowed to interrupt the stream, but only once. The TTL only fires when the user has gone idle. Here is one possible run, with the gate that fires at each step:

The demo of the same turn would be three frames: prompt, loading spinner, finished preview. Every event labelled "gate" would be either invisible or cut entirely.

How to read a demo from someone else

The point is not to dunk on agent demos. The point is to give you a checklist. The next time someone shows you an agent doing something impressive, walk down the five gates and ask where they live in the product:

1. What does the product do when the first token does not arrive in time? Is there a watchdog, and what is its value? If the demo cut to mid-response, the TTFT could be any number.
2. What is the ceiling on a single agent turn? If the answer is "unbounded," the agent can hang. If it is "way shorter than the demo," the demo is on a different transport.
3. What does the error UI look like when the SDK throws? A product without a discriminated error type is going to show you the same toast for billing, auth, and image failures, and you will retry the wrong thing every time.
4. How long does the underlying compute live after the turn ends? A demo that runs for two minutes hides anything past that.
5. Is anything gated on an account? An anonymous demo and a logged-in demo are two different products. The first is the on-ramp, the second is the workshop.

If you can answer all five from a public artifact (a video, a tweet, a sandbox), the team has thought about it. If you cannot, you do not actually know what you are looking at. That is fine, you can ask. The honest teams will tell you their numbers.

The summary

The limits of agent demos are not about the agent. They are about the gap between a take you can retry and a turn the user is watching live. mk0r's five gates (TTFT watchdog, maxDuration ceiling, classified errors, sandbox TTL, anon cap) are the cost of closing that gap. The values are debatable. The fact that they exist as named constants in the source is not.

Open mk0r.com on a phone. Send a prompt. If you have a slow network, you may see the TTFT error. If you stay anonymous and keep going, you will hit the turn cap. If you walk away for an hour and come back, you will see the paused sandbox. None of those would survive editing a demo. All of them are the live product being honest about what it can and cannot do.