thinslice vs Fly Sprites

Fly Sprites (sprites.dev) are stateful cloud micro-VMs for AI agents. Fly launched them in January 2026. Each Sprite is a persistent Linux machine on Fly's servers, with agents pre-installed and per-VM metered billing. exe.dev and E2B sell the same shape: rented, isolated cloud compute you reach over the network.

thinslice is a CLI that binds each git worktree to its own bag of runtime state — a dedicated Postgres cluster, a Redis instance, a port range, and config. It runs native processes on your machine. No Docker, no VMs, no cloud account. Source available, on macOS, Linux, and Windows.

thinslice CLI multiplexing agent worktrees

Local, not rented

A Sprite lives on Fly's servers. The environment the agent touches is a machine you rent by the hour. exe.dev gives you SSH into a rented Linux box. E2B gives you a Firecracker micro-VM in the cloud. Every one of these is a computer somewhere else.

thinslice runs on the machine in front of you. The agent's Postgres, Redis, and dev server are native processes on your own disk. You own the machine and every process on it. There is no account to provision and no VM to rent.

No internet in the inner loop

A cloud sandbox puts a network round-trip between the agent and the code it runs. Every command, every test, every migration crosses the internet to Fly, exe.dev, or E2B and back. Lose the connection and the loop stops.

thinslice has no network hop in the inner loop. The agent, the code, and the database run as processes on one machine. Work on a plane or a bad hotel connection — the loop does not change.

No per-VM meter

Sprites bill for CPU, memory, and stored bytes, plus a subscription tier that caps how many run at once (as of August 2026). exe.dev and E2B meter compute the same way. Every hour an agent runs is a line on a bill.

thinslice is free. It has no metered compute, no per-VM charge, and no per-checkpoint charge. Let an agent try something expensive ten times. The cost does not change, because the process runs on hardware you already own.

Process fork, not VM restore

Sprites report a checkpoint and restore near 300ms and a cold create of 1 to 12 seconds (as of August 2026). That is fast for a VM. It is still a VM: state must serialize to disk and load back.

thinslice starts a new worktree with a process fork. There is no VM to checkpoint and no image to restore. A new slice is a directory and a set of processes, so it is ready about as fast as your shell can spawn them.

State you can open

When an agent breaks something in a Sprite, its state sits inside a VM behind an API. You reach it through SSH or a checkpoint, not with the file tools already on your machine.

A thinslice state bag is a plain named directory. You can cd into it, run pg_dump, rsync it to a backup, or snapshot it with any file tool. The database and the config are files you can open and read directly.

CLI

thinslice is a CLI first:

# Create a worktree with its own db, redis, and ports
slice new feature/add-search

# Spawn a throwaway worktree cloned from the current slice, hand it to any agent
slice tmp --from current claude -p "add full-text search to the products table"

# List all slices and their state
slice ls

# Attach to an existing slice
slice attach feature/add-search

slice tmp --from current clones the current state bag into a fresh worktree, so the agent starts with real data and a working dev environment. When the agent exits, thinslice discards the throwaway worktree. Any CLI agent works, with your own credentials.

Change the tool itself

thinslice ships as a collection of shell scripts. The files that run are the files you installed. There is no compiled binary and no build step between you and the tool.

If you want a command to work differently, ask your coding agent to edit the installed scripts. The change is live on the next run. Most tools stop you at this point: fork the repository, install the toolchain, build, and then test. thinslice also includes a built-in path to send your change upstream.

Sprites, exe.dev, and E2B are hosted services. You cannot change how they work.

Platforms

thinslice runs on macOS, Linux, and Windows. Sprites, exe.dev, and E2B run in the cloud, so a browser or an SSH client is enough on the client side. The work runs on their servers.

Comparison

thinsliceFly Spritesexe.devE2B
Where it runsYour machineFly cloudexe.dev cloudE2B cloud
Services run asNative processesMicro-VMLinux VMFirecracker micro-VM
Cost modelFreeMetered + subscriptionSubscriptionMetered + subscription
Works offlineYes
Cold startProcess fork~300ms restore, 1–12s createVM startSub-200ms VM
Inspect state with local file toolsYes (plain directory)
Per-worktree Postgres / Redis / portsYes
Bring your own agentYesPre-installed setShelley (own agent)Yes
Edit the tool with your coding agentYes (shell scripts)
LicenseSource available (community license)ProprietaryProprietaryOpen source
VM-level isolation for untrusted codeYesYesYes
Scale beyond one machineYesYesYes