bochka vs Runtime
Both give each agent a Linux VM with its own kernel. Runtime is built for many short, mostly idle runs that pause with their memory, while bochka gives a fuller machine for long agent work, with nested virtualization and coding agents built in, hosted in the EU.
Where bochka stands out
A full VM that runs like a server
Every bochka sandbox has root, Docker, systemd and /dev/kvm, so it can run Android emulators, nested VMs and services that start again after a resume. Runtime gives root and Docker, but its docs do not offer nested virtualization or document systemd, and its Daytona drop-in refuses the kvm option by name.
Coding agents you drive from outside
Claude Code, Codex, OpenCode and other agents come preinstalled in each bochka sandbox, and you prompt, steer and follow them through one API. The credentials proxy keeps real keys out of the sandbox and can switch a credential to another account when one runs out of credits.
Your data stays in the EU
bochka runs only in the EU, in Germany, Finland and France, with EU data residency and zero data retention. Runtime runs everything in one region, in Virginia, United States.
The companies and products
bochka
bochka.xyz runs sandboxes for AI agents: each one is a full Linux VM with its own kernel.
You start a machine with one command or one API call, then SSH in, run Docker, open a desktop, or let a built-in agent (Claude Code, Codex, OpenCode and others) work in it. The disk stays between sessions, and a stopped sandbox costs nothing.
- Isolation
- Full VM per sandbox, own kernel
- Regions
- EU: Germany, Finland, France
Runtime
Runtime (withruntime.com) is a cloud built for AI agents whose first product is sandboxes: Linux microVMs an agent creates, drives and stops by API, CLI, MCP or SDK.
Each Runtime sandbox is a Firecracker microVM with its own kernel, started as a copy of a machine that booted once, so it is running about 100 ms after the create request. It pauses itself when idle with its memory kept and wakes on the next command, and it comes with forks, custom images, previews, egress rules, secrets the sandbox never sees, a desktop and a long list of network products. It is built for teams that run many agent jobs that spend most of their time waiting on a model, and it offers drop-in SDKs for code written for E2B, Daytona, Vercel Sandbox and Blaxel.
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. “3rd cheapest of 367” means 2 of the other 366 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 | bochka: price rank | Runtime: price rank |
|---|---|---|
| Software factory 100 at once · 4 vCPU / 8 GB · 2,200 sessions of 8 h a month A software factory that builds Android apps, runs VMs or needs systemd services gets /dev/kvm and systemd on bochka; Runtime offers neither in its docs. | 3rd cheapest of 367 $634 a month | 4th cheapest of 367 $895 a month |
| Always-on AI employees 50 machines 24/7 · 2 vCPU / 4 GB Both fit: Runtime can keep an assistant paused with its memory between tasks, while bochka keeps it running on a full VM with its disk saved every minute. | 5th cheapest of 366 $657 a month | 8th cheapest of 366 $1,090 a month |
| Code interpreter bursts 100 at once · 1 vCPU / 2 GB · 200,000 sessions of 1 min a month Runtime is built for this: sandboxes running in about 100 ms, a pause that keeps memory, and CPU billed only while code uses it. | 186th of 345, with limits $2,000 a month | 3rd cheapest of 345 $64 a month |
| Sandboxes for your users 300 at once · 2 vCPU / 4 GB · 30,000 sessions of 23 min a month 300 user sandboxes at once are above a Runtime account's starting limit, so it needs a raise from support; Runtime's wake on request suits users who come and go. | Cheapest of 361 $209 a month | 51st of 361, with limits $371 a month |
| RL rollouts 1,000 at once · 2 vCPU / 4 GB · 1,000,000 sessions of 3 min a month | 34th of 360, with limits $2,000 a month | 64th of 360, with limits $3,752 a month |
| Agent evals 250 at once · 4 vCPU / 8 GB · 15,000 sessions of 20 min a month | 10th cheapest of 364 $200 a month | 109th of 364, with limits $370 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 nested virtualization, which bochka has and Runtime does not document. | 4th cheapest of 377 $86 a month | 30th cheapest of 377 $300 a month |
| 24/7 dev boxes 1 machine 24/7 · 4 vCPU / 8 GB A dev box that runs all month suits bochka, where it keeps running and a stop costs nothing; Runtime bills a stopped sandbox's disk as storage. | 18th cheapest of 368 $26 a month | 37th cheapest of 368 $45 a month |
| Computer-use agents 50 at once · 4 vCPU / 8 GB · 20,000 sessions of 15 min a month Both have a Linux desktop for computer use; bochka streams it at 60fps with Chromium ready, and Runtime installs its desktop on first start and can record it to MP4. | 6th cheapest of 369 $200 a month | 7th cheapest of 369 $241 a month |
| Browser-use agents 50 at once · 2 vCPU / 4 GB · 30,000 sessions of 10 min a month Runtime keeps browsers out of its image to keep it small, so each sandbox installs Chromium or uses a custom image; bochka ships Chromium ready on its desktop. | 7th cheapest of 367 $200 a month | 55th of 367, with limits $121 a month |
| Scraping & bots (startup scale) 50 at once · 1 vCPU / 2 GB · 100,000 sessions of 3 min a month | 6th cheapest of 346 $90 a month | 9th cheapest of 346 $132 a month |
| Mass scraping & bots (undetectable) 1,000 at once · 1 vCPU / 2 GB · 3,000,000 sessions of 2 min a month | 71st of 338, with limits $1,800 a month | 98th of 338, with limits $2,568 a month |
| Parallel red teaming 200 at once · 2 vCPU / 4 GB · 5,000 sessions of 30 min a month | 2nd cheapest of 360 $200 a month | 18th of 360, with limits $138 a month |
| GPU eval jobs 10 at once · 8 vCPU / 32 GB · 500 sessions of 30 min a month | Can't run it | 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 |
Key features
Every feature Battleships tracks (43)
| Feature | bochka | Runtime |
|---|---|---|
| Full VM (own kernel) | Yes | Yes |
| Docker inside | Yes | Yes |
| Nested virtualization | Yes | No |
| Root | Yes | Yes |
| Systemd | Yes | Not published |
| Desktop GUI | Yes | Yes |
| Browser | Yes | Yes |
| Computer-use API | Yes | Yes |
| SSH | Yes | Yes |
| Persistent disk | Yes | Yes |
| Pause/resume | Yes | Yes |
| Automatic snapshots | Yes | Yes |
| Fork/clone | Yes | Yes |
| Live fork (no pause) | Yes | No |
| Memory fork | No | Yes |
| Custom image (Docker or snapshot) | Yes | Yes |
| ≥24 h sessions | Yes | Yes |
| Idle auto-stop | No | Yes |
| Wake on request | No | Yes |
| HTTPS preview URLs | Yes | Yes |
| Raw TCP inbound | Yes | Yes |
| Public IPv4 | No | Yes |
| Egress allowlist | No | Yes |
| Secret proxy | Yes | Yes |
| Secret proxy for any API | Yes | Yes |
| Preinstalled agents | Yes | Yes |
| Agent harness API | Yes | Yes |
| MCP server | No | Yes |
| GPU | No | No |
| Windows | No | No |
| Arm64 | No | No |
| Self-hosting | No | No |
| BYOC | No | No |
| Open source | No | No |
| Scoped API keys | Yes | Yes |
| Spend limits | Yes | Yes |
| Usage per sandbox (API) | Yes | Yes |
| Audit logs | No | Yes |
| SSO | No | Yes |
| SOC 2 | No | No |
| HIPAA | No | No |
| EU data residency | Yes | No |
| Zero data retention | Yes | Not published |
Performance
There is no comparable measurement: Runtime was not in the StarSling hpc-sandbox-benchmarks run where bochka did 26.69 runs per second at 4 vCPU / 8 GB. Runtime publishes its own start-time medians, which measure how fast a sandbox starts, not how fast it does CPU work. Its sandboxes run on AMD EPYC servers with shared CPU above a guaranteed floor, or reserved CPU if you ask.
Node.js build-and-test loop at 4 vCPU / 8 GB, higher is better. Measured with the open hpc-sandbox-benchmarks suite. Runtime has 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 | bochka, a month | Runtime, 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 | $20 · $20/mo | $18 · Prepaid paid account |
| One agent that never stops 4 vCPU / 8 GB, 50 GB disk, running 24/7 all month | $26 · $20/mo | $65 · Prepaid paid account |
| 50 agents in parallel 50 machines of 4 vCPU / 8 GB at once, 8-hour sessions, 1,100 sessions a month, Docker inside | $317 · $20/mo × 3 seats | $782 · Prepaid paid account |
| Sandboxes for your users 2 vCPU / 4 GB, 30,000 sessions of 10 minutes a month, up to 300 at once | $200 · $100/mo × 2 seats | $214 · Prepaid paid account · with limits |
| 1,000 short jobs at once 2 vCPU / 4 GB, 1,000 at once, 3 minutes each, 200,000 jobs a month | $2,000 · $2000/mo · with limits | $750 · Prepaid paid account · with limits |
bochka: You pick a monthly plan from $20, and all of it becomes usage credit spent per second on running sandboxes. A stopped sandbox costs nothing and keeps its disk.
Runtime: Runtime bills CPU only while code uses it, above a floor of 50 millicores per sandbox, plus the memory you reserve, from prepaid credit with no plan fee. Idle sandboxes pause after 60 seconds and then pay only storage, which also covers stopped sandboxes and a running sandbox's disk past its first 10 GiB.
Limits in those scenarios
A paid Runtime account starts with a cap on sandboxes at once and on total running vCPU and memory, 200 vCPU and 400 GiB, which 50 agents of 4 vCPU fill exactly. 300 user sandboxes at once and 1,000 short jobs at once are above that starting limit, so both need a raise from support, which its docs say usually comes the same day. bochka counts sandboxes by plan, from 100 to 2,000, plus starts per minute, so the 1,000-job burst gets queued and needs more starts per day than the $2,000 plan allows. The Runtime figures include its storage charge for a running disk past the first 10 GiB, counted on the full disk size, so they run a little high for a disk that is mostly empty.
| Scenario | bochka | Runtime |
|---|---|---|
| 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 | None that bite |
| Sandboxes for your users | None that bite |
|
| 1,000 short jobs at once |
|
|
Which one should you use?
Use Runtime when
you run many short agent jobs that sit idle waiting on a model and should pause with their memory, or when your sandboxes must run in the US behind strict egress rules.
- Memory pause and instant wake. Useful for agents that wait on a model most of the time: an idle sandbox pauses with its memory and wakes on the next call.
- Network rules and team controls. Useful when agents must reach only chosen hosts, or when a security team wants SSO, SCIM and an audit log on day one.
- US region and bigger memory. Useful for US-hosted products and memory-heavy jobs: it runs in Virginia, with up to 64 GiB in one sandbox.
Use bochka when
your agents do long, real work: builds, Docker, emulators and a desktop on a full VM with systemd and /dev/kvm, coding agents built in, and your data kept in the EU.
- A full VM that runs like a server. An agent that builds an Android app or tests a VM image needs /dev/kvm, and there is no workaround on Runtime. Without systemd, every service an agent sets up has to be started again by your code.
- Coding agents you drive from outside. On Runtime you install each agent in every sandbox or bake it into an image, then write the loop that runs it. Its AI SDK adapter page says no Claude Code or Codex bridge has run on Runtime yet.
- Your data stays in the EU. If your users or contracts need code and data kept in the EU, a US-only sandbox is a blocker before any feature matters. On Runtime there is no region to choose.
Questions people ask
Is bochka cheaper than Runtime?
It depends on how busy the machine is. For one agent running all month, bochka comes to $26 a month and Runtime to $65, and for 50 agents in parallel $317 against $782. Runtime is cheaper for one agent on workdays ($18 against $20) and for 1,000 short jobs at once ($750 against $2,000), though neither fits that burst without higher limits.
Can bochka pause a sandbox with its memory like Runtime?
No. bochka saves the disk every minute and when the sandbox stops, so files survive and systemd services start again, but resuming boots the machine. Runtime pauses with memory and running processes and wakes them on the next call.
Can I run Android emulators or nested VMs on Runtime?
Runtime's docs do not offer /dev/kvm inside a sandbox, and its Daytona drop-in refuses the kvm option by name. bochka exposes /dev/kvm on every machine, so Android emulators and nested VMs run there.
Where do bochka and Runtime run?
bochka runs only in the EU, in Germany, Finland and France, with EU data residency and zero data retention. Runtime runs everything in one region, in Virginia, United States.
Do both keep API keys out of the sandbox?
Yes. Both put a placeholder in the sandbox and add the real value on HTTPS to the hosts you choose. bochka's credentials proxy can also switch a credential to another account when one runs out of credits.
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.
Start a sandbox
Install the CLI, then run bochka new.
Product preview