AI Sandbox for Agents: Runtime, State, and Cost

Do not index

An AI sandbox is an isolated environment where an agent can run code, install dependencies, and work with files under limits you control. Choose one by the workload it must run, the access it needs, and what you pay while it waits. Agent37 offers standard gVisor sandboxes and full Linux VMs, so you can choose the runtime without treating every task as a full virtual machine.

The buying mistake is starting with a provider's headline price or startup claim. First decide whether you need a disposable code runner, a persistent agent workspace, or a machine that can run Docker. Those are different jobs, even when the products share the word sandbox.

This guide covers hosted execution infrastructure for developers. It does not cover enterprise AI experimentation portals or regulatory testing programs, which also use the term AI sandbox.

What an AI sandbox actually provides

Your model decides what to do. Your application coordinates the work. The sandbox supplies the computer on which that work executes.

Consider an agent asked to fix a failing test. It needs a repository, a language runtime, permission to change files, and a way to run the test suite. It does not automatically need your production database credentials, another customer's workspace, or administrative access to your cloud account.

A useful sandbox service lets your application provision that environment, send commands, collect results, and control its lifetime. An agent sandbox can remain available for repeated work or disappear after a single task. Persistence is a product choice, not something implied by the name.

The execution boundary is also separate from the model. You can call a model from a trusted service and send only generated code into the sandbox. Alternatively, you can run an agent harness inside it. In the second design, the harness needs access to its model endpoint and any approved tools.

This separation makes a provider easier to evaluate. Ask which part it supplies: execution infrastructure, an agent framework, model inference, or a bundle. Avoid paying for a bundle you do not need.

Choose the workload before the provider

Write down the smallest real task your agent must complete. Include its dependencies and the files you expect back. Then use that task to narrow the runtime.

Your workload	What to check first	Common mismatch
Run generated Python against an uploaded file	Supported packages, file transfer, output collection, execution limits	Buying a persistent desktop for a short calculation
Make code changes across several sessions	Durable workspace, dependency retention, restart behavior	Assuming an expired session keeps the repository
Build and test with Docker Compose	Working Docker daemon, container networking, disk capacity	Choosing a runtime that cannot start Docker
Run a browser workflow	Browser availability, required libraries, networking, artifact capture	Assuming every agent template includes a browser
Operate a long background worker	Runtime limits, health checks, restart policy, sleep configuration	Letting an inactivity rule suspend useful work

Do not replace this exercise with a list of advertised integrations. A provider can support your programming language while missing an operating-system feature your dependency needs.

Bring the real dependency set into a small evaluation. If your workflow builds native packages, accesses a device, or starts additional services, test those operations early. A successful hello-world command establishes very little about the full task.

Containers, gVisor, and VMs solve different problems

Ordinary Linux containers isolate processes and resources while sharing the host kernel. Their suitability depends on configuration and the trust you place in the workload.

gVisor adds an application kernel between application system calls and the host. It is a distinct approach with its own compatibility and overhead tradeoffs. Calling it an ordinary container misses that extra boundary; calling it a full Linux VM misses the difference too.

A virtual machine has its own guest kernel. A microVM uses a smaller virtualization device model for focused workloads. Firecracker's documentation describes this approach, but the technology alone does not tell you which features a hosted provider exposes.

The practical question is which runtime runs your software with the controls you require. At Agent37, standard gVisor instances cannot run a Docker daemon. The full VM option supports Docker and Compose, and has a different compute rate. Its entrypoint is not a systemd init environment, so check that assumption before moving an existing server setup.

For a deeper architecture comparison, see microVMs versus containers. A runtime label helps you shortlist. A representative workload tells you whether the shortlist works.

Decide what must survive between tasks

An AI agent sandbox needs a clear state model. Otherwise, a successful first demo can turn into missing files after the first restart.

Separate three kinds of state: files you need to keep, processes that are currently running, and credentials the task can use. They do not necessarily have the same lifetime.

Ask what happens after stopping, sleeping, updating an image, restoring a backup, and deleting the environment. A persistent disk does not guarantee a running process survives. A snapshot may have retention limits or separate charges. Deletion should happen only after the application has collected everything it needs.

Agent37 documents these distinctions in its instance lifecycle reference. Files survive ordinary lifecycle changes, while image updates reset the operating-system layer outside the documented persistent data directory. Put durable work in that directory and keep a reproducible setup for dependencies.

Choose reuse deliberately. One workspace per customer or project can avoid repeated setup. One fresh environment per task can simplify cleanup and separation. Reusing the same workspace across unrelated customers creates a harder data-handling problem than saving a few seconds of setup is likely to justify.

Your evaluation should include a restart halfway through a task. Confirm that the application can find the workspace, recover its task record, and resume from a known step.

Keep permissions separate from the runtime choice

Isolation does not cancel permissions you intentionally grant. Code inside a VM can still call a destructive API if it has a valid token and network access to that API.

Keep infrastructure management credentials in the trusted application. Give the agent only the files and service permissions its task requires. Make external actions such as publishing, deploying, or changing customer data explicit application decisions.

Network defaults deserve a direct check. Agent37 instances can reach the public internet by default. Its network access controls let you deny outbound access or allow specified IPv4 addresses and ranges. Its managed model and tool services are unavailable under either restricted policy. Keep model orchestration outside the restricted worker, or verify a separately authorized endpoint and its required connectivity.

For an offline code runner, the application can call the model outside the sandbox. For an agent harness running inside it, provide only the connectivity the harness actually needs. Neither design makes arbitrary outputs trustworthy: validate returned files, structured results, and proposed actions before using them elsewhere.

Create a small acceptance checklist. The sandbox should run the approved task, fail when attempting a prohibited operation, and leave an audit trail useful enough to explain either result. Check behavior, not just the settings screen.

Compare the total cost of your execution pattern

The useful price is the cost of your workload over its lifetime. Keep compute, retained storage, model tokens, and other services separate.

Agent37's published standard rates are $0.80 per vCPU, $0.70 per GB of RAM, and $0.09 per GB of disk per 730-hour month, metered by the minute. Standard compute uses shared host resources. VM compute is 2.5 times the standard compute rate; disk uses the same rate.

Here is an illustrative estimate for one 2 vCPU, 4 GB RAM instance with 4 GB of disk. Disk remains allocated for all 730 hours in each scenario. These are arithmetic examples at the published rates, not measured throughput or customer invoices.

Runtime and schedule	Compute	Retained disk	Total infrastructure estimate
Standard, running all 730 hours	$4.40	$0.36	$4.76
Standard, running 30 hours and stopped or asleep otherwise	$0.18	$0.36	$0.54
Full VM, running all 730 hours	$11.00	$0.36	$11.36
Full VM, running 30 hours and stopped or asleep otherwise	$0.45	$0.36	$0.81

Models and tools are extra. These shapes explicitly use 4 GB of disk; a template's default allocation may differ. For example, Agent37's Ubuntu VM defaults to 12 GB unless you specify otherwise.

When comparing providers, include required subscriptions, resource minimums, free allowances, storage retention, and the basis of CPU billing. A service that bills consumed CPU can behave differently from one that bills allocated compute while running. A free allowance can also win for a small workload. Compare the same job, not just two hourly numbers.

Make idle time an explicit lifecycle decision

An agent waiting for a model response is still running unless your system or provider suspends it. Low CPU usage alone does not make allocated compute free.

At Agent37, compute stops billing when the instance stops or sleeps, while retained disk continues billing. Auto-sleep is opt-in. Its inactivity signal includes traffic through instance URLs and exec activity; it is not a general measure of whether your background business task has finished.

For a request-driven agent, an inactivity window can reduce compute hours between visits. For a long silent background job, configure that window to fit the job or control the lifecycle yourself. Test a quiet period that resembles production instead of assuming a continuously open connection counts as activity.

Also plan for a wake that starts fresh. A restored checkpoint may retain memory, but durable work should live on disk and the application should tolerate a cold start.

Decide who owns cleanup. After the result is safely stored, your application should stop, sleep, retain, or delete the instance according to a clear policy. Otherwise, successful jobs can leave a growing collection of running computers behind them.

Evaluate an agent sandbox with one complete workflow

Choose a task with an observable result: update a small repository, run its checks, and return a patch plus logs. Use synthetic or non-sensitive data for the first evaluation.

Record the environment shape and image. Capture setup time separately from execution time, then include dependency downloads, retries, output transfer, and the idle interval before cleanup. A provider's advertised creation time is only one part of the experience your user sees.

Run the same task after a restart. Try the expected failure cases: a missing dependency, a command that fails, an interrupted connection, and an output larger than your application allows. Your system needs to distinguish a tool error from a completed task.

Then estimate the monthly pattern. How many jobs run at once? How long does each environment stay allocated? How much disk remains after the jobs finish? Which model or external tool generates the largest separate charge?

Choose Agent37's standard runtime when your workload fits its compatibility and shared-resource model. Choose its VM runtime when you need the guest kernel and Docker support. If a competing service's SDK, free allowance, regional coverage, or execution model better fits your requirements, include that in the decision.

You can explore Agent37 sandboxes and follow the instance documentation to run that evaluation. Start with the smallest representative job, then expand after its behavior and bill are understood.

Frequently asked questions

Is an AI sandbox the same as an agent sandbox?

In hosted code-execution discussions, the terms commonly describe the same kind of environment. Check the actual product: some AI sandbox offerings are experimentation portals rather than computers your agent can control.

Does the model have to run inside the sandbox?

No. Your application can call a hosted model and execute its generated code in a separate environment. An agent harness can also run inside the sandbox while calling an external model endpoint.

Should every agent use a full VM?

Choose based on workload compatibility and isolation requirements. A full VM is useful when you need its kernel capabilities. A compatible standard sandbox may be enough for file operations, scripts, and supported agent harnesses.

Is a sleeping sandbox free?

Check the provider's billing rules. At Agent37, sleep pauses compute charges, but retained disk continues billing. Model and tool charges are separate from the infrastructure estimate.

AI Sandbox: Choose the Right Runtime for Your Agent