workdir — Firecracker sandboxes for AI agents
log in<br>get api key →
$ 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<br>capacity-limited demo with $0.50 in credits, not a production cloud.<br>Self-hosting is the production path.
get a demo key →<br>self-host it
npm i @workdir/sdk · pip install workdir ·<br>or just curl
workdir — zsh — 80×24<br>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, p501<br>38ms
empty-pool create1<br>45ms
1 vCPU · 2 GB1<br>$0.009/hr
hosted API1<br>demoonly
// the numbers 01
Measured, not marketed.
Three ways a sandbox comes up. Every create response tells you which one you got, with<br>the full timing trace.
boot path<br>p501<br>p951<br>what it is
hot_pool<br>38 ms<br>61 ms<br>warm microVM claimed from the pool — curated images
snapshot_restore<br>45 ms<br>65 ms<br>golden image snapshot restored — empty-pool creates land here now, and so does the perpetual-standby wake
cold_boot<br>~1.2 s<br>~1.5 s<br>fresh rootfs boot — only the first run of a brand-new image, or a volume-attached sandbox
base shape<br>1 vCPU · 2 GB · 8 GB disk<br>$0.009 / hr<br>≈ $0.0000025 / second
metering<br>per second<br>no minimum<br>meter stops at delete
bigger shapes<br>linear in resources<br>2× memory ≈ 2× price<br>quote returned on every create
don't trust this table — every create returns its own boot_path,<br>timings_ms, and metered quote. trust those.<br>¹ how we measure →
// perpetual standby 02
Idle costs nothing. Waking costs nothing extra.
Leave a sandbox alone and it stops burning RAM and money — without dying. workdir<br>snapshots it, frees the memory, and parks it at $0 , then brings it back with its<br>disk and processes intact the instant your next call lands. Your code never knows it slept.
state<br>cost<br>what happens
running<br>per-second<br>full vCPU + RAM, metered by the second while it works
idle, still hot<br>per-second<br>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<br>$0 / hr<br>snapshotted to disk, RAM freed, parked — the meter stops the moment it parks
wake<br>no extra<br>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<br>per-second<br>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.<br>standby is the third option — a sandbox that's always there and only costs you while it's<br>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<br>storage that outlives the box, and run far more of them per node — all behind the one API.
capability<br>what you get
computer-use desktops<br>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<br>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<br>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<br>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<br>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<br>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,<br>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<br>e2b<br>modal<br>fly machines
isolation<br>firecracker microVM<br>firecracker microVM<br>gVisor container<br>firecracker microVM
create → ready<br>38 ms hot · 45 ms restore · ~1.2 s cold<br>~150 ms<br>~1 s<br>~300 ms
idle sandbox<br>$0 ·...