Google Agent Runtime vs smol machines

Google Agent Runtime hosts your agent code on Google Cloud and gives it sandboxes that run as an unprivileged user in a locked container. smol machines gives each agent its own microVM with its own kernel and Docker inside, built on an open-source engine you can also run on your own laptop or servers.

The companies and products

Google Agent Runtime

Google Agent Runtime is the agent hosting part of Gemini Enterprise Agent Platform on Google Cloud, renamed from Vertex AI Agent Engine in April 2026.

It is a hyperscaler service, not a sandbox company. Agent Runtime deploys agents you build with ADK, LangGraph, LangChain, AG2 or LlamaIndex and bills them only while they work on a turn. Next to it, Agent Sandbox gives those agents a place to run code: a Code Execution sandbox, a shell or custom container sandbox, and a Computer Use browser. All of them run as secure containers inside your Google Cloud project.

Kind of product: Managed agent hosting plus code, shell and browser sandboxes on Google Cloud
Former name: Vertex AI Agent Engine, renamed Agent Runtime in April 2026
Isolation: Secure container sandboxing; commands run as the unprivileged user appuser with no sudo
Launch stage: Shell and Computer Use sandboxes GA since 2026-09-09; custom containers, templates and snapshots launched in Preview on 2026-05-26
Regions: 23 locations across the US, Europe, Asia, Canada, Australia and Brazil
Billing: $0.085 per vCPU-hour and $0.009 per GiB-hour allocated, first 50 vCPU-hours and 100 GiB-hours free each month

smol machines

smol machines makes fast, isolated Linux microVMs that run the same way on your laptop, in their hosted cloud, or on your own servers.

The core is smolvm, an open-source microVM engine built on libkrun, where each machine has its own guest kernel. smol cloud is the paid hosted service that runs fleets of those machines behind a REST API and Node, Python and Rust SDKs. It is built for developers who want one VM model from local development to production, with live branching of running machines.

Isolation: Hardware-isolated microVM with its own guest kernel (libkrun)
Company: Founded 2026, Y Combinator Spring 2026, San Francisco, team of one listed
Open source: smolvm engine and smol SDK are open source and run on macOS, Linux and Windows hosts
Guests: Linux only; no Windows or macOS guests
Regions: No region field in the cloud create API
Uptime SLA: 99.95% on Pro, Startup and Enterprise

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. “28th cheapest of 366” means 27 of the other 365 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	Google Agent Runtime: price rank	smol machines: price rank	bochka: price rank
Software factory 100 at once · 4 vCPU / 8 GB · 2,200 sessions of 8 h a month smol machines runs Docker inside each microVM while Google's sandboxes have no root or Docker; bochka adds /dev/kvm, SSH and coding agents on top of Docker.	295th of 367, with limits $5,801 a month	73rd of 367, with limits $604 a month	3rd cheapest of 367 $634 a month
Always-on AI employees 50 machines 24/7 · 2 vCPU / 4 GB Google hosts the agent loop and bills only working turns, but a sandbox is deleted when its TTL ends; smol machines has no lifetime cap, and bochka adds a desktop and a credentials proxy.	28th cheapest of 366 $7,519 a month	148th of 366, with limits $1,038 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 Both fit short code runs: Google has a ready Python interpreter with no network, and smol machines has a one-minute minimum and a /code endpoint for Python and JavaScript.	254th of 345, with limits $275 a month	12th cheapest of 345 $140 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 smol machines wakes a stopped machine on the next command, while Google sandboxes are reached only through its API or your VPC; bochka gives each user HTTPS on up to 50 ports.	280th of 361, with limits $1,916 a month	7th cheapest of 361 $531 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 Both can branch a sandbox with its memory, so many rollouts start from one prepared state; smol machines does it from a running machine.	128th of 360, with limits $8,240 a month	111th of 360, with limits $6,978 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	79th cheapest of 364 $2,060 a month	36th cheapest of 364 $670 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 jobs that build containers need Docker, which smol machines has and Google's unprivileged sandboxes do not; bochka runs Docker and systemd on every VM.	98th cheapest of 377 $989 a month	66th cheapest of 377 $514 a month	4th cheapest of 377 $86 a month
24/7 dev boxes 1 machine 24/7 · 4 vCPU / 8 GB Neither offers SSH into a sandbox, so neither works well as a dev box you log into; bochka gives you SSH and a desktop.	311th of 368, with limits $241 a month	216th of 368, with limits $29 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 Google gives you a ready browser with a VNC view and a click and type API, smol machines leaves you to run your own Chromium, and bochka streams a full 60fps desktop.	283rd of 369, with limits $1,648 a month	90th of 369, with limits $156 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	102nd of 367, with limits $824 a month	176th of 367, with limits $136 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	53rd cheapest of 346 $515 a month	241st of 346, with limits $242 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	210th of 338, with limits $8,240 a month	148th of 338, with limits $4,344 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	260th of 360, with limits $412 a month	252nd of 360, with limits $377 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	Can't run it	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	Can't run it

