Sprites vs Beam
Sprites gives each agent a persistent Firecracker microVM that pauses when idle and wakes on the next request. Beam is a serverless GPU platform whose sandboxes are quick gVisor containers that run until you end them or their timer runs out.
The companies and products
Sprites
Sprites is Fly.io's product for agents: persistent Linux computers you create by API or CLI, which sleep when idle and wake on the next request.
Each Sprite is a Firecracker microVM with 8 vCPU, memory the platform manages, and a 100 GB ext4 disk that syncs to object storage. It runs one managed Ubuntu image with Claude Code, Codex, Gemini CLI and Cursor preinstalled, gets an HTTPS URL that wakes it, and bills only for the CPU and memory it actually uses while awake. It is built for coding agents, dev environments and user code that sit idle most of the time.
- Isolation
- Firecracker microVM per Sprite
- Regions
- Not selectable for Sprites
- Free start
- $30 trial credit per organization
Beam
Beam is a serverless cloud for GPU inference, sandboxes and background jobs, built on its open-source runtime Beta9.
Beam runs functions, REST endpoints, task queues, pods, sandboxes and VMs on CPUs and GPUs, all from a Python or TypeScript SDK. A sandbox is a container isolated with gVisor that starts in a second or two, lives until you terminate it or its time to live runs out, and can be saved as a filesystem image or a memory snapshot. Beam VMs are a separate CPU product: a microVM with its own kernel, systemd and a root disk that stays when it stops. Much of Beam is a GPU serverless platform for AI teams.
- Bring your own cloud
- Management fee per vCPU and GB of RAM, on top of your own cloud bill
Which use cases each one fits
For each use case, Battleships prices every sandbox provider on the same workload and sorts them from the cheapest monthly bill up. “63rd cheapest of 377” means 62 of the other 376 providers run that workload, with every feature it needs, for less. “With limits” means the provider runs it but misses something, so it is listed after every full match. Open a use case for its whole ranking and what each provider misses.
| Use case and its workload | Sprites: price rank | Beam: price rank | bochka: price rank |
|---|---|---|---|
| Software factory 100 at once · 4 vCPU / 8 GB · 2,200 sessions of 8 h a month | 66th of 367, with limits $546 a month | 69th of 367, with limits $551 a month | 3rd cheapest of 367 $634 a month |
| Always-on AI employees 50 machines 24/7 · 2 vCPU / 4 GB An assistant that waits all month loses open connections on every Sprite pause, while a Beam VM or a bochka sandbox just keeps running. | 157th of 366, with limits $1,166 a month | 115th of 366, with limits $651 a month | 5th cheapest of 366 $657 a month |
| Code interpreter bursts 100 at once · 1 vCPU / 2 GB · 200,000 sessions of 1 min a month Beam fits short code runs better here: its sandboxes start in a second or two, bill per second and end on their own when the timer runs out. | 93rd of 345, with limits $140 a month | 8th cheapest of 345 $117 a month | 186th of 345, with limits $2,000 a month |
| Sandboxes for your users 300 at once · 2 vCPU / 4 GB · 30,000 sessions of 23 min a month Beam gives each user a quick container and Sprites a persistent microVM, but Sprites does not publish how many can run at once on pay as you go; bochka gives each user a full VM with hosting. | 56th of 361, with limits $428 a month | 3rd cheapest of 361 $290 a month | Cheapest of 361 $209 a month |
| RL rollouts 1,000 at once · 2 vCPU / 4 GB · 1,000,000 sessions of 3 min a month Sprites bills the CPU it actually uses, while Beam sandboxes bill the CPU and memory you request until they end. | 105th of 360, with limits $6,540 a month | 341st of 360, with limits $939 a month | 34th of 360, with limits $2,000 a month |
| Agent evals 250 at once · 4 vCPU / 8 GB · 15,000 sessions of 20 min a month | 125th of 364, with limits $545 a month | 13th cheapest of 364 $251 a month | 10th cheapest of 364 $200 a month |
| CI runners 40 at once · 8 vCPU / 16 GB · 6,000 sessions of 12 min a month CI that builds Android apps or VM images needs /dev/kvm, which neither Sprites nor Beam documents and every bochka sandbox has. | 63rd cheapest of 377 $476 a month | 12th cheapest of 377 $171 a month | 4th cheapest of 377 $86 a month |
| 24/7 dev boxes 1 machine 24/7 · 4 vCPU / 8 GB Both keep work between days: a Sprite keeps its 100 GB disk, a Beam VM keeps its 50 GiB root disk, and bochka saves the disk every minute and on stop. | 213th of 368, with limits $27 a month | 13th cheapest of 368 $21 a month | 18th cheapest of 368 $26 a month |
| Computer-use agents 50 at once · 4 vCPU / 8 GB · 20,000 sessions of 15 min a month Neither Sprites nor Beam has a desktop or browser product; bochka streams a 60fps desktop with Chromium for computer use. | 85th of 369, with limits $136 a month | 111th of 369, with limits $237 a month | 6th cheapest of 369 $200 a month |
| Browser-use agents 50 at once · 2 vCPU / 4 GB · 30,000 sessions of 10 min a month | 171st of 367, with limits $122 a month | 195th of 367, with limits $176 a month | 7th cheapest of 367 $200 a month |
| Scraping & bots (startup scale) 50 at once · 1 vCPU / 2 GB · 100,000 sessions of 3 min a month | 229th of 346, with limits $206 a month | 200th of 346, with limits $131 a month | 6th cheapest of 346 $90 a month |
| Mass scraping & bots (undetectable) 1,000 at once · 1 vCPU / 2 GB · 3,000,000 sessions of 2 min a month | 141st of 338, with limits $4,113 a month | 42nd of 338, with limits $923 a month | 71st of 338, with limits $1,800 a month |
| Parallel red teaming 200 at once · 2 vCPU / 4 GB · 5,000 sessions of 30 min a month | 210th of 360, with limits $223 a month | 175th of 360, with limits $155 a month | 2nd cheapest of 360 $200 a month |
| GPU eval jobs 10 at once · 8 vCPU / 32 GB · 500 sessions of 30 min a month Beam has GPUs from RTX 4090 to H100 and B200; Sprites and bochka are CPU only. | Can't run it | Cheapest of 98 $458 a month | Can't run it |
| macOS agents 5 at once · 4 vCPU / 8 GB · 1,000 sessions of 20 min a month | Can't run it | Can't run it | Can't run it |
Key features
| Feature | Sprites | Beam | bochka |
|---|---|---|---|
| Isolation | Firecracker microVM with its own kernel | gVisor container by default; separate Beam VMs are CPU microVMs with their own kernel | Full VM with its own kernel on dedicated AMD Ryzen 9 9950X hosts |
| Machine size | Fixed 8 vCPU and 100 GB disk; memory managed and scaled by the platform | You request CPU cores and memory per sandbox; the maximum size is not published | You choose; up to 16 vCPU / 32 GB on the $100 plan and above |
| Docker and systemd | Root and Docker, with rough edges users report; no systemd | Docker inside sandboxes with docker_enabled; systemd only in Beam VMs | Root, Docker and systemd, like a normal Ubuntu server |
| Nested virtualization | No /dev/kvm in the docs | Not documented | Yes, /dev/kvm for Android emulators and VMs |
| Idle behavior | Pauses about 30 seconds after activity stops and wakes on the next request in 100 to 500 ms | A sandbox runs and bills until you terminate it or its time to live ends, 10 minutes by default | Runs until you stop it or its time to live ends; a stopped sandbox costs nothing |
| Disk between runs | Persistent 100 GB disk, with checkpoints that restore in place | A sandbox ends with its time to live unless you save an image or use a volume; a Beam VM keeps a 50 GiB root disk | Disk saved every minute and on stop; a stopped sandbox keeps it for free |
| Fork and snapshots | No fork in the public API or CLI | Memory snapshot of a running sandbox with its processes, restored into new sandboxes | Fork a running sandbox with its disk into a new one |
| GPUs | No, CPU only | GPU sandboxes and serverless GPUs up to H100, H200 and B200 | No, CPU only |
| Reaching the sandbox | One HTTPS URL to one HTTP port, private by default; other ports and SSH through the sprite proxy CLI | A public HTTPS URL per exposed port with no built-in auth; no raw TCP or dedicated IP | HTTPS URLs for up to 50 ports, token-protected; raw TCP; dedicated IPv4 or IPv6; SSH |
| Outbound rules | Optional DNS-based domain allowlist; private IPs always blocked | Block all outbound traffic, or allow up to 10 CIDR ranges, changeable while running | Open internet, no provider-side allowlist |
| Keeping keys out of the sandbox | Connectors gateway holds the token for GitHub, Slack or any HTTP API, with path allow and block lists | Secrets are exposed as environment variables inside the sandbox | Credentials proxy for model providers and any HTTPS API; switch a credential to another account when credits run out |
| Coding agents | Claude Code, Codex, Gemini CLI and Cursor preinstalled, run through exec or a console | None preinstalled; you install and run them through process exec | Seven agents preinstalled, with a prompt, steer and events API to drive them from outside |
| Desktop and browser | Headless; no desktop or browser product | No desktop or browser product | 60fps Linux desktop with Chromium, computer use and an embeddable stream |
| Regions and self-hosting | Region not selectable; no self-hosting | US only; Beta9 runtime is AGPL-3.0 and free to self-host, or bring your own cloud for a fee | EU only (Germany, Finland, France), with EU data residency; no self-hosting |
Every feature Battleships tracks (43)
| Feature | Sprites | Beam | bochka |
|---|---|---|---|
| Full VM (own kernel) | Yes | No | Yes |
| Docker inside | Yes | Yes | Yes |
| Nested virtualization | No | No | Yes |
| Root | Yes | Yes | Yes |
| Systemd | No | No | Yes |
| Desktop GUI | No | No | Yes |
| Browser | No | No | Yes |
| Computer-use API | No | No | Yes |
| SSH | No | Yes | Yes |
| Persistent disk | Yes | Yes | Yes |
| Pause/resume | Yes | No | Yes |
| Automatic snapshots | Yes | No | Yes |
| Fork/clone | No | Yes | Yes |
| Live fork (no pause) | No | Yes | Yes |
| Memory fork | No | Yes | No |
| Custom image (Docker or snapshot) | Yes | Yes | Yes |
| ≥24 h sessions | Yes | Yes | Yes |
| Idle auto-stop | Yes | No | No |
| Wake on request | Yes | No | No |
| HTTPS preview URLs | Yes | Yes | Yes |
| Raw TCP inbound | No | No | Yes |
| Public IPv4 | No | No | No |
| Egress allowlist | Yes | Yes | No |
| Secret proxy | Yes | No | Yes |
| Secret proxy for any API | Yes | No | Yes |
| Preinstalled agents | Yes | No | Yes |
| Agent harness API | No | No | Yes |
| MCP server | Yes | Yes | No |
| GPU | No | Yes | No |
| Windows | No | No | No |
| Arm64 | No | No | No |
| Self-hosting | No | Yes | No |
| BYOC | No | Yes | No |
| Open source | No | Yes | No |
| Scoped API keys | Not published | Not published | Yes |
| Spend limits | Not published | Not published | Yes |
| Usage per sandbox (API) | No | No | Yes |
| Audit logs | Not published | Not published | No |
| SSO | Yes | No | No |
| SOC 2 | Yes | Yes | No |
| HIPAA | Yes | Yes | No |
| EU data residency | No | Not published | Yes |
| Zero data retention | Not published | Not published | Yes |
Performance
There is no comparable CPU measurement for either Sprites or Beam: neither has a result on the StarSling hpc-sandbox-benchmarks test we use, so we cannot say which is faster. bochka did 26.69 runs per second on that test at 4 vCPU / 8 GB, on dedicated AMD Ryzen 9 9950X hosts.
Node.js build-and-test loop at 4 vCPU / 8 GB, higher is better. Measured with the open hpc-sandbox-benchmarks suite. Sprites and Beam have no published run in this suite yet, so there is no like-for-like number to compare.
Pricing in five scenarios
Each bill is priced from the providers' public price lists by the open Battleships engine, with the cheapest plan that runs the scenario.
| Scenario | Sprites, a month | Beam, a month | bochka, a month |
|---|---|---|---|
| One coding agent, workdays 4 vCPU / 8 GB, 50 GB disk, 8 hours a day, 22 days a month, files kept between days | $23 · Pay-as-you-go | $5 · Developer | $20 · $20/mo |
| One agent that never stops 4 vCPU / 8 GB, 50 GB disk, running 24/7 all month | $92 · Pay-as-you-go | $22 · Developer | $26 · $20/mo |
| 50 agents in parallel 50 machines of 4 vCPU / 8 GB at once, 8-hour sessions, 1,100 sessions a month, Docker inside | $1,120 · Pay-as-you-go | $410 · Team | $317 · $20/mo × 3 seats |
| Sandboxes for your users 2 vCPU / 4 GB, 30,000 sessions of 10 minutes a month, up to 300 at once | $314 · Pay-as-you-go · with limits | $191 · Team | $200 · $100/mo × 2 seats |
| 1,000 short jobs at once 2 vCPU / 4 GB, 1,000 at once, 3 minutes each, 200,000 jobs a month | $1,134 · Pay-as-you-go · with limits | $259 · Team | $2,000 · $2000/mo · with limits |
Sprites: Sprites bills CPU time actually used at $0.0385 per CPU-hour and actual memory at $0.021875 per GB-hour, only while the Sprite is awake, plus storage on the bytes you write. Optional plans include fixed CPU, memory and storage allowances that are not credit.
Beam: Beam sandboxes bill per second for each CPU core (two vCPU) and GiB of RAM you request, until you terminate them or their time to live ends, so an idle tail is billed too. Developer has no fee, and Team costs $89 a month plus usage, with no credit.
Beam: Plans start at $20 a month, and the whole fee is usage credit. You pay per second while a sandbox runs, and a stopped sandbox costs nothing and keeps its disk.
Limits in those scenarios
Sprites does not publish how many Sprites can run at once on pay as you go, so 300 sandboxes for your users and 1,000 jobs at once are not confirmed there, and creation is 10 a minute without a plan. Beam's Developer plan allows 30 CPU containers at once, so 50 parallel agents need the Team plan, which allows 1,000 and fits both bursts. Beam publishes no price for extra disk, so the scenarios count no disk cost for it. bochka's $2,000 plan queues starts at 1,000 short jobs at once.
| Scenario | Sprites | Beam | bochka |
|---|---|---|---|
| One coding agent, workdays | None that bite |
| None that bite |
| One agent that never stops | None that bite |
| None that bite |
| 50 agents in parallel |
|
| None that bite |
| Sandboxes for your users |
|
| None that bite |
| 1,000 short jobs at once |
|
|
|
Which one should you use?
Use Sprites when
your agents or apps sit idle most of the day and should wake on a request, keep a persistent disk without extra steps, or need a domain allowlist and API connectors.
- Sleeps when idle, wakes on request. For agents and apps idle most of the day, a Sprite stops billing compute and wakes on the next request.
- A persistent machine by default. Each Sprite keeps its 100 GB disk and installed software between uses, with no image to save first.
- Agents and API keys handled for you. Coding agents come preinstalled, and Connectors keep tokens outside the Sprite with per-path allow and block lists.
Use Beam when
your work needs GPUs, many short sandboxes that start fast, memory snapshots, US hosting, or a runtime you can self-host.
- GPUs in the same platform. For work that needs a GPU, Beam offers GPU sandboxes and serverless GPUs from RTX 4090 to H100, H200 and B200.
- Fast sandboxes with memory snapshots. Sandboxes start in a second or two, and a memory snapshot of a running one can start new copies.
- Open source and your own cloud. The Beta9 runtime is AGPL-3.0 and free to self-host, and Beam can also run in your own cloud for a fee.
Where bochka fits
Sprites and Beam both give an agent a Linux machine, but each trims it: a Sprite is a fixed, headless box with no systemd, and a Beam sandbox is a container that ends with its timer. If your agents install things, run services, test apps in a browser or serve ports for hours, look at bochka, where every sandbox is a full VM with a desktop and hosting built in.
A full VM with systemd and /dev/kvm
Sprites has no systemd and restricts Linux capabilities, so some Docker images misbehave; a Beam sandbox is a gVisor container with systemd only in Beam VMs. Neither documents /dev/kvm, so Android emulators and nested VMs have nothing to start on.
Hosting with access control and raw TCP
A Sprite exposes one HTTP port, and other ports go through the sprite proxy CLI on your own machine. A Beam port URL is public with no built-in auth, and neither offers raw TCP, so a database or game server cannot be reached.
A desktop, and agents driven from outside
Neither has a desktop, so a computer-use agent needs a display server, browser and stream you build yourself. On both you start agents through exec and write your own code to prompt and watch them; bochka has an API for that.
Use bochka when your agents need a full machine for hours: systemd, Docker, emulators, many ports and raw TCP, a desktop and browser, forks, and an API to drive the agents inside from outside. Compare it one to one: bochka vs Sprites and bochka vs Beam.
Questions people ask
Is Sprites cheaper than Beam?
In the five scenarios we priced, Beam costs less: one agent that never stops is $22 against $92 a month, and 50 agents in parallel are $410 against $1,120. Beam publishes no price for extra disk, so no disk is counted for it, and Sprites bills real CPU use, so a mostly idle workload can cost less on Sprites than these estimates.
Which is faster, Sprites or Beam?
We cannot say: neither has a result on the CPU benchmark we use. Sprites says it wakes in 100 to 500 ms from a pause, and Beam says its sandboxes cold-boot in 1 to 3 seconds.
Can Sprites and Beam run Docker?
Yes, both. Beam needs docker_enabled on the sandbox, and Sprites users report that docker exec fails for containers whose main process is not root. bochka runs Docker, systemd and /dev/kvm in every sandbox.
Does Sprites or Beam have GPUs?
Beam does, with GPU sandboxes and serverless GPUs from RTX 4090 up to H100, H200 and B200. Sprites is CPU only, and so is bochka.
What happens to my files when the sandbox stops?
A Sprite keeps its 100 GB disk when it pauses. A Beam sandbox ends with its time to live unless you save an image, a memory snapshot or a volume, while a Beam VM keeps its root disk. bochka saves the disk every minute and keeps it while stopped.
Is bochka SOC 2 compliant?
SOC 2 is in progress. We're open about where we stand: live status at status.bochka.xyz and our data retention policy at docs.bochka.xyz/data-retention.
Try bochka
Install the CLI, then run bochka new.
Product preview