Sprites

Product Overview

Sprites are Fly.io's stateful sandbox environments for running arbitrary code — particularly AI agents like Claude Code.^[1] Launched in January 2026, they are publicly available with usage-based billing (Fly.io has never attached a formal beta/GA label).^[2] Unlike ephemeral sandboxes that die after each run, Sprites are persistent Linux computers with checkpoint/restore.

The pitch: "Claude doesn't want a stateless container. Claude wants a computer."^[4]

What Makes It Different

Fly.io's thesis is that ephemeral sandboxes are the wrong abstraction for AI agents:^[4]

Key capabilities:^[5]

• Create Sprites in 1-2 seconds (feels like SSH to an existing machine)
• Unlimited checkpoints — like git, but for the whole system
• Live Checkpoints take ~300ms (copy-on-write, incremental); cold-start restores in well under a second^[1]
• Auto-sleep when idle, wake on next request
• Each Sprite gets a unique HTTPS URL
• Native MCP endpoint (sprites.dev/mcp) so agents can provision and manage Sprites themselves^[6]

Technical Architecture

Three design decisions make Sprites work:^[7]

1. No Container Images

Fly Machines require pulling and unpacking user containers, which takes 30-60+ seconds. Sprites use a standard base image, so pools of "empty" Sprites stand by ready. Creating a Sprite is just starting one.

2. Object Storage for Disks

Sprite storage is backed by S3-compatible object storage, not attached NVMe. The filesystem uses a JuiceFS-like model: data chunks on object storage, metadata in local SQLite (made durable with Litestream). NVMe is just a read-through cache.

Implications:

• Sprites migrate trivially (state is just a URL)
• Recovery from failed physicals is instant
• Checkpoints shuffle metadata, not data — hence they're fast

3. Inside-Out Orchestration

Unlike traditional cloud where the host manages the guest, Sprites flip it: the most important orchestration happens inside the VM. User code runs in a nested container within the Sprite.

What's Shipped Since Launch

Fly.io has iterated quickly since the January 2026 launch:

• Subscription plans (January 2026) — eight tiers from Adventurer ($20/month, 20 concurrent active Sprites) through Mythic ($2,000/month, 2,000 concurrent) plus custom Guild plans; usage beyond included amounts bills at standard rates^[8]
• Storage repricing (January 2026) — cold storage cut to $0.02/GB-month on Tigris, hot NVMe cache at $0.50/GB-month^[1]
• Self-service plan changes (February 2026) — upgrades take effect immediately from the billing dashboard^[8]
• MCP support (March 2026) — a native sprites.dev/mcp endpoint, shipped with characteristic ambivalence: "In 2026, MCP is the wrong way to extend the capabilities of an agent" — but it lets agents without CLI skills spin up disposable computers^[6]

GPU support remains absent — Sprites are CPU-only, with Fly Machines as the GPU path.^[9]

Pricing

Granular billing based on actual resource consumption (rates verified June 2026):^[1]

Minimums: 6.25% CPU per second, 250MB memory per second.

Example Costs

No charges when idle. Storage persists at negligible cost (~$0.20/month for 10GB cold).

Subscription plans ($20–$2,000/month, plus custom Guild tiers) gate how many Sprites can be active concurrently — from 20 on the $20 Adventurer plan to 2,000 on Mythic — with included CPU/RAM/storage allocations per tier.^[8]

Use Cases

Sprites are designed for:^[5]

1. AI Code Execution — Claude Code, Codex, or any agent that needs a real environment
2. Untrusted Code — User-submitted code in hardware-isolated VMs
3. Development Environments — Persistent dev boxes that sleep when inactive
4. Long-lived Services — APIs that auto-sleep and wake on request
5. CI/CD — Testing against live repos with full environment access

The launch blog describes a use case where someone "vibe-coded an MDM" with Claude on a Sprite and has been running it in production for a month — dev is prod, prod is dev.^[4]

Quick Start

# Install CLI
curl https://sprites.dev/install.sh | bash

# Login (uses Fly.io account)
sprite login

# Create a Sprite
sprite create my-sprite

# Run a command
sprite exec -s my-sprite ls -la

# SSH-like console
sprite console -s my-sprite

# Checkpoint
sprite checkpoint create v1

# Restore
sprite checkpoint restore v1

Also available via REST API, JavaScript SDK, and Go SDK.^[1]

Competitive Landscape

As of June 2026:^[9]

Sprites' unique position: Combines instant creation (like serverless) with persistence (like VMs) and checkpoint/restore (unique). The "ballpoint disposable computer" — cheap enough to create hundreds, durable enough to keep for months.

Limitations

• Young product — launched January 2026; developers report sparse documentation and limited billing/usage visibility^[10]
• No Docker image support — you start from a base Linux environment and install dependencies manually, rather than bringing standard OCI images^[9]
• Fly.io account required — uses Fly's auth, billing tied to Fly account; runs exclusively on Fly.io infrastructure (no BYO-cloud)^[9]
• Not for high-scale stateless — if you want ephemeral-by-design, use E2B
• 100GB max storage — sufficient for most agent work, but not for large datasets
• No GPU support — CPU-only by design; Fly Machines are the GPU path^[9]

What Developers Say

Hacker News reaction (as of June 2026) skews positive on the core experience, critical on polish:^[10]

"I shipped an MVP with it... found it was a lot more polished, and now have multiple production apps running there." — macNchz

"Set it up right in Termux and you can vibe code a website with a full backend from your phone." — roywiggins

"Documentation is sparse, or not even available? The API docs don't tell you much about the service itself." — MrOrelliOReilly

"Incredible engineers that somehow lack that final 10% of polish/naming/documentation that makes things seriously usable." — el_nahual

Simon Willison called it a product that "addresses both developer sandboxes and API sandboxes at the same time" — sandboxing agents in YOLO mode plus an API for untrusted code.^[2]

Bottom Line

Sprites represent a philosophical shift in how we think about agent execution environments. The ephemeral sandbox model — pioneered by E2B and others — assumes agents should start fresh every time. Fly.io argues this creates unnecessary friction: rebuilding node_modules, setting up databases, losing context between sessions.

Recommended for:

• Agents that need to maintain state between runs
• Checkpoint/restore-driven experimentation ("git for the whole system")
• Workloads that need a real Linux computer, not a container
• Cost-sensitive usage — granular billing, zero idle cost

Not recommended for:

• Ephemeral-by-design isolation at platform scale (E2B)
• GPU compute (Modal, RunPod, Fly Machines)
• Teams that need standard Docker/OCI images or BYO-cloud deployment^[9]
• Managed orchestration (Codex App cloud, Warp Oz)

Outlook: Five months in, Sprites is shipping fast — plans, storage repricing, MCP — and developers are running production apps on it, while complaining about thin docs and billing visibility.^[10] The persistent-sandbox thesis ("ephemeral sandboxes are obsolete") is getting validated by community tooling built on top of it; the open question is whether Fly.io's small team can out-execute the heavily funded ephemeral-sandbox players.^[4]

---

Research by Ry Walker Research

Disclosure: Author is CEO of Tembo, which offers agent orchestration as an alternative approach to agent infrastructure.