Sprites

Product Overview

Sprites are Fly.io's new stateful sandbox environments for running arbitrary code — particularly AI agents like Claude Code.^[1] Unlike ephemeral sandboxes that die after each run, Sprites are persistent Linux computers with checkpoint/restore.

Aspect	Details
Company	Fly.io (cloud platform, $120M+ raised)
Model	Stateful VMs with object-storage persistence
Isolation	Firecracker microVMs (hardware-level)
Storage	100GB ext4 filesystem, backed by S3
Creation	~1-2 seconds
SDKs	CLI, REST API, JavaScript, Go
Trial	$30 credits (~500 Sprites)

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

What Makes It Different

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

Feature	Serverless/Ephemeral	Sprites
State	Destroyed after use	Persistent
Filesystem	Read-only or temp	Full ext4, survives restarts
Startup	Cold starts (100ms–seconds)	Instant wake from hibernate
Billing	Per-invocation	Per-second, free when idle
Environment	Fixed container	Full Linux, install anything
Isolation	Container-level	Hardware-level (Firecracker)

Key capabilities:^[3]

• Create Sprites in 1-2 seconds (feels like SSH to an existing machine)
• Unlimited checkpoints — like git, but for the whole system
• Checkpoint/restore in ~1 second
• Auto-sleep when idle, wake on next request
• Each Sprite gets a unique HTTPS URL

Technical Architecture

Three design decisions make Sprites work:^[4]

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.

Pricing

Granular billing based on actual resource consumption:^[1]

Resource	Price
CPU Time	$0.07/CPU-hour
Memory	$0.04375/GB-hour
Hot Storage (NVMe cache)	$0.000683/GB-hour
Cold Storage (S3)	$0.000027/GB-hour

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

Example Costs

Scenario	Cost
4-hour Claude Code session (avg 30% of 2 CPUs, 1.5GB)	~$0.44
Web app with 30 hrs/month wake time	~$1.89/month

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

Use Cases

Sprites are designed for:^[3]

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.^[2]

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

Solution	Model	Persistence	Checkpoint	Isolation
Sprites	Stateful VMs	✅ 100GB	✅ Instant	Firecracker
E2B	Ephemeral sandboxes	❌	❌	Firecracker
Modal	Serverless containers	❌	❌	gVisor
Daytona	Dev environments	✅	❌	Containers
Codex Cloud	Cloud execution	✅	❌	Unknown

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

• New product — launched recently, ecosystem still maturing
• Fly.io account required — uses Fly's auth, billing tied to Fly account
• 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 (yet) — CPU-only workloads

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.

When to use Sprites:

• Your agent needs to maintain state between runs
• You want checkpoint/restore for experimentation
• You need a real Linux computer, not a container
• You want granular billing with no idle costs

When to use something else:

• You specifically want ephemeral isolation (E2B)
• You need GPU compute (Modal, RunPod)
• You want managed orchestration (Codex App cloud, Warp Oz)

Sprites fill a gap in the market: instant-creation VMs with durability. As Fly.io puts it, "ephemeral sandboxes are obsolete."^[2]

---

Research by Ry Walker Research

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