boxd vs sprites.dev: two bets on persistent agent compute

In January 2026 Fly.io launched Sprites with a sentence from Kurt Mackey that read like a manifesto: "The age of sandboxes is over. The time of the disposable computer has come." It's the same thesis we built boxd on. Two teams looked at where AI agents are going and concluded persistent microVMs are the right primitive. The two products are the head-to-head implementations of that bet.

This is an honest comparison from the team building the other one. Sprites is well-funded, well-engineered, and validates our category. The differences below are about design choices, not architecture; we agree on most of the architecture.

What we agree on

The thesis is identical:

• AI agents need persistent compute, not ephemeral sandboxes.
• The right unit is a microVM, not a container — real kernel, real isolation.
• Idle compute should bill near zero — sleep-to-zero is required, not optional.
• Checkpoint and resume should be fast enough that hibernation feels invisible.
• Per-VM HTTPS, real network identity, MCP-friendly are baseline requirements.

If you've read the Sprites launch post and our manifesto on persistence, you'll recognise the same arguments. The teams arrived at the same place independently. Two products betting on the same future is a sign that the thesis is right.

At a glance

Sprites figures are sourced from public Fly.io documentation, the launch post, and the design-and-implementation blog as of April 2026. boxd figures are from our own benchmarks.

Methodology

We picked the eight capabilities above as the criteria most material to a buyer choosing between persistent-microVM platforms for agent workloads. Sprites has additional capabilities not surfaced in the table (granular per-second billing across many resource axes, native MCP transport, Tailscale-backed networking, Claude pre-installed) — the "Where Sprites wins" section credits those. Pricing rows reflect each vendor's published rates as of April 2026; corrections to hello@boxd.sh.

Where Sprites wins

Be honest. Five places they're ahead:

Fly.io's infrastructure and team. Sprites runs on Fly Machines, which runs on bare-metal datacenters Fly has been operating for years. Network, observability, billing, scale — all already-solved problems. ~60 employees, 33 engineers, ~$110M raised total funding, ~$397M valuation as of 2024 (Crunchbase). That's a different operational maturity than a startup.

Claude pre-installed by default and MCP transport native. A new Sprite arrives with Claude Code already configured, the claude binary on the path, and an https://sprites.dev/mcp endpoint with OAuth-based MCP transport. For an agent builder who wants to ship today, that's friction removed.

SDK breadth. Go, JavaScript/TypeScript, Python, and Elixir SDKs are all live, all MIT, all designed to mirror native APIs (Node child_process, Go exec.Cmd). The DX is cleaner than most cloud platforms three years older.

Content marketing distribution. Simon Willison covered Sprites positively at launch. The HN debut was 508 upvotes. The Sprites blog publishes 3–4 substantive posts a month. Fly.io's voice is well-tuned for developer audiences and that pulls real traffic. We're earlier in our content motion.

Granular usage billing model. Per-CPU-second, per-GB-second, per-block-written. For a workload that's genuinely usage-shaped, you pay almost exactly for what you use. We share the auto-sleep mechanic; their billing model is more granular than ours by a factor.

If you're an indie dev building agents on Anthropic models, want a hosted product that just works today, and don't need to self-host — Sprites is a clean choice and we'd say so.

The architectural difference

We diverge on what sits between you and the model. The visible spec is similar; the implementation isn't.

Sprites: inside-out orchestration

A Sprite is a Firecracker microVM running on top of Fly Machines. Inside the VM, a root namespace runs orchestration code — a service manager, a storage stack, a logging shim. The user's code runs in an inner container nested inside the VM. The global orchestrator is an Elixir/Phoenix application that uses object storage as the metadata source of truth, with per-account SQLite databases made durable via Litestream. Storage is a heavily modified JuiceFS pinned to S3-compatible object storage with NVMe as a read-through cache. Service discovery is Corrosion, Fly.io's gossip protocol over SQLite. Checkpoint/restore in ~300ms is achieved by copy-on-write metadata reshuffling.

It's a sophisticated stack. It's also a lot of moving parts. Several of them are open source (Corrosion, the SDKs); the core orchestration is not.

boxd: one binary, one process per VM

A boxd VM is a KVM microVM with the user's code running directly on the kernel — no inner container layer. The control plane is a single Rust binary that runs all roles in one process for dev (boxd), or splits into per-role binaries (boxd-control, boxd-worker, boxd-proxy, boxd-dns) for production. State of record is Raft (raft-rs/TiKV) plus a SQLite materialised view. No external Postgres. No external Redis. No Kubernetes. No object-storage-backed metadata stack.

Resume from sleep is sub-millisecond because the design treats hibernation as a first-class state, not a derived feature. Fork is sub-100 ms because copy-on-write of the running VM is the primitive. The whole control plane is the binary.

Both stacks land at persistent microVMs. The Sprites stack expresses it through a richer service mesh; the boxd stack expresses it through fewer moving parts. Whether you prefer rich-and-managed or minimal-and-self-hostable is a real preference, not a marketing distinction.

Where boxd wins

Five places where our design choices line up differently.

Self-host as a real option. Sprites is Fly.io-managed-only as of April 2026. Thomas Ptacek announced an open-source local version at launch; it has not shipped, three months in. boxd is one Rust binary; you can run it in your VPC today. For a regulated team or an EU org subject to DSGVO and Schrems II, this is the difference between theoretically compliant and the audit fits on one page.

