$ open-source sandboxes for ai agents
One API to create, exec, and delete Firecracker microVMs. The hosted API is a small capacity-limited demo with $0.50 in credits, not a production cloud. Self-hosting is the production path.
npm i @workdir/sdk · pip install workdir · or just curl
workdir — zsh — 80×24 api.workdir.dev
hot boot, p50 38ms
empty-pool create 45ms
1 vCPU · 2 GB $0.009/hr
hosted API demoonly
// the numbers 01
Three ways a sandbox comes up. Every create response tells you which one you got, with the full timing trace.
| boot path | p50 | p95 | what it is |
|---|---|---|---|
| hot_pool | 38 ms | 61 ms | warm microVM claimed from the pool — curated images |
| snapshot_restore | 45 ms | 65 ms | golden image snapshot restored — empty-pool creates land here now, and so does the perpetual-standby wake |
| cold_boot | ~1.2 s | ~1.5 s | fresh rootfs boot — only the first run of a brand-new image, or a volume-attached sandbox |
| base shape | 1 vCPU · 2 GB · 8 GB disk | $0.009 / hr | ≈ $0.0000025 / second |
| metering | per second | no minimum | meter stops at delete |
| bigger shapes | linear in resources | 2× memory ≈ 2× price | quote returned on every create |
don't trust this table — every create returns its own boot_path,
timings_ms, and metered quote. trust those.
// perpetual standby 02
Leave a sandbox alone and it stops burning RAM and money — without dying. workdir snapshots it, frees the memory, and parks it at $0, then brings it back with its disk and processes intact the instant your next call lands. Your code never knows it slept.
| state | cost | what happens |
|---|---|---|
| running | per-second | full vCPU + RAM, metered by the second while it works |
| idle, still hot | per-second | after ~a minute idle the guest hands its unused RAM back to the host (virtio-balloon) — a 2 GB sandbox drops to ~57 MB resident while staying instantly responsive |
| idle → standby | $0 / hr | snapshotted to disk, RAM freed, parked — the meter stops the moment it parks |
| wake | no extra | the next exec / file / port call auto-resumes it in ~50 ms (~80 ms for the full API round trip) — no resume API, no cold boot, state intact (survives a daemon restart, too) |
| fork | per-second | clone a live sandbox into an instant sibling from its snapshot — same disk, its own id |
most sandboxes make you choose: pay to keep one warm, or lose its state when it times out. standby is the third option — a sandbox that's always there and only costs you while it's actually doing something.
// build on it 03
The same microVM runs more than a shell. Give an agent a real browser to drive, hand it storage that outlives the box, and run far more of them per node — all behind the one API.
| capability | what you get |
|---|---|
| computer-use desktops | the browser image boots headed Chrome on a virtual display — drive it programmatically over CDP (Chrome DevTools Protocol, e.g. Playwright connectOverCDP), watch it live over VNC/noVNC, or grab a one-call GET /browser/screenshot PNG. Built for browser agents and computer-use. |
| persistent volumes | attach block storage that outlives the sandbox. Delete the box, keep the disk, re-attach it to the next one — survives standby and resume too. volumes: [{ volume_id, mount_path }]. |
| interactive terminal | a real TTY in every sandbox: GET /v1/sandboxes/:id/pty upgrades to a WebSocket bridged onto an in-guest pseudo-terminal — job control, ^C, vim, the lot. Point xterm.js at it and you have a live terminal. |
| live metrics | GET /v1/sandboxes/:id/metrics — what a sandbox actually uses vs. what it reserves: host-resident memory, guest memory stats, network counters. The same honesty as boot_path, for runtime. |
| in-RAM density | one read-only base image and one golden memory image are shared across every microVM — single copies in host RAM — while each VM's writes land in its own overlay. Many more sandboxes per node, same isolation. |
| instant fork | clone a running sandbox into an independent sibling from its live snapshot — same disk state, its own id and network. Great for fan-out and branch-and-try. |
volumes are the durable counterpart to standby: standby keeps a running sandbox cheap, volumes keep its data around even after it's gone.
// the field 04
Their published numbers, their marketing's best case, rounded in their favor.
| workdir | e2b | modal | fly machines | |
|---|---|---|---|---|
| isolation | firecracker microVM | firecracker microVM | gVisor container | firecracker microVM |
| create → ready | 38 ms hot · 45 ms restore · ~1.2 s cold | ~150 ms | ~1 s | ~300 ms |
| idle sandbox | $0 · auto-resumes | killed on timeout | scales to zero | auto-stop, you wire it |
| 1 vCPU · 2 GB | $0.009 / hr | ~$0.13 / hr | ~$0.15 / hr | ~$0.015 / hr |
| boot path disclosed | every create | — | — | — |
| self-host | one command | diy cluster | — | — |
| open source | AGPL-3.0, all of it | infra only | — | — |
mid-2026 list prices for the closest comparable shape; latencies as advertised by each. spot an error? open an issue and we'll fix the table.
// self-host 05
One command on a KVM box turns it into a sandbox fleet — the same binary our cloud runs, scheduler, billing, and preview proxy included.
Your agents, on your metal. You can read every line of the thing they execute on, cap their network, and add capacity by plugging in another server. No quotas, no noisy neighbors, no usage report you can't audit.
The hosted cloud at workdir.dev exists for the impatient — same code, same prices, zero setup. It's a convenience, not a moat.
agpl-3.0 · single binary · no phone-home · gpu shapes next release
ubuntu 24.04 / debian 12 · kvm required
curl -fsSL https://workdir.dev/install.sh | sudo bash
impatient? take a hosted key → first sandbox in under a minute.
¹ every number, and how it's measured
All latencies are timed server-side, from the API admitting your create to the in-guest
agent reporting ready — the exact span returned as timings_ms on every
create. Percentiles are trailing 30 days on the public fleet, split per path.
| hot_pool | claim a pre-booted microVM from the warm pool: queue → assign → handshake. Live fleet percentiles. |
| snapshot_restore | restore a memory + disk snapshot and resume the VM. Two cases share this path: an empty-pool create restores the per-image golden snapshot (a pre-spawned jailed Firecracker is waiting for it), and a standby sandbox wakes from its own. Measured on the production node — the guest demand-pages from the mem file, so resume returns without reading the whole image. |
| cold_boot | copy the rootfs, boot the kernel fresh (boot logging off the serial console), start the agent, handshake. Only the first run of a brand-new image — or a sandbox with volumes attached — takes this path. ~ = rounded from production measurements. |
| $0.009 / hr | the at-cost unit price in pricing.rs × the resources you ask for. The exact quote rides on every create response. |
| 1 s metering | the meter runs from create to delete and rounds to the second. No minimum, no idle charge after delete. |
Why we split it three ways: most providers quote their warmest path and call it "starts at". We won't. 38 ms is the hot pool — cold is ~1.2 s, and the table says so. Every create tells you which one you got.
² comparison sources
Retrieved June 2026, normalized to the closest shape to 1 vCPU · 2 GB each provider sells, rounded in their favor. Latencies are the headline figures from their own docs — we did not benchmark competitors ourselves.
Pricing pages move. If a number here is stale, open an issue — the table gets fixed, not defended.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。