Archil Persistent Sandboxes

Archil released Persistent Sandboxes, a new compute option for executing long-running untrusted model-generated code, network services, or interactive development environments that connect to data on existing Archil disks. The sandboxes remain available across calls, can be paused with memory snapshotting or forked, and support preview URLs for public internet access. Available immediately for Archil customers in AWS regions.

Today, Archil is releasing Persistent Sandboxes https://docs.archil.com/compute/sandboxes/introduction . Persistent Sandboxes are the easiest way to execute long-running untrusted model-generated code, network services, or interactive development environments that connect to data on your existing Archil disks. Archil already offers Serverless Execution https://docs.archil.com/compute/serverless-execution for customers who want to give their agents a run bash that works on real Linux machines without needing to manage a sandbox. However, after working closely with some of the best teams building agentic products, we've identified that some workloads don't actually fit a one-off execution tool. For example, teams need a place to actually run their agent loop, start development servers with preview URLs, or keep expensive-to-start processes alive in memory. Persistent Sandboxes fill this gap with a familiar API for existing sandbox users, including the ability to specify an OCI base image, vCPU count, and memory. The sandbox remains available across calls, so that long-running processes remain running while the agent is working. If your agent stops or needs to pause, you can stop the sandbox and stop paying for compute without losing its files or installed dependencies. When used with an agent loop, Persistent Sandboxes stay alive in between turns, which means that it can follow the entire trajectory of long-running agents, but they can also be paused with memory snapshotting or forked https://docs.archil.com/compute/sandboxes/introduction forking-a-sandbox so that you can preserve known good states or explore multiple approaches in parallel without rebuilding the environment each time. If your agent produces something interactive, you can also generate preview URLs inside of the sandbox so that you can access network services from the public internet. For more complex tasks, Persistent Sandboxes can be combined with Archil disks and Serverless Execution. Teams often store agent context on an Archil disk and need that data to remain strongly consistent across several environments such as: - Humans accessing a website that uses the Archil S3 API https://docs.archil.com/protocols/s3-api - The agent's bash tool operates on the context with Archil Serverless Execution https://docs.archil.com/compute/serverless-execution - The agent loop can now run and mount the same disk inside a Persistent Sandbox https://docs.archil.com/compute/sandboxes/introduction Many of our customers are currently choosing to use Archil with an existing sandbox platform like E2B or Daytona, and this launch only strengthens our commitment to deliver Archil as an open, neutral storage platform for all sandbox providers. We continue to recommend using other sandbox providers for tasks that require hundreds of thousands of concurrent vCPUs, Windows or macOS tasks, or attached GPUs, but we're excited to deliver a simple primitive for Archil customers who "just" need a Linux box. Persistent Sandboxes are a powerful new way to run agents entirely inside of the Archil cloud, and they're available immediately for Archil customers in AWS regions. Get started now by generating an API key on the Archil console https://console.archil.com , or contacting our sales team mailto:sales@archil.com to get BYOC set up in your cloud in about an hour.