选择托管 agent runtime 前，先看空闲时会发生什么

Disclosure: I work on Gobare, one of the three runtimes below. To keep that from mattering, I quote the other two instead of describing them, and there is a section on where each of us loses, Gobare included. All quotes are from public docs, checked 27 September 2026. Misha. I read the sandbox docs of three hosted agent runtimes side by side, ours included. In a 30-second demo they look the same. The agent writes code, runs it, shows a result. The difference is one question the demo never asks: After the agent stops typing, does its machine still exist? Perplexity, OpenAI and Gobare give three different answers. None of them is wrong. They are building different things. But if you pick one without checking, you find out an hour into a job, at the step where the work was supposed to land. This post is the check I wish I had done first. First, be clear which OpenAI product you mean OpenAI ships two things with similar names. They are not layers of each other. The Agents SDK is open source and runs in your process. You own the loop. Other models work through LiteLLM (Python) or the AI SDK adapter (TypeScript). The Agents API is hosted. OpenAI runs the loop, and it is built around OpenAI models. So "can I use Claude with OpenAI's agents?" has two answers. In the SDK, yes. In the hosted Agents API, the one that gives you a sandbox, non-OpenAI models are on a second-class path. Everything below is about hosted runtimes: the ones that give you a machine. Three answers, in their own words Perplexity, on their sandbox tool: "Multiple executions in a single response share the same container: files written and packages installed by an earlier step are still there for a later one." Between responses, nothing is promised. That is the right design for an answer engine that computes. If you want an answer, paying to keep a machine alive afterwards is waste. OpenAI, on hosted sandboxes: "If activity and keep-alives stop for an hour, the sandbox can be deleted." Files you write to /workspace/outputs become immutable artifacts that "remain downloadable after the sandbox expires." The rest of the workspace does not survive. Clean contract: the sandbox is a place to do work, not to keep it. Gobare, on limits: "A workspace is also paused after five minutes with nothing happening, and woken by the next thing you send." Before the machine is reclaimed, the workspace files are snapshotted. It is best-effort. Git history, installed dependencies and running processes are not in the snapshot, and a workspace over 300MB is skipped. Side by side: Perplexity OpenAI hosted Gobare Machine lives for One response Until an hour with no activity or keep-alives Paused after five idle minutes, woken by your next message What survives Nothing promised between responses Files in /workspace/outputs, as artifacts Workspace files, best-effort snapshot What doesn't The container The rest of the workspace Git history, installed deps, running processes; workspaces over 300MB Three workloads where the answer decides things These are not failures of a bad runtime. They are where a correct runtime, picked for the wrong shape of work, gives you a system you cannot finish. A job longer than the idle window. Say a 40-minute refactor across several turns, with gaps while your dispatcher does something else. On a per-request container each response starts clean, so this can't be expressed. On a session sandbox it works, if you know exactly what "idle" means to your provider. A task that stops to ask a human. Approval mid-run means the machine waits, maybe for hours. Whether that wait is free, billed or impossible depends on how the runtime treats an idle machine. An agent that serves something. If the agent starts a preview server, the machine has to exist when the visitor arrives. That can be long after the agent stopped writing code. If the sandbox goes when execution ends, the preview URL goes with it. The container has a public price Perplexity publishes a price for the container itself, on their pricing page: "$0.03 per session (≤20-min billing window)" That is roughly $0.09 an hour for a managed container. It is the clearest public anchor I found for what hosted agent compute costs. It also explains the product. Perplexity's money is in the search index. For them, the runtime does not need to be profitable, and that sets the floor for everyone else. Where each one loses Perplexity: no session state across responses. If work has to survive a response boundary, you build that yourself on previous_response_id. OpenAI hosted: an hour of quiet and the working tree is gone. Only what you published to /workspace/outputs stays. Non-OpenAI models are second-class on the hosted path. OpenAI self-hosted: you own the lifecycle, so you also own its outages. With Daytona as the provider you must set auto_stop_interval=0, or the sandbox stops mid-agent. Gobare: Single sandbox provider (E2B). No bring-your-own-compute. That is real lock-in, and the fairest criticism of us here. A workspace is reclaimed two hours of active time after it starts. Paused time doesn't count, but a turn still running at that point fails. No model fallback chain. Perplexity tries up to five models; we have nothing equivalent. Saved agents are not versioned. No search index. Questions to ask any runtime's docs Take this list to whichever runtime you are evaluating. Every item comes from a place where these three differ. Lifetime Within one response or turn, do executions share a container? Is anything promised between responses? How long can the machine sit idle before it is paused or deleted? What counts as activity? On self-hosted compute, does the provider's idle tracking see the agent's connection, or do I have to disable auto-stop? Is there a hard cap on session lifetime, and what happens to a turn that is running when it hits? State What survives the machine: nothing, an outputs folder, or the whole workspace? What is excluded? Git history, installed dependencies, running processes, anything over a size limit? Workload fit Can the machine wait hours for a human? Is that wait free, billed or impossible? Can something the agent serves stay reachable after it stops generating? Control Who runs the agent loop, me or the vendor? Which models are first-class on the hosted path? Can I bring my own compute? Is there a model fallback when a provider goes down? Are saved agent configurations versioned? Is there a published price for the container itself? The one question that sorts the rest Not "which runtime is best." Ask: After my agent stops typing, do I still need the machine? If no, a per-request container is the honest choice, and you shouldn't pay for more. Perplexity's model is the clean version of that. If yes, you are choosing between owning the compute yourself and having someone manage its state for you. Both are defensible. Not knowing which one you picked is not. Full version with every source link: gobare.dev/blog/agent-runtimes-disagree-on-what-a-session-is If you have run agents in production: which of these questions did you only learn to ask after something broke?