Key features

Feature	Google Agent Runtime	smol machines	bochka
Isolation	Secure container sandboxing inside your Google Cloud project	libkrun microVM with its own guest kernel	Full VM with its own kernel on dedicated AMD Ryzen 9 9950X hosts
Root and Docker	Runs as appuser with no sudo; images must not need root; no Docker documented	Docker runs inside the VM, with its data on the machine's ext4 disk	Root, systemd and Docker on every machine
Nested virtualization	No /dev/kvm documented	Not exposed in the cloud create API; a local smolvm flag only	Yes, /dev/kvm for Android emulators and VMs
Shell access	execute_bash() API calls; each command runs in a new shell; no SSH	Command API, sessions and a WebSocket terminal capped at one hour per connection; no SSH	SSH, plus a command API and terminal
How long a sandbox lives	TTL of up to 7 days for a custom container and 14 days for Code Execution	No provider cap; an optional TTL you set yourself	No session cap on paid plans
Files after a stop	Pause keeps the file system and costs less (rate not published); deleted when the TTL ends	Filesystem survives a stop, memory paths like /tmp are emptied; stopped disk keeps billing	Disk saved every minute and on stop; a stopped sandbox costs nothing
Branching with memory	Snapshots keep memory and files; start many sandboxes from one snapshot	Branch a running machine with its memory and processes; checkpoints capture RAM to a file	Fork a running sandbox with its disk; the fork boots fresh
Reaching the sandbox	Through Google's API or a private endpoint in your VPC; no public URL documented	Up to 16 published ports through a returned URL or an authenticated connect route	HTTPS URLs for up to 50 ports, token-protected; raw TCP; dedicated IPv4 or IPv6
Outbound internet	Off unless the template turns it on; can route through your VPC with Cloud NAT, a static IP or a firewall	Blocked, open, or an allowlist of hosts and CIDR ranges	Open internet on every plan; no provider-side allowlist
Desktop and browser	A browser in a container with a VNC live view, a click and type API and CDP	No hosted desktop; a guide shows running your own Chromium	Linux desktop streamed at 60fps, Chromium and computer use built in
Coding agents	Managed Agents API (Preview) runs Google's Antigravity harness	Registry images with the Codex CLI and the Harbor eval harness, run through the command API	Claude Code, Codex, OpenCode and more preinstalled, with a prompt, steer and events API
Keeping API keys out of the sandbox	You provision and scope the credentials the agent uses	Cloud secrets are environment variables the guest can read	Credentials proxy for model providers and any HTTPS API; switch to another account when credits run out
Hosting your agent code	Deploys ADK, LangGraph, LangChain, AG2 and LlamaIndex agents; idle time between turns is not billed	No managed agent hosting; you run your loop in a machine	You run your own agent loop inside a sandbox
Where it runs	23 Google Cloud locations in the US, Europe, Asia, Canada, Australia and Brazil	No region choice in the cloud API; open-source smolvm runs on your own laptop or servers	EU only: Germany, Finland, France, with EU data residency

Every feature Battleships tracks (43)

