Runtime vs Fly.io

Fly.io runs agent code in Firecracker microVMs, as Sprites or as Machines; Runtime does too, and bills the CPU a sandbox uses at lower rates than Sprites.

This page compares Runtime with Fly.io's two ways to run agent code: Sprites, its sandboxes for agents, and Machines, its general-purpose VMs. Facts about Fly.io come from its public pricing and documentation, checked 23 September 2026, with Machines at the rates of its Ashburn (iad) region; check the links at the end before relying on them. Equal vCPU counts do not prove equal performance, and the services have not been benchmarked against each other.

At a glance

Cost for the same job

Take 1,000 runs of a 2 vCPU, 4 GiB sandbox. Each run lasts 60 seconds and keeps the CPU busy for 20 CPU-seconds, which is typical of an agent that spends most of its time waiting for a model. The Sprite is assumed to use all 4 GB for the whole minute. The Machine is a performance-2x with 4 GB.

TextRuntime   CPU    1,000 × 20 s / 3,600 × $0.025        = $0.14          Memory 1,000 × 60 s / 3,600 × 4 × $0.0075   = $0.50          Total                                          $0.64Sprites   CPU    1,000 × 20 s / 3,600 × $0.07         = $0.39          Memory 1,000 × 60 s / 3,600 × 4 × $0.04375  = $2.92          Total                                          $3.31Machines  Size   1,000 × 60 s / 3,600 × $0.0861       = $1.44

Sprites bill the memory a Sprite actually uses, so a job that uses 1 GB pays a quarter of that memory figure, $1.12 in total. A Sprite also stays awake for about 30 seconds after its last activity unless you delete it. A Machine bills its size for every second it is started, busy or not. Its performance vCPUs are whole cores kept for it, which Runtime's default shared CPU is not. A shared-cpu-2x Machine with 4 GB would cost about $0.50, but shared vCPUs are guaranteed 6.25% of a core each and start with a small burst allowance, so a new one would not fit 20 CPU-seconds into the minute.

With both CPUs busy for the whole minute, the same job costs $1.33 on Runtime, $5.25 on Sprites and $1.44 on Machines. Storage, network, plan fees, taxes and free credits are excluded from all three. See pricing for Runtime's terms.

Where Fly.io is stronger

• Regions. Machines run in 18 regions. Runtime runs in one.
• Size. Machines go up to 16 performance vCPUs and 128 GB of memory, with cores reserved for them. Every Sprite has 8 vCPUs and 100 GB of disk.
• Idle for almost nothing. A Sprite pauses itself when work stops and wakes on the next request, and its disk costs $0.02 per GB-month while it sleeps. Runtime's paused storage costs $0.08 per GB-month.
• Checkpoints. A Sprite checkpoints its whole filesystem in about a second. Runtime's snapshots and forks are paused while an issue is fixed; build a custom image to start many sandboxes from one setup.
• Platform and track record. Machines, volumes and Managed Postgres sit in the same account, Fly.io has run production workloads for years, and it lists SOC 2 Type II. Runtime opened public signup in September 2026 and has not completed an outside security audit.

Where Runtime is stronger

• Price. Measured CPU costs about a third of Sprites' rate, and reserved memory about a sixth of Sprites' rate for memory in use.
• Memory survives a pause. A paused Runtime sandbox keeps its processes for the retention you set, 1 to 365 days. A Sprite drops its memory when it goes cold, at a time you do not choose. Machine suspend keeps memory but is meant for Machines of up to 2 GB, and a Machine's root disk is temporary.
• Sized to the job. You set vCPUs and memory for each sandbox and are billed for no more. A Sprite's memory is managed by Fly and is not a fixed figure to plan against.
• Setup by the agent. An agent runs npx withruntime run --trial -- ..., shows you a link, and starts work once you approve it in the browser. No API key is copied into a prompt or a config file, and the MCP server reuses the same connection.
• Safe retries. Every write takes an idempotency key, and the SDKs retry with one automatically, so a lost response does not create a second sandbox.

Moving from Fly.io

Sprites:

JavaScriptimport { SpritesClient } from "@fly/sprites";const client = new SpritesClient(process.env.SPRITE_TOKEN);const sprite = await client.createSprite("my-sprite");const result = await sprite.execFile("python3", ["-c", "print(6 * 7)"]);console.log(result.stdout);await sprite.delete();

Runtime:

TypeScriptimport { Sandbox } from "withruntime";const box = await Sandbox.create({ funding: "trial" });try {  console.log((await box.exec(["python3", "-c", "print(6 * 7)"], { check: true })).stdout);} finally {  await box.stop();}

If you create a Machine for each job through the Machines API, create a Runtime sandbox instead and stop it when the job ends. To have a coding agent make the switch, test it and compare costs on your own workload, give it the prompt in migration. Keep Fly.io available until the same job passes on both.

Sources

• Fly.io pricing for Machines and Sprites
• Sprites and its pricing questions
• Sprites documentation and lifecycle and persistence
• Machine CPU performance
• Machine suspend and resume
• Fly Volumes
• Fly.io regions
• Runtime pricing, security and products