待翻译：Workdir: Open-source sandboxes for AI agents

AI 服务暂时不可用，以下为来源正文，待恢复后补全翻译。

workdir — Firecracker sandboxes for AI agents $ open-source sandboxes for ai agents Real Linux sandboxes in 38 ms. 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. get a demo key → self-host it npm i @workdir/sdk · pip install workdir · or just curl workdir — zsh — 80×24 api.workdir.dev $workdir create → sandbox sb_9f3ka2 created boot_pathhot_pool queue2ms assign4ms kernel19ms agent13ms ready38ms ── total $workdir exec sb_9f3ka2 -- echo "hello from a microVM" hello from a microVM $workdir delete sb_9f3ka2 → deleted · ran 11s · metered $0.00003 $ hot boot, p50 38ms empty-pool create 45ms 1 vCPU · 2 GB $0.009/hr hosted API demoonly // the numbers 01 Measured, not marketed. 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 Idle costs nothing. Waking costs nothing extra. 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 A desktop, a disk that stays, and room to pack them in. 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 Versus the other sandboxes. 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 We'd rather you self-host. 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 deploy guide github impatient? take a hosted key → first sandbox in under a minute.