Feature	Google Agent Runtime	smol machines	bochka
Full VM (own kernel)	No	Yes	Yes
Docker inside	No	Yes	Yes
Nested virtualization	No	No	Yes
Root	No	Not published	Yes
Systemd	Not published	Not published	Yes
Desktop GUI	No	No	Yes
Browser	Yes	No	Yes
Computer-use API	Yes	No	Yes
SSH	No	No	Yes
Persistent disk	Yes	Yes	Yes
Pause/resume	Yes	Yes	Yes
Automatic snapshots	Yes	No	Yes
Fork/clone	Yes	Yes	Yes
Live fork (no pause)	Yes	Yes	Yes
Memory fork	Yes	Yes	No
Custom image (Docker or snapshot)	Yes	Yes	Yes
≥24 h sessions	Yes	Yes	Yes
Idle auto-stop	No	Yes	No
Wake on request	No	Yes	No
HTTPS preview URLs	No	Yes	Yes
Raw TCP inbound	Not published	Not published	Yes
Public IPv4	No	No	No
Egress allowlist	Yes	Yes	No
Secret proxy	No	No	Yes
Secret proxy for any API	No	No	Yes
Preinstalled agents	Yes	Yes	Yes
Agent harness API	Yes	No	Yes
MCP server	No	Yes	No
GPU	No	No	No
Windows	No	No	No
Arm64	Yes	Yes	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	Yes	Yes
Usage per sandbox (API)	Yes	Yes	Yes
Audit logs	Not published	Not published	No
SSO	Yes	Yes	No
SOC 2	Yes	No	No
HIPAA	Yes	No	No
EU data residency	Yes	No	Yes
Zero data retention	Not published	Not published	Yes

Performance

Google Agent RuntimeNot measured

smol machinesNot measured

bochka26.69 runs/s

There is no comparable CPU measurement for Google Agent Runtime or smol machines: neither has been run on the StarSling hpc-sandbox-benchmarks CPU test. bochka did 26.69 Node.js build-and-test runs per second on that test at 4 vCPU / 8 GB. smol machines publishes a boot time under 200ms for smolvm, which is a start-time figure, not CPU speed.

Node.js build-and-test loop at 4 vCPU / 8 GB, higher is better. Measured with the open hpc-sandbox-benchmarks suite. Google Agent Runtime and smol machines 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	Google Agent Runtime, a month	smol machines, 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	$73 · Pay as you go	$25 · Standard	$20 · $20/mo
One agent that never stops 4 vCPU / 8 GB, 50 GB disk, running 24/7 all month	$301 · Pay as you go	$93 · Standard	$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	$3,626 · Pay as you go · with limits	$1,139 · Pro	$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	$1,030 · Pay as you go	$465 · Startup	$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	$2,060 · Pay as you go	$1,389 · Startup	$2,000 · $2000/mo · with limits

Google Agent Runtime: Google bills $0.085 per vCPU-hour and $0.009 per GiB-hour for what you allocate, with the first 50 vCPU-hours and 100 GiB-hours free each month. Sandboxes bill while they exist, and disk, egress and paused rates are not published.

smol machines: smol cloud charges a base fee for every hour a machine runs plus the CPU and memory the guest actually uses, with a one-minute minimum and disk billed even while stopped. Pro ($20 a month) and Startup ($150 a month) are fees on top of usage, not credit.

smol machines: Plans start at $20 a month, and the whole fee is usage credit spent per second while a sandbox runs. A stopped sandbox costs nothing and keeps its disk.

Limits in those scenarios

On Google, the 50-agent fleet does not fit because its sandboxes have no Docker inside, and every Google row leaves disk and egress unpriced because those rates are not published. A Google sandbox is also deleted when its TTL ends, 7 days at most for a custom container. smol machines caps machines by plan, 20 on Standard, 100 on Pro and 1,000 on Startup, with stopped machines still holding a slot, so the fleet needs Pro and the 1,000-job burst needs Startup. On bochka the burst is the problem: the $2,000 plan queues starts above 90 a minute.

