E2B

You call the SDK to spawn a sandbox, which comes up as an isolated environment with a filesystem, network access and the usual tooling. Your agent writes code, the sandbox runs it, and you read back stdout, files or errors and feed them to the next step of the loop. Because startup is fast and each sandbox is disposable, the normal pattern is one sandbox per task or per attempt rather than a long-lived machine you have to keep clean. Sandboxes can be sized to the workload, and billing follows the seconds consumed at a rate that scales with size. When the run finishes you tear it down and nothing persists unless you deliberately keep it.

• •Isolation as the Product - Generated code executes away from your own infrastructure, which is the entire reason the category exists
• •Per-Second Billing - Costs track actual compute, so idle agents are free and parallel bursts cost only what they use
• •Fast Disposable Environments - Designed for one sandbox per task rather than long-lived machines that accumulate state
• •Open Source Core - The isolation boundary you are trusting can be read and self-hosted
• •Built for Agent Patterns - Explicitly targets deep research, computer use, background and RL agents, plus secure MCP servers
• •Real Tooling Inside - Filesystem, network and standard tools, not a stripped interpreter that breaks on real work

Teams building products where an AI writes and runs code: data analysis agents, coding agents, research agents that fetch and process, anything with an execution step. If you are prototyping alone, the free tier plus $100 of credits covers a lot of experimenting. The economics work best when load is spiky, since per-second billing is a poor deal for steady round-the-clock usage where a reserved machine is cheaper. If your agent only calls APIs and never executes generated code, you do not need this at all.