AI sandbox providers give agents an isolated environment for running generated code, testing changes, and working with files. Vercel Sandbox, E2B, Daytona, Modal, Cloudflare Sandboxes, Blaxel, and Fly.io Sprites support different execution and state requirements. Choose according to what your code needs to run and what must survive between sessions.
Vercel publishes this comparison and provides the first product listed. Providers are grouped by workload; the order doesn't rank performance or security.
Copy link to headingWhat should you compare in an AI sandbox provider?
Start with a representative task. Running a Python calculation once has different state requirements from returning to the same repository over several days. Notebook-style execution may also need to preserve variables and imported modules between code calls.
Evaluate the isolation boundary alongside the APIs your application will use. Providers can expose shell commands, a stateful interpreter, or methods for interacting with a remote workspace. These interfaces change how you send code, handle errors, and retrieve files.
Filesystem persistence keeps files, while memory preservation can retain interpreter variables and process state. Neither guarantees that a remote database connection remains usable after a pause. Test the lifecycle your workload needs and confirm exactly what each snapshot restores.
These workload recommendations reflect documented capabilities. Providers can serve several categories, so use the table to build a shortlist for your own task.
Copy link to heading1. Use Vercel Sandbox for isolated execution in your application
Vercel Sandbox runs code in Firecracker microVMs that you control through TypeScript or Python SDKs. Your application can create an environment, write files, execute a command, and retrieve its output. This fits an agent that generates a Python analysis script or edits a repository and runs its tests.
The Sandbox firewall enforces network policy outside the program. It can restrict destinations and add credentials to outgoing requests, allowing code to call an authenticated API without receiving the raw key.
Notion uses this model for Notion Workers, which execute code written by third-party developers and agents. Each Worker gets its own microVM, with controls for network access and credentials.
Choose the lifecycle deliberately. Vercel's persistent sandboxes retain filesystem state between sessions, while non-persistent sandboxes support disposable execution. Restoring a filesystem snapshot doesn't restore a running Python interpreter's memory. If your product expects notebook variables to survive, it needs an interpreter design that supplies that behavior.
For implementation, start with the KB guide to running untrusted Python or the guide to executing AI-generated code from Next.js. Vercel is a natural candidate when your application already uses its project authentication and you want generated programs to execute separately from the application backend.
Copy link to heading2. Evaluate E2B for code-interpreter applications
E2B provides cloud sandboxes with SDKs for commands and files. Its Code Interpreter SDK retains variables between calls and returns structured results such as charts. This supports follow-up analysis of data already in memory.
For example, an analyst might ask for revenue by region, then ask to exclude refunded orders. An interpreter can reuse its loaded data and imports as it evaluates the next code block. An application built around separate script processes must arrange equivalent reuse through files or another state mechanism.
E2B uses Firecracker microVM isolation. Its sandbox execution, Code Interpreter, and desktop products are separate entry points into the platform, so choose the SDK that matches the interaction you need. Installing the base sandbox SDK doesn't by itself provide the Code Interpreter's result model.
During evaluation, test a complete conversation rather than a single successful cell. Confirm how you associate interpreter state with a user and how a reset affects the next question. Keep the raw dataset available when a failed or interrupted session needs to reconstruct its analysis.
Copy link to heading3. Evaluate Daytona for development workspaces
Daytona provides programmable environments for agents to run commands and work with project files. Its lifecycle APIs cover operations such as creating, stopping, and deleting sandboxes. Development workflows can retain the working environment instead of rebuilding project setup for every interaction.
Reusable Daytona snapshots can define the environment a task starts from. You can prepare language dependencies and project tooling once, then create workspaces from that setup. This is useful when an agent needs a repository-specific test environment across repeated tasks.
Snapshot behavior depends on the sandbox type. Daytona distinguishes container filesystem snapshots from VM snapshots that can also include memory. Select the environment and snapshot mode together; restoring project files is different from resuming an in-progress process.
Test a repository change across several commands, then return to the workspace. Check how your application resumes work after the environment stops. Confirm that the next task receives the intended revision without another user's changes.
Copy link to heading4. Evaluate Modal for Python and GPU-related workloads
Modal Sandboxes provide isolated execution within Modal's compute platform. You can define the environment's image and resources, then run programs through its sandbox API. This makes Modal relevant when generated code needs to work alongside an existing Python compute application or requires GPU resources.
Runtime selection affects the available capabilities. Modal supports VM and gVisor sandbox runtimes, and its GPU sandboxes require the gVisor runtime. Evaluate the isolation model with the resources your production workload requires.
The networking and security controls let you configure how a sandbox reaches other systems. Apply those controls to the actual task: a model-weight download during preparation and an offline computation afterward may need different access.
For a trial, include the full input and output path. Running a GPU command successfully doesn't establish that the application can transfer its dataset, retain artifacts, and recover from an interrupted job. Test those steps before deciding whether the integration fits.
Copy link to heading5. Use Cloudflare Sandboxes from a Worker
Cloudflare Sandboxes gives Workers applications two execution options. Containers provide a Linux environment for commands and installed tools. Dynamic Workers load untrusted code into a separate Worker and expose the application methods that code can call.
Choose Linux for a coding agent that needs a shell, native tools, or a repository's test runner. Transformations that only call methods supplied by your Worker may fit a Dynamic Worker. The choice determines which APIs are available and how much environment setup your application owns.
Cloudflare's sandbox security model treats the contents of each sandbox as shared by the code inside it. Assign separate environments to unrelated users or jobs, and derive their identities from authenticated application state. Don't let a caller-supplied sandbox name determine whose workspace the request receives.
Cloudflare is worth evaluating when a Worker already coordinates the application. Test which credentials remain in the Worker and how your application validates output from the execution environment.
Copy link to heading6. Evaluate Blaxel for sessions that resume after inactivity
Blaxel sandboxes can move into standby when they have no active connection. Standby preserves filesystem and process state, then restores the sandbox when a client reconnects. An agent that works intermittently in the same environment can use this lifecycle to retain its working context between interactions.
Restoring process memory doesn't restore external connections. The database or API may have closed its side while the environment was paused. Resumed code must reconnect and check whether any interrupted operation already completed.
That makes a pause-and-return workflow a better evaluation than a continuous execution. Leave a workspace idle, reconnect, and check both local state and remote-service behavior. If the agent writes to an external system, include a way to identify repeated operations so a reconnect doesn't create duplicates.
Standby and deletion also have different consequences. Use a retention policy that matches how long a user's workspace should remain available, and provide a deliberate reset path for tasks that need a clean environment.
Copy link to heading7. Evaluate Fly.io Sprites for persistent Linux workspaces
Fly.io Sprites are hardware-isolated Linux VMs intended for persistent environments, including AI agents and untrusted code. Files remain available between runs, which suits work that accumulates a repository, installed tools, or intermediate artifacts over time.
The workspace model can fit an agent that returns to an unfinished project. Instead of recreating every file from conversation history, the agent can inspect the existing environment and continue. Your application still needs to establish which user owns that environment and what a subsequent task is allowed to reuse.
Sprites also provides filesystem checkpoints for returning to an earlier state. Restoring an earlier filesystem can discard later edits, and it doesn't undo changes already sent to an external API.
Evaluate persistence with a task that makes changes, stops, and returns later. Then test recovery from an unwanted edit, including which files the checkpoint restores and which later changes it removes.
Copy link to headingHow do you use a sandbox with your AI agent?
Your agent framework controls the model loop and tool calls. The sandbox provider supplies the environment where commands run and files live. You can connect them by exposing sandbox operations as tools, or by starting a coding agent inside the sandbox. The choice depends on whether you are building the agent's tool loop yourself or using an existing agent such as Claude Code.
These integrations use Vercel Sandbox and a server-side Node.js 24+ project. Configure authentication, workspace ownership, and cleanup for your application before using them with real users.
Copy link to headingGive an eve agent a session workspace
eve's sandbox integration connects the built-in bash, read_file, write_file, and edit_file tools to a session workspace.
Add the configuration to agent/sandbox.ts in your eve project:
import { defineSandbox } from 'eve/sandbox';import { VercelSandbox } from 'eve/sandbox/vercel';
export const environment = VercelSandbox.environment();
export default defineSandbox(() => environment.open());Use agent/sandbox/sandbox.ts if the project already has that directory.
Each session gets its own sandbox and keeps files across turns, so an assistant can revise a report after a follow-up request. Authored tools use ctx.getSandbox() to access the same workspace.
Run eve link to connect local development to a Vercel project. Configure deployment credentials, reusable setup, and network policies for that environment. Vercel Drives can retain files independently of the session.
Copy link to headingConnect an AI SDK tool to a sandbox
With AI SDK, the model loop stays in your application while commands run remotely. Its experimental sandbox interface makes that environment available to tools. Tool execute functions still run in your application and must call the sandbox explicitly to execute a command there.
Install the dependencies for the server-side TypeScript example:
pnpm add ai @ai-sdk/sandbox-vercel zodConfigure Sandbox authentication and set AI_GATEWAY_API_KEY in the host environment. Set AI_GATEWAY_MODEL to a tool-capable model ID from AI Gateway.
import { createVercelNetworkSandboxSession,} from '@ai-sdk/sandbox-vercel';import { isStepCount, tool, ToolLoopAgent } from 'ai';import { z } from 'zod';
const model = process.env.AI_GATEWAY_MODEL;if (!model) throw new Error('Set AI_GATEWAY_MODEL');
const session = await createVercelNetworkSandboxSession({ runtime: 'node24', persistent: false, timeout: 60_000, networkPolicy: 'deny-all',});
try { const agent = new ToolLoopAgent({ model, stopWhen: isStepCount(5), tools: { shell: tool({ description: 'Run a shell command in the isolated workspace.', inputSchema: z.object({ command: z.string() }), execute: async ( { command }, { experimental_sandbox, abortSignal }, ) => { if (!experimental_sandbox) { throw new Error('Sandbox is unavailable'); } const result = await experimental_sandbox.run({ command, abortSignal, }); return { exitCode: result.exitCode, stdout: result.stdout.slice(0, 12_000), stderr: result.stderr.slice(0, 12_000), }; }, }), }, });
const result = await agent.generate({ experimental_sandbox: session.restricted(), prompt: 'Use Node.js to calculate the sum of integers from 1 through 100.', }); console.log(result.text);} finally { await session.destroy();}The model request leaves from your application, so the sandbox can deny outbound access during the calculation. The example allows up to five model steps and requests workspace cleanup in a finally block. The expected answer is 5,050; the model's wording can vary.
Each tool result returns up to 12,000 characters from each output stream. Truncation happens after collection, so it doesn't bound output buffered in the host. For public submissions, consume and limit streamed output. Pin compatible versions of the experimental interface and adapter.
Copy link to headingRun a coding agent through TanStack AI
TanStack AI's sandbox middleware can start a coding agent inside the selected environment and stream its work through chat(). It separates the provider, workspace setup, and agent adapter. Its provider integrations include Vercel, E2B, Daytona, Blaxel, and Sprites.
This Claude Code agent inspects a public repository. Install its dependencies:
pnpm add @tanstack/ai @tanstack/ai-claude-code \ @tanstack/ai-sandbox @tanstack/ai-sandbox-vercelSet ANTHROPIC_API_KEY in the host environment, along with the Vercel credentials VERCEL_TOKEN, VERCEL_TEAM_ID, and VERCEL_PROJECT_ID.
import { randomUUID } from 'node:crypto';import { chat } from '@tanstack/ai';import { claudeCodeText } from '@tanstack/ai-claude-code';import { createSecrets, defineSandbox, defineWorkspace, githubRepo, withSandbox,} from '@tanstack/ai-sandbox';import { vercelSandbox } from '@tanstack/ai-sandbox-vercel';
const apiKey = process.env.ANTHROPIC_API_KEY;if (!apiKey) throw new Error('Set ANTHROPIC_API_KEY');
const workspace = defineSandbox({ id: 'repository-reader', provider: vercelSandbox({ persistent: false, timeout: 300_000 }), workspace: defineWorkspace({ source: githubRepo({ repo: 'TanStack/ai' }), setup: ['npm install -g @anthropic-ai/claude-code --include=optional'], secrets: createSecrets({ ANTHROPIC_API_KEY: apiKey }), }), lifecycle: { reuse: 'none', snapshot: 'none', destroyOnComplete: true },});
const stream = chat({ threadId: randomUUID(), adapter: claudeCodeText('claude-opus-4-8'), messages: [ { role: 'user', content: 'Read the README and explain this repository.', }, ], middleware: [withSandbox(workspace)],});
for await (const chunk of stream) { if (chunk.type === 'TEXT_MESSAGE_CONTENT') { process.stdout.write(chunk.delta); } if (chunk.type === 'RUN_ERROR') throw new Error(chunk.message);}Here the sandbox needs network access to clone the repository, install the CLI, and contact the model provider. The model API key enters the sandbox as a workspace secret, so use a credential scoped for that workload. The explicit lifecycle creates a disposable environment for this run. For follow-up work on the same repository, configure thread reuse and persistence together.
TanStack AI can also make your application's server tools callable by the sandboxed agent. Those bridged tools execute on the host, with the host's permissions, so authorization belongs in each tool. For this integration, the bridge endpoint must be reachable from the remote sandbox.
Copy link to headingHow should you test a shortlist?
Use the same workload across providers, including a successful run and the failures your application must handle:
Run a representative program with its real dependencies and input size.
Interrupt it and inspect which files, processes, and outputs remain.
Attempt a network request that the configured policy should reject.
Produce more output than the application intends to retain.
Return to a saved workspace and verify its owner and input revision.
Compare the work your application must own after each test. Successful execution may still require changes to authentication, artifact storage, or session recovery.
Keep results linked to the input and configuration you tested. Include dependency installation and data transfer so measurements cover the full task.
Copy link to headingWhat does choosing a provider leave unresolved?
The provider supplies the execution environment. Your application decides who can use it and what each task can do. Credential brokering keeps keys out of the sandbox, but API permissions must still limit what those keys authorize.
Reusing a workspace saves setup work and retains prior changes, including changes made by untrusted code. Use disposable environments for independent submissions and verify ownership before resuming a workspace.
Vercel Drives can retain files independently of sandbox compute when an application needs a separate storage lifecycle.
Copy link to headingFrequently asked questions
Copy link to headingIs one AI sandbox provider best for every agent?
No. Data-analysis assistants may need a stateful interpreter, while a repository agent needs command execution and a retained working directory. Choose based on the execution model and lifecycle your application requires, then test those requirements with a representative task.
Copy link to headingWhich providers should I evaluate for notebook-style code execution?
E2B is a relevant starting point because its Code Interpreter SDK preserves variables across code calls and returns structured results. Shell-oriented sandboxes can also host interpreters, but your application must provide and manage that integration. Check the distinction before treating a successful Python command as a complete notebook experience.
Copy link to headingDo all sandbox providers preserve the same state?
No. Files, interpreter memory, processes, and external connections have different lifecycles. Check the exact environment and snapshot mode, then test what remains after a pause or restart.
Copy link to headingCan I switch providers by changing the SDK import?
Usually the integration requires more work because providers differ in command handling, file APIs, authentication, and state retention. Keep your application's execution interface explicit and test those behaviors during a migration. Even a shared interface leaves differences in isolation and lifecycle behavior.