Scenario	Google Agent Runtime	smol machines	bochka
One coding agent, workdays	disk beyond 0 GiB: price unknown egress price not published	None that bite	None that bite
One agent that never stops	disk beyond 0 GiB: price unknown egress price not published	None that bite	None that bite
50 agents in parallel	missing Docker inside disk beyond 0 GiB: price unknown egress price not published	None that bite	None that bite
Sandboxes for your users	disk beyond 0 GiB: price unknown egress price not published	None that bite	None that bite
1,000 short jobs at once	disk beyond 0 GiB: price unknown egress price not published	None that bite	max 2,400 starts/day (needs ~6,667) max 600 starts/hour (needs ~1,000) bursts above 90 starts/min are queued (a burst of 333 takes ~4 min to start)

Which one should you use?

Use Google Agent Runtime when

you build agents with ADK or LangGraph on Google Cloud and want them hosted inside your own project, network rules and regions, with short code runs in a locked sandbox.

A managed home for your agent code. Useful if you build agents with ADK or LangGraph: Agent Runtime hosts them and skips billing for idle time between turns.
Inside your Google Cloud network. Useful if agents must stay in a Google Cloud perimeter, with egress off by default and routed through your own firewall.
A ready browser and worldwide regions. Useful if you want a browser sandbox with a click and type API, running in the US, Europe or Asia.

Use smol machines when

you want each agent in its own microVM with Docker, live branches of a running machine with its memory, or one open-source engine from your laptop to your own servers.

A real VM with Docker inside. Useful if your agents build containers or need their own kernel: each smol machine is a microVM that runs Docker.
Live branches of a running machine. Useful for RL and test fan-out: branch a running machine with its memory and processes, paying the minimum once.
Open source, from laptop to your servers. Teams that want the same VM locally, in a hosted cloud and on their own servers can run one open-source engine.

Where bochka fits

If your agents need a whole computer rather than a place to run code, look at bochka. Google locks its sandboxes in a container with no root, and smol machines gives you a VM but no SSH, desktop or nested virtualization. bochka gives every agent a full VM with root, Docker, /dev/kvm, a desktop and coding agents built in.

Root, Docker and /dev/kvm on one machine

On Google, sudo apt install and docker compose fail because commands run as appuser. smol machines runs Docker but hides /dev/kvm, so Android emulators and nested VMs cannot start. bochka has root, Docker, systemd and /dev/kvm on every VM.

A desktop and public URLs for what agents build

Google's computer use is a browser only, reached through its API or your VPC, and smol machines has no hosted desktop and up to 16 ports. bochka streams a 60fps desktop and serves HTTPS on up to 50 ports, with SSH and raw TCP.

Coding agents and keys handled for you

Google runs only its own Antigravity harness, and smol cloud puts secrets in environment variables the guest can read. bochka ships Claude Code, Codex and more, driven from outside, with real keys kept out of the sandbox.

Use bochka when your agents need a whole machine for real work: root, Docker, /dev/kvm, SSH, a desktop and public URLs on a full VM that keeps its disk, with coding agents you drive from outside. Compare it one to one: bochka vs Google Agent Runtime and bochka vs smol machines.

Questions people ask

Is Google Agent Runtime cheaper than smol machines?

Not in the five scenarios we priced. One coding agent on workdays comes to $25 a month on smol machines and $73 on Google, and one agent running all month comes to $93 versus $301. Google's numbers assume a sandbox that exists all those hours; a Runtime agent that sits idle between turns bills less.

Which is faster, Google Agent Runtime or smol machines?

We have no comparable CPU measurement for either. bochka did 26.69 Node.js build-and-test runs per second on the StarSling CPU test at 4 vCPU / 8 GB. smol machines publishes a smolvm boot time under 200ms, which measures start time, not CPU speed.

Can Google Agent Runtime or smol machines run Docker?

smol machines can: Docker runs inside each microVM, with its data on the machine's ext4 disk. Google's sandboxes run as the unprivileged user appuser with no sudo, so Docker is not available. bochka runs Docker, systemd and /dev/kvm on every VM.

Can I fork a running sandbox with its memory?

Both can. smol machines branches a running machine into children that keep its memory and processes, and Google can start many sandboxes from one snapshot that keeps memory and files. bochka forks a running sandbox with its disk, and the fork boots fresh.

Can I self-host either one?

smol machines, yes: its smolvm engine is open source and runs on macOS, Linux and Windows hosts. Google Agent Runtime runs only on Google Cloud, inside your own project. bochka is a hosted service in the EU.

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