Building Maximally Efficient Cloud Environments for Long-Horizon Agents | Sail Research<br>We've raised $80M funding, with our seed led by Sequoia and Series A led by Kleiner Perkins!→← BlogBuilding Maximally Efficient Cloud Environments for Long-Horizon Agents<br>NBCC<br>Nirvik Baruah · Charley Cunningham·Jul 14 2026·8 min read

One of the most compelling aspects of Sailboxes, our cloud environments for long-horizon agents, is our pricing model: we are both significantly cheaper than other providers and only charge you for the exact resources you consume every second. Given that long-horizon agents can live for weeks and spend most of their time dormant, charging only for active resource usage makes these workflows scalable and sustainable.<br>Our pricing model is made possible by the fact that Sailboxes are able to live-migrate to new hosts on command: we can move an entire VM (including all of its open sockets) to a new host in seconds without agents being aware they experienced any downtime. Live migrations are an extremely powerful tool that lets us run Sailboxes on ephemeral compute and periodically load-balance to ensure balanced resource utilization across our fleet.<br>Enabling live migrations at scale, however, is a daunting problem. Sailboxes provide agents with full VMs and we need to make any arbitrary command that might run be seamlessly migrateable. Sailboxes are also completely elastic: workloads can use hundreds of GB of memory if necessary and we need to transport all this data in seconds. We built up three core pieces of infrastructure to make this possible: a robust network proxy, user-space page faulting over a P2P network, and automatic memory ballooning.<br>Network Proxying<br>The first issue you’ll encounter when attempting a live migration is the fact that open network connections simply break. Most VM technologies let you snapshot memory and filesystem state natively but none provide support at the network layer. You can imagine why this is a hard problem: suppose you are sending a stream of bytes to a VM on one host, and then it suddenly moves to an entirely different host with a different IP address; from your perspective, the VM simply vanished and your connection is now broken.<br>The naive implementation of VM migration breaks any open network connections.We wanted any existing application to simply work inside a Sailbox even as it migrates, including more complex networking workflows such as SSH. To support this, every Sailbox uses an L4 network proxy that intercepts all connections at the TCP packet level. Instead of external clients connecting directly to the Sailbox, they instead communicate with a persistent network proxy. The network proxy in turn connects to a sidecar process that exists inside the VM and shuttles bytes between these two connections. The guest finally receives bytes from the sidecar process. From a guest’s perspective, their connections originate from their in-VM sidecar which always lives in the same location regardless of the physical host; from an external client’s perspective, their connections terminate at our network proxy service which also stays in a fixed location. This architecture enables seamless migrations of a client’s network connections.<br>Our network proxy allows both clients and servers to maintain their connections without being aware of a migration taking place.Another responsibility of the network proxy service is spooling. Since VMs may be offline for a few seconds while a migration occurs, the network proxy caches the last few minutes of packets so that they can be relayed when the VM is back online.<br>While this architecture adds an additional network hop, we find that the performance overhead is minimal and can be alleviated through horizontal scaling. Additionally, it gives us several other features for free that are important for any agent cloud environment: we can easily maintain whitelists of the external servers an agent in a Sailbox can connect to, we can automatically inject credentials on network egress, and we can easily resume Sailboxes on network ingress.<br>P2P Migrations<br>Now that we have a way to migrate the networking state of Sailboxes, the next question becomes how do we perform the migration efficiently. We initially took the most naive approach to migrations: serialize the entire VM on the original host, upload its state to S3, download it on the new host, and then resume from there. However, this was prohibitively slow, especially given the fact that our VMs allow users to store hundreds of GB of memory if desired.<br>The fix for this was to build a custom page fault handler with userfaultfd, a Linux API for handling missing memory pages. At migration time, the original host serializes the VM state to its local disk and asynchronously copies it to S3. At the same time, the new host will start the VM with some minimal state. Whenever the new host needs to read a page of memory that is not loaded in yet, it will first contact the original host...