Before you pick a hosted agent runtime, check what happens at idle

When evaluating hosted agent runtimes, it is crucial to understand what happens when the machine is idle. Perplexity, OpenAI, and Gobare each have different approaches to this question, which can significantly impact the usability of the runtime for certain types of work.

Perplexity maintains a single container for multiple executions within a single response. Any files written and packages installed in earlier steps remain available for later steps. However, between responses, nothing is guaranteed. If there is no activity or keep-alives for an hour, the sandbox can be deleted. The files written to `/workspace/outputs` become immutable artifacts and remain downloadable after the sandbox expires, while the rest of the workspace does not survive.

This means that only the specific files in `/workspace/outputs` are preserved, and the container itself is not retained after inactivity.

OpenAI's hosted sandboxes work differently. If there is no activity and keep-alives stop for an hour, the sandbox can be deleted. Files written to `/workspace/outputs` become immutable artifacts that remain downloadable after the sandbox expires. However, the rest of the workspace does not survive. This provides a clearer contract: the sandbox is a place to do work, not to keep it.

The machine is reclaimed after five minutes of idle time, and any workspace files are snapshotted before the machine is reclaimed. This snapshot includes the workspace files, but excludes Git history, installed dependencies, and running processes. Turn-based work that requires the machine to exist for an extended period may be affected by this idle timeout.

Gobare takes a middle ground. A workspace is paused after five minutes of idle time and is woken up by the next message sent by the user. Before the machine is reclaimed, the workspace files are snapshotted, but Git history, installed dependencies, and running processes are not included in the snapshot. Workspaces over 300MB are skipped. This approach provides a best-effort snapshot of the workspace files, but does not guarantee the preservation of all workspace artifacts.

These differences in runtime behavior can have significant implications for the types of work that can be performed. A job that requires multiple turns and idle periods may be limited by the idle timeout of the runtime. For example, a 40-minute refactor across several turns with gaps in activity may not be feasible on a runtime that deletes the sandbox after an hour of inactivity.

Similarly, an agent that serves a preview server that needs to exist after the agent has finished writing code may encounter issues if the runtime deletes the sandbox before the visitor can access the preview URL.

In terms of pricing, Perplexity publishes a clear price for the container itself: $0.03 per session (≤20-minute billing window), which translates to roughly $0.09 an hour for a managed container. This pricing model indicates that Perplexity's focus is on the search index, and the runtime itself may not need to be profitable. OpenAI's hosted sandboxes have a similar pricing model, while Gobare's pricing is not explicitly stated in the source material.

This price difference may be a factor in choosing a runtime, depending on the specific needs and budget of the project.

When evaluating hosted agent runtimes, it is essential to ask the following questions to understand how each runtime handles idle time and workspace preservation:

* Within one response or turn, do executions share a container? If not, are there any promises about preserving state between responses?

* How long can the machine sit idle before it is paused or deleted? Is this time measured only when there is no activity, or does it include time spent on keep-alives or other interactions?

* What counts as activity? Does the provider's idle tracking mechanism recognize the agent's connection, or is additional configuration required to disable auto-stop?

* On self-hosted compute, does the provider's idle tracking see the agent's connection, or is it necessary to disable auto-stop to maintain control over the machine's lifecycle?

* Is there a hard cap on session lifetime, and what happens to a turn that is running when it hits this cap?

* What survives the machine: nothing, an outputs folder, or the whole workspace? What is excluded from the snapshot?

* For self-hosted compute, does the provider's idle tracking see the agent's connection, or must it be disabled manually to prevent unexpected machine reclamation?

By considering these factors and understanding how each runtime handles idle time and workspace preservation, you can make a more informed decision about which runtime is best suited for your specific use case.