Sailboxes: 6 Powerful Facts About Persistent Agent Compute

Every conversation about AI agents eventually hits the same wall, and it is not the model. It is the computer the agent works on. A chat session lasts minutes; an agent task can last hours, and a research or coding agent that runs overnight needs a machine that is still there in the morning, with its files, its installed packages and its half-finished build intact.

That is the problem Sailboxes addresses, and it is the same gap that makes AI sandboxes the least glamorous and most consequential layer of the agent stack. Sail Research, a startup selling inference for open models, has built a sandbox product around one specific claim: that the environment for long-running agents should be a full computer with no runtime limit, billed per second of actual use. The company has also opened a startup program offering up to $10,000 in credits across both products. This article explains what the product actually is, why the billing model matters more than the feature list, what the credits do and do not cover, and how to judge infrastructure like this before committing a roadmap to it.

What Sailboxes actually are

The product is a persistent Linux virtual machine, described by the company as purpose-built for long-horizon agents. In a market full of AI sandboxes that behave like mayfly, this one is designed to keep living. The Sailboxes specification list is unusually concrete: a full, kernel-isolated VM with root access, independent disks, persistent state, Docker support and local NVMe storage examples.

Three properties follow from that design and matter more than the individual bullets.

Sailboxes are VMs, not containers. Kernel isolation is the distinction that lets a security team approve running untrusted agent-generated code. A container shares the host kernel, which is fine for trusted workloads and a poor boundary for an agent that may execute arbitrary instructions it wrote itself. This is the same argument that has shaped the sandbox conversation across the agent tooling world, from the workspace products that isolate parallel agents in separate worktrees to the containment guidance in vendor security advisories.

Sailboxes lifetimes are uncapped. There is no maximum runtime. An agent can live for days or weeks, and the company's wording goes further, describing agents that can run indefinitely without losing state. For anyone who has watched a long job die at a sandbox timeout and had to reconstruct its working directory from logs, that is the headline feature.

Sailboxes state is an object you can manipulate. Pause, resume and fork all apply to sandbox state, in-flight work survives, and open connections survive for up to ten minutes. Forking is the quietly interesting one: an agent that has reached a promising state can be cloned, and two branches can explore different continuations from the same starting point. That is a capability agent researchers have wanted since the first tree-search experiments.

Sailboxes tooling is a CLI and TUI plus SDKs in Python, TypeScript and Rust, which covers the languages most agent frameworks are written in.

Why long-running agents break ordinary sandboxes

The failure mode is worth spelling out, because it explains why a product like this exists at all.

A conventional serverless sandbox is built for short, stateless execution. It boots fast, runs a function, returns a result and disappears. That model fits code interpreters and one-shot evaluations. It fits an agent badly, because an agent's work is cumulative: it installs a dependency, writes a file, runs a test, reads the failure, patches the file, runs the test again. Every step depends on the previous one's side effects.

When the sandbox is ephemeral, the agent must rebuild that context constantly, either by replaying setup commands or by serialising state into something external. Both approaches consume tokens, time and reliability. A long-horizon agent on an ephemeral sandbox spends a meaningful fraction of its budget re-establishing a world it already built once.

The Sailboxes design inverts that by making the machine the durable artifact. The agent does not reconstruct context because the context never left. That single Sailboxes property is what makes multi-day agent products tractable, and it is why the company's customer examples are mostly research and evaluation platforms rather than chatbots.

The billing model is the real feature

Most sandbox pricing is charged by wall-clock time or by provisioned capacity. Both are wrong for agents, and the reason is that agents are idle most of the time.

A long-horizon agent on Sailboxes spends its hours waiting: on an inference call, on a build, on a test suite, on a rate limit, on a human approval. If you pay for provisioned time, you pay for all of that waiting at full rate. If you pay for wall-clock, same problem.

Sailboxes bills per second for the CPU, memory and disk actually consumed by each box, and adds a mechanism the company calls sleeping while thinking: the sandbox automatically sleeps while an agent waits on a Sail inference call. Because sleeping consumes far less than running, the effective cost of a waiting agent collapses.

The company claims the Sailboxes model lands more than 70 percent below other providers. That figure is a vendor claim and no methodology or comparison set is published alongside it, so treat it as a directional signal rather than a measured fact. But the underlying argument is sound and easy to reason about: if an agent is idle 80 percent of the time, per-second billing of active resources saves most of the bill regardless of the exact percentage a vendor advertises.

One Sailboxes boundary is worth knowing. The automatic sleep is tied to Sail inference calls, so it covers the waiting that happens inside that pairing. An agent blocked on a third-party API, a long compile, or a human review will not trigger the same optimisation. That is a structural Sailboxes limit, not a flaw, and it argues for pairing the sandbox with the inference provider the sleep behaviour was built for.

What the startup program actually offers

The Sailboxes startup program is straightforward in structure and less generous in practice than the headline suggests, which is normal for this kind of offer and worth understanding before applying.

The headline is up to $10,000 in free credits, drawn from a single balance shared between inference and Sailboxes. That shared balance is the most useful design decision in the offer, because it means a team does not have to guess in advance whether it will spend more on tokens or on compute. It also means a credit grant is genuinely usable end to end: a research agent that needs both open-model inference and a persistent machine can be built and run entirely on the grant.

Support is a dedicated shared Slack channel with the company's team, plus a swag package and access to coworking and events, the last subject to approval. Eligibility covers bootstrapped and funded startups, and every application is reviewed individually.

The important qualifier is in the company's own FAQ: the program offers up to $10,000, applying does not guarantee approval, and awards are reviewed individually rather than granted at a fixed amount. A founder reading a headline about $10,000 should plan on the possibility of a smaller allocation. The application itself is short, and the strongest entries will describe the workload concretely, since that is what the review is assessing.

Worth noting for planning: the standard self-serve plan includes $5 in monthly credits, and the paid tier is $250 a month with $100 in included credits plus $150 in the first month, up to 5,000 concurrent Sailboxes and waived creation fees. So the startup credits are a runway extension on a product that is otherwise priced from free upward, not a gate in front of it.

The other half: completion windows

The startup program matters because inference and sandboxes are designed to be used together, and the inference side has its own unusual pricing idea.

Sail sells access to open models, including Kimi-K2.6, GLM-5.2, gpt-oss-120b, DeepSeek V4 Pro, Nemotron 3 Super 120B and Gemma 4 31B IT, through APIs that are compatible with OpenAI's and Anthropic's formats. The interesting part is what the company calls a completion window, set per request: asap for immediate responses at the baseline price, priority at roughly a minute for 30 to 50 percent lower cost, standard at roughly five minutes for 45 to 65 percent lower, and flex at best-effort timing for 60 to 80 percent lower.

In plain terms, Sail is selling the same intelligence at four prices and letting the caller choose how much latency to trade away. For a synchronous chat product, that is irrelevant; users will not wait five minutes. For a background agent running a thousand evaluation rollouts overnight, it is close to free money, because nobody is watching and the deadline is tomorrow morning.

That pairing, cheap asynchronous inference plus a sandbox that sleeps while it waits, is the coherent product thesis. The company describes itself as aiming at long-horizon agents rather than at being the fastest provider, and its pricing structure matches the claim. Whether the underlying efficiency claims hold at a given workload is a question each buyer has to test.

How to evaluate agent infrastructure like this

For teams deciding whether to build on Sailboxes, or on any of the comparable AI sandboxes now appearing, six questions separate a durable choice from a demo.

Is it a VM or a container? If agent-generated code runs inside it, kernel isolation matters. Ask directly, and get the answer in writing.

What is the actual runtime limit? Uncapped is a strong claim. Confirm what happens to a sandbox that sits idle for a week, and whether state survives an infrastructure event on the provider's side.

How is billing measured? Most AI sandboxes charge by provisioned capacity or wall-clock time. Per-second active CPU, memory and disk is a very different invoice. Ask for a worked example on a realistic workload rather than a per-hour headline.

What does sleep cost? If the sandbox sleeps while waiting on inference, what is the cost while asleep, and what latency does waking add? A cheap sleeping state that takes a minute to resume changes the economics for interactive agents.

Can state be forked and restored? This is the capability that unlocks parallel exploration, and it is also the capability that quietly fails under load. Test it before you depend on it.

Where does the data live? Region options, retention and compliance documentation determine whether a product is usable at all for regulated work. Sail advertises SOC 2 compliance and publishes a trust centre, and enterprise terms add HIPAA support with a signed agreement.

Those questions are the same ones this site has applied to inference economics generally, from the idle GPU capacity problem to the caching strategies that keep agent context cheap. The pattern is consistent: the bill for AI agents is dominated by waste, and the products that win are the ones that price the waste out. That is also the argument behind the parallel agent workspaces that keep separate tasks from colliding, and behind the harness economics that decide how much compute a single task deserves.

Who should actually use this

Not every agent product needs a persistent machine, and the distinction is worth drawing because it determines whether a startup credit grant is well spent or wasted on architecture that does not need it.

The clear fit is any product where the agent's work is cumulative and long. Research agents that run experiments overnight, evaluation platforms that execute thousands of rollouts against a shared environment, coding agents that build and test a repository over hours, and security tools that need a stable machine to probe. In each case the sandbox is not a utility call, it is the agent's office, and losing it means losing the work.

The unclear fit is a chat product with tool calls. If every request is independent and finishes in seconds, a persistent VM is over-provisioned, and the cheaper answer is a short-lived function or a managed code interpreter. Teams in this category should be honest about it rather than adopting durable sandboxes because the term sounds advanced.

The interesting middle case is the assistant that keeps context across days. An always-on agent with memory, a set of files and a schedule needs a machine that stays warm and a bill that stays small while it is idle. That is precisely the profile Sailboxes is priced for, and it is also the profile most consumer AI assistants will eventually have, which is why the product thesis is plausible beyond the research market it currently serves.

For a startup deciding, the practical test is a two-week pilot with one real workload rather than a synthetic benchmark. Run the same job on the incumbent sandbox and on Sailboxes, measure cost per completed task rather than cost per hour, and count the failures caused by state loss or runtime limits. That number, not the marketing page, is the one that belongs in the decision.

Where the numbers stop

• The “over 70 percent less than other providers” figure is Sail's own claim on its product page. No comparison set, methodology or benchmark is published alongside it, and this article does not independently verify it.
• The inference pricing claim of paying roughly half for tokens when waiting about a minute is likewise the company's own comparison against unnamed traditional providers.
• The startup program offers up to $10,000, but the company states that applications are reviewed individually and that approval and the maximum amount are not guaranteed. Nothing here should be read as a promise of a specific award.
• Sailboxes per-second rates for self-serve use are not published on the pages reviewed for this article, only the plan structure above them, so no cost estimate is given here.
• The automatic sleep behaviour is documented as applying while waiting on Sail inference calls, not to arbitrary third-party waits.
• Customer logos and quotes are the vendor's own marketing material. No independent performance testing of Sailboxes was available, and none was run for this article.
• SOC 2 compliance and the trust centre contents were not independently audited here; the claim is reported as the company states it.

FAQ

What are Sailboxes?

Sailboxes are persistent Linux virtual machines from Sail Research, designed for AI agents that run for hours or days. Each one is a full VM with root access, independent disks, Docker support and local NVMe storage, with no runtime cap, persistent state across pauses, and the ability to fork a sandbox to explore parallel continuations. Billing is per second for the CPU, memory and disk actually used, and a sandbox sleeps automatically while its agent waits on a Sail inference call.

How much does the startup program give, and who qualifies?

The program offers up to $10,000 in free credits, drawn from one balance shared between inference and Sailboxes, plus a dedicated Slack channel, swag and optional coworking. Bootstrapped and funded startups can apply, and every application is reviewed individually. The company is explicit that applying does not guarantee approval or the full amount, so treat the maximum as a ceiling rather than an entitlement.

How do completion windows change the price?

Sail lets each request specify a completion window instead of paying one flat rate. Immediate responses cost the baseline, roughly one-minute responses cost 30 to 50 percent less, roughly five-minute responses cost 45 to 65 percent less, and best-effort flex scheduling costs 60 to 80 percent less. The trade is latency, which is irrelevant for overnight batch work and decisive for chat, so the practical move is to set the window per job rather than per account.

The short version

Sailboxes are persistent VMs for agents that need a computer for days rather than seconds: full kernel isolation, root access, uncapped lifetimes, forkable state and per-second billing of resources actually consumed, with the sandbox sleeping while it waits on inference. Paired with Sail's completion windows, which trade latency for 30 to 80 percent lower token costs, the product is a coherent bet that long-horizon agents will be priced on waste rather than on capacity. The startup program adds up to $10,000 across both products, awarded case by case rather than automatically. The efficiency claims are the vendor's own and unverified, and the sleep optimisation is limited to Sail's own inference calls, but the underlying design argument is sound, and the six evaluation questions above are the ones worth asking before any agent roadmap depends on it.

Sources

• Sail Research, the Sailboxes product page covering VM isolation, uncapped lifetimes, fork and restore, per-second billing and plan structure: https://sailresearch.com/sailboxes
• Sail Research, the startup program page covering the credit offer, what is included, eligibility and the review process: https://sailresearch.com/startups
• Sail Research, the platform page describing open-model inference, OpenAI and Anthropic API compatibility and completion windows: https://sailresearch.com/