Sub-millisecond resume. The two products are doing different things here. Sprites' "~300 ms" figure is the time to create a checkpoint (a metadata operation); user-perceived restore back to running is roughly one second. boxd's sub-millisecond figure is wake-from-hibernate of a VM that was already running. For per-iteration agent workloads, that difference compounds: a thousand wakes at one second is 16 minutes of accumulated tax; a thousand wakes at sub-millisecond is under a second.

Fork of the running machine. Sprites' checkpoint/restore is the closest thing they ship to fork. It's a snapshot of disk state taken before the action and restored after. boxd's fork is copy-on-write of the running VM — memory, disk, in-flight processes — at sub-100 ms. The semantic is branch this exact state and run forward in two universes. Different primitive; matters for agent harness workflows that genuinely need parallel exploration from one state.

Stack simplicity. Sprites' control plane involves Elixir/Phoenix, JuiceFS, S3, Litestream, SQLite, Corrosion, Tailscale, and the Firecracker host machinery. boxd's is Rust, KVM, Raft, SQLite. Fewer moving parts means fewer blast radii, fewer dependencies to upgrade, a smaller surface for the team running it.

Region and jurisdiction control. Sprites auto-assigns to the nearest Fly.io region. No region selection. boxd's managed offering runs on OVH in Europe; the binary runs anywhere with KVM. Where the agent executes is a customer decision, not a vendor scheduling decision.

Specific scenarios

"I'm an indie dev building an agent"

Sprites probably wins here. Claude is pre-installed; MCP works out of the box; the trial credits cover meaningful experimentation. boxd is also good (free individual tier, 100 GB disk per VM, full programmatic API), but the day-one to running agent path is shorter on Sprites today.

"I'm an engineering team with compliance pressure"

boxd wins here decisively. Self-host on your VPC, your country, your bare metal. The single-binary install is roughly the same operational surface as a Postgres install. Sprites' lack of self-host means a vendor in your data path; for many compliance contexts that's a non-starter.

"I want a hosted product but I want option-to-self-host later"

boxd. The same software runs in our managed cloud and on your hardware; migration is a config change, not a re-platform. Sprites' open-source local version was promised at launch and remains unshipped; we wouldn't bet on it as a fallback until it ships.

"I want fork-from-running-state for parallel agent runs"

boxd. Sprites' checkpoint/restore is closest, but the semantics are different: snapshot to disk, restore from disk. Fork-from-memory in 60 ms is a distinct primitive that maps to the try three approaches in parallel workflow.

"I want a polished SDK in my language today"

Sprites. Their SDK ecosystem is broader than ours right now. We expose everything over SSH and JSON, which is enough to drive boxd from any language but it's not the same as a typed Go or Python SDK.

When to pick Sprites

• You want hosted; you don't want to operate a control plane.
• You're building Claude-first; pre-installed Claude and MCP transport are valuable.
• You're already on Fly.io and the integration story matters.
• You care most about granular pay-per-use billing.
• Your data residency requirements are loose enough that Fly.io's regions is acceptable.

When to pick boxd

• You need self-host — your VPC, your DC, your country.
• You're building agent harnesses that fork from running state.
• You want sub-millisecond resume on a per-iteration loop.
• You'd rather operate one Rust binary than an Elixir orchestrator + JuiceFS stack.
• You want the substrate to be open source so you can audit, fork, contribute.

What this comparison is for

The agent-compute category has split into two halves. One half is the broad ephemeral-sandbox products (E2B, code interpreters) that are now retrofitting persistence. The other half is the products built around persistence from the start. Sprites and boxd are both in the second half, and we're glad about it — Mackey's the age of sandboxes is over lands with more weight when two teams are saying it.

Within the persistent-microVM category, Sprites is the managed Fly.io play. boxd is the open, self-hostable play. Both are valid. The comparison above is specific enough to match against your actual requirements rather than against marketing.

ssh boxd.sh and try it. If Sprites fits better, go there — https://sprites.dev. The thesis wins either way. The other comparison worth reading is boxd vs exe.dev — the closest competitor by stated positioning rather than by architecture.

Verification details (boxd vs sprites.dev, last verified 2026-05-04, last updated 2026-05-04)

• Pricing rows reference Sprites' standard tier (monthly invoice, as of April 2026): $0.07/CPU-hour, $0.04375/GB-hour memory, billed by the second, scale-to-zero, as documented at sprites.dev. boxd's Individual tier is free as of April 2026; Team pool plans are per-user, billed monthly, as documented at boxd.sh/pricing.
• Feature claims about Sprites are sourced from the sprites.dev site, the Code and Let Live launch post, and the Design and Implementation of Sprites deep-dive, all as of April 2026.
• Comparison criteria are limited to the eight rows in the At a glance table. Sprites has additional capabilities not compared here (granular per-second billing, native MCP transport at sprites.dev/mcp, Tailscale-backed networking, Claude pre-installed, broader SDK ecosystem). Other readers may weigh those differently; treat this as one team's honest assessment, not a buying guide.
• This is informational, not a contractual statement of either product's capabilities. Send corrections to hello@boxd.sh.