Daytona vs Google Agent Runtime
Daytona is a sandbox cloud: you create containers or VMs with root, Docker, SSH and preview URLs, and add GPUs or Windows when you need them. Google Agent Runtime, once called Vertex AI Agent Engine, hosts your agent code on Google Cloud and gives it sandboxes that run as an unprivileged user with no Docker.
The companies and products
Daytona
Daytona is a cloud for running AI-generated code: you create sandboxes from code through its API and SDKs.
By default a Daytona sandbox is a Linux container with its own namespaces and reserved vCPU, memory and disk. You can also pick a Linux VM class (pause, fork, memory snapshots, /dev/kvm), a Windows VM class, or a GPU class with Nvidia and AMD cards. It is built for teams that run agent code, code interpreters and evals through Python, TypeScript, Ruby, Go or Java SDKs.
- Founded
- 2023
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.
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. “15th cheapest of 367” means 14 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 | Daytona: price rank | Google Agent Runtime: price rank | bochka: price rank |
|---|---|---|---|
| Software factory 100 at once · 4 vCPU / 8 GB · 2,200 sessions of 8 h a month Daytona fits, with root and Docker in every class; Google's sandboxes have no sudo or Docker, so installs and compose stacks fail there, and bochka has both plus /dev/kvm on every VM. | 15th cheapest of 367 $4,111 a month | 295th of 367, with limits $5,801 a month | 3rd cheapest of 367 $634 a month |
| Always-on AI employees 50 machines 24/7 · 2 vCPU / 4 GB All three fit, but a Google sandbox is deleted when its TTL ends (7 days at most for a custom container), while Daytona and bochka have no default session cap. | 24th cheapest of 366 $6,104 a month | 28th cheapest of 366 $7,519 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 Daytona fits short runs best here: it creates up to 600 sandboxes a minute on Tier 4, while Google's Code Execution sandbox is a ready Python interpreter with no network. | 25th cheapest of 345 $271 a month | 254th of 345, with limits $275 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 300 sandboxes of 2 vCPU need 600 vCPU, more than Daytona's Tier 4 pool of 500, and Google fits the size but gives your users no public URL; bochka serves HTTPS on up to 50 ports per sandbox. | 154th of 361, with limits $2,000 a month | 280th of 361, with limits $1,916 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 | 130th of 360, with limits $8,261 a month | 128th of 360, with limits $8,240 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 | 189th of 364, with limits $2,000 a month | 79th cheapest of 364 $2,060 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 | 308th of 377, with limits $805 a month | 98th cheapest of 377 $989 a month | 4th cheapest of 377 $86 a month |
| 24/7 dev boxes 1 machine 24/7 · 4 vCPU / 8 GB Google has no SSH into a sandbox and runs each command in a new shell, while Daytona and bochka both let you SSH in. | 183rd of 368, with limits $245 a month | 311th of 368, with limits $241 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 Daytona has a VNC desktop and a computer-use API on Linux and Windows, Google gives you only a browser, and bochka streams a 60fps desktop with Chromium. | 26th cheapest of 369 $1,198 a month | 283rd of 369, with limits $1,648 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 All three run a real Chromium you can drive over CDP; Google keeps outbound internet off unless the template turns it on, and Daytona opens it from Tier 3. | 93rd of 367, with limits $598 a month | 102nd of 367, with limits $824 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 | 38th cheapest of 346 $404 a month | 53rd cheapest of 346 $515 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 | 202nd of 338, with limits $8,073 a month | 210th of 338, with limits $8,240 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 | 12th cheapest of 360 $2,000 a month | 260th of 360, with limits $412 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 Only Daytona fits: it rents Nvidia and AMD GPUs by the hour, and neither Google's sandboxes nor bochka have GPUs. | 20th cheapest of 98 $1,190 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 | Can't run it |
Key features
| Feature | Daytona | Google Agent Runtime | bochka |
|---|---|---|---|
| Isolation | Container by default; Linux VM and Windows VM classes have their own kernel | Secure container sandboxing inside your Google Cloud project | Every sandbox is a full VM with its own kernel |
| Root, Docker and nested virtualization | Root and Docker in all classes; /dev/kvm only on Linux VMs, once KVM is turned on for your organization | Runs as appuser with no sudo; images must not need root; no Docker or /dev/kvm documented | Root, systemd, Docker and /dev/kvm on every machine |
| CPU speed (Node.js build-and-test, 4 vCPU / 8 GB) | 21.52 runs/s on the Linux VM class; the default container class reported no result | Not measured | 26.69 runs/s |
| Reaching the sandbox | HTTPS preview URLs on any port, token-protected or public; SSH; no raw TCP or public IP | Through Google's API or a private endpoint in your VPC; no SSH or public URL documented | HTTPS URLs for up to 50 ports, token-protected; raw TCP; SSH; dedicated IPv6 or IPv4 |
| Desktop and computer use | VNC desktop (xfce4) and a computer-use API on Linux and Windows | A browser only, with a VNC live view, a click, type and screenshot API, and CDP | 60fps desktop and Chromium, computer use and browser control, embeddable stream |
| Files after a stop | The disk is kept and billed while stopped; archived containers are free | Pause keeps files at a lower, unpublished rate; the sandbox is deleted when its TTL ends | Snapshots every minute and on stop; a stopped sandbox costs nothing |
| Memory snapshots and branching | Linux VM and Windows classes pause and fork with memory kept; containers cannot | Snapshots keep memory and files in every sandbox; start many sandboxes from one | Fork a running sandbox; resume reboots from disk (no memory snapshots) |
| How long a sandbox lives | No default cap; a wall-clock TTL is optional | TTL of up to 7 days for a custom container and 14 days for Code Execution | No session cap on paid plans |
| Outbound internet | Tier 1 and 2 reach only registries, git hosts and AI APIs; Tier 3 and up get open internet plus per-sandbox allowlists | Off unless the template turns it on; can route through your VPC with Cloud NAT, a static IP, Cloud NGFW or Secure Web Proxy | Open internet on every plan; no provider-side allowlist |
| Coding agents | Guides install agents and run them through process exec | Managed Agents API (Preview) runs Google's Antigravity harness; no other coding harness named | Claude Code, Codex, OpenCode and more preinstalled, with a prompt, steer and events API |
| Keeping keys out of the sandbox | Secrets proxy swaps placeholders in HTTPS request headers for allowed hosts | You provision and scope the credentials the agent uses | AI credentials proxy for model providers and any HTTPS API you register; switch a credential to another account when credits run out |
| Hosting your agent code | Sandboxes only; you run your agent loop yourself | Agent Runtime deploys ADK, LangGraph, LangChain, AG2 and LlamaIndex agents; idle time between turns is not billed | You run your own agent loop inside a sandbox |
| GPUs and Windows | Nvidia and AMD GPUs on-demand or preemptible; Windows VM sandboxes | No GPUs or Windows sandboxes | No GPUs or Windows guests; Wine for Windows apps |
| Regions | US and EU, plus dedicated regions or your own machines (BYOC) | 23 locations in the US, Europe, Asia, Canada, Australia and Brazil | EU only: Germany, Finland, France |
Every feature Battleships tracks (43)
| Feature | Daytona | Google Agent Runtime | bochka |
|---|---|---|---|
| Full VM (own kernel) | No | No | Yes |
| Docker inside | Yes | No | Yes |
| Nested virtualization | Yes | No | Yes |
| Root | Yes | No | Yes |
| Systemd | Not published | Not published | Yes |
| Desktop GUI | Yes | No | Yes |
| Browser | Yes | Yes | Yes |
| Computer-use API | Yes | Yes | Yes |
| SSH | Yes | No | Yes |
| Persistent disk | Yes | Yes | Yes |
| Pause/resume | Yes | Yes | Yes |
| Automatic snapshots | Yes | Yes | Yes |
| Fork/clone | Yes | Yes | Yes |
| Live fork (no pause) | No | Yes | Yes |
| Memory fork | Yes | 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 | No | No | No |
| HTTPS preview URLs | Yes | No | Yes |
| Raw TCP inbound | No | Not published | 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 | Yes | Yes |
| Agent harness API | No | Yes | Yes |
| MCP server | Yes | No | No |
| GPU | Yes | No | No |
| Windows | Yes | No | No |
| Arm64 | No | Yes | No |
| Self-hosting | No | No | No |
| BYOC | Yes | No | No |
| Open source | No | No | No |
| Scoped API keys | Yes | Not published | Yes |
| Spend limits | Not published | Not published | Yes |
| Usage per sandbox (API) | Yes | Yes | Yes |
| Audit logs | Yes | Not published | No |
| SSO | Yes | Yes | No |
| SOC 2 | Yes | Yes | No |
| HIPAA | Yes | Yes | No |
| EU data residency | Yes | Yes | Yes |
| Zero data retention | Not published | Not published | Yes |
Performance
In StarSling's public run of 2026-09-29 at 4 vCPU / 8 GB, bochka did 26.69 Node.js build-and-test runs per second and Daytona's Linux VM class did 21.52, so each build takes about a quarter longer on Daytona. Daytona's default container class reported no result. Google Agent Runtime and its sandboxes were not part of that run, so there is no comparable number for Google.
Node.js build-and-test loop at 4 vCPU / 8 GB, higher is better. Measured with the open hpc-sandbox-benchmarks suite. Daytona measured on: Linux VM sandbox (same rates; KVM / nested virt per-org feature). Google Agent 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 | Daytona, a month | Google Agent Runtime, 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 | $56 · Tier 3 ($500 top-up) | $73 · Pay as you go | $20 · $20/mo |
| One agent that never stops 4 vCPU / 8 GB, 50 GB disk, running 24/7 all month | $245 · Tier 3 ($500 top-up) | $301 · Pay as you go | $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 | $2,682 · Tier 3 ($500 top-up) | $3,626 · Pay as you go · with limits | $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 | $2,000 · Tier 4 ($2,000 top-up every 30 days) · with limits | $1,030 · Pay as you go | $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,000 · Tier 4 ($2,000 top-up every 30 days) · with limits | $2,060 · Pay as you go | $2,000 · $2000/mo · with limits |
Daytona: Daytona bills per second for the vCPU, memory and disk you reserve, and keeps billing the disk while a sandbox is stopped. You pay from a prepaid wallet: open internet needs a $500 top-up (Tier 3), and the biggest pool needs $2,000 every 30 days (Tier 4).
Google Agent Runtime: Google bills $0.085 per vCPU-hour and $0.009 per GiB-hour allocated, with the first 50 vCPU-hours and 100 GiB-hours free each month. Runtime skips idle time between turns, but sandboxes are billed while they exist, and disk and egress rates are not published.
Google Agent Runtime: 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.
Limits in those scenarios
Daytona limits the total vCPU running at once, 500 vCPU on Tier 4, so 300 sandboxes for your users (600 vCPU) and 1,000 short jobs at once (2,000 vCPU) need a custom limit. Google fits both of those sizes, but its 50-agent fleet does not fit because its sandboxes have no Docker inside, and its sandboxes are deleted when their TTL ends. Neither publishes an egress price, and Google leaves disk unpriced too. On bochka the 1,000-job burst is the problem: starts are capped at 90 a minute and 2,400 a day on the $2,000 plan, so the jobs get queued.
| Scenario | Daytona | Google Agent Runtime | bochka |
|---|---|---|---|
| One coding agent, workdays |
|
| None that bite |
| One agent that never stops |
|
| 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 Daytona when
your agents need root, Docker and SSH in a sandbox you create by API, or GPUs, Windows, the US or your own machines.
- Root, Docker and SSH. Useful if your agents install packages and build containers: Daytona gives root and Docker in every class, where Google's sandboxes have no sudo.
- GPUs and Windows. Useful if agents test models or need a Windows desktop: Daytona rents Nvidia and AMD GPUs and runs Windows VM sandboxes.
- Sandboxes that keep running. Useful for long-lived agents: a Daytona sandbox has no default time limit, while a Google custom container is deleted after 7 days at most.
Use Google Agent Runtime when
you build agents with ADK or LangGraph on Google Cloud and want them hosted inside your own project and network, 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.
- Memory snapshots and 23 locations. Useful if you branch sandboxes with their memory, or need to run in Asia, Canada, Australia or Brazil.
Where bochka fits
If your agents do real work for hours, like installs, builds, tests, Docker and emulators, look at bochka too. Every bochka sandbox is a full VM with root, Docker, /dev/kvm, a desktop and coding agents built in, and it was faster than Daytona's VM class in the same CPU test. Daytona gets you most of the way with its VM class, and Google's locked sandboxes stop short of it.
A full VM, not a container
Daytona's default is a container on a shared kernel; you need its VM class, and KVM turned on for your organization, to get /dev/kvm. Google's sandboxes run with no sudo and no Docker, so you bake every tool into an image ahead of time.
Public URLs and raw TCP for what agents build
Daytona gives HTTPS previews but no raw TCP or public IP. Google documents no public URL at all, so showing a preview to someone outside your project means setting up a VPC endpoint, load balancer or tunnel yourself.
Coding agents you drive from outside
On Daytona you install Claude Code or Codex and run it as a process. Google runs only its own Antigravity harness, in Preview. bochka ships both preinstalled with a prompt, steer and events API, and its credentials proxy can switch accounts when credits run out.
Use bochka when your agents need a real computer for hours: root, Docker, /dev/kvm, SSH, a desktop and public URLs on a full, faster VM with coding agents built in. Compare it one to one: bochka vs Daytona and bochka vs Google Agent Runtime.
Questions people ask
Is Daytona cheaper than Google Agent Runtime?
In most scenarios we priced, yes: one coding agent on workdays comes to $56 a month on Daytona and $73 on Google, and one agent running all month $245 versus $301. Google is cheaper for sandboxes for your users, $1,030 versus $2,000, where Daytona also needs a higher limit. bochka comes to $20, $26 and $200 a month for those three.
Which is faster, Daytona or Google Agent Runtime?
Only Daytona has a measured number: its Linux VM class did 21.52 Node.js build-and-test runs per second at 4 vCPU / 8 GB. Google's sandboxes were not in that benchmark. bochka did 26.69 in the same run.
Can Google Agent Runtime run Docker like Daytona?
No. Google's shell sandbox runs commands as the unprivileged user appuser with no sudo, and custom images must not need root, so Docker is not available. Daytona has Docker in all its classes, and bochka has Docker, root and /dev/kvm on every VM.
Is Google Agent Runtime the same as Vertex AI Agent Engine?
Yes. Google renamed Vertex AI Agent Engine to Agent Runtime in April 2026, as part of Gemini Enterprise Agent Platform. The code, shell and browser sandboxes are a separate part of the same platform called Agent Sandbox.
Do Daytona or Google Agent Runtime have GPUs?
Daytona does: it rents Nvidia and AMD GPUs from RTX 4090 to B300, on demand or preemptible. Google's agent sandboxes have no GPUs, and neither does bochka.
Where does my data run?
Daytona runs in the US and EU, plus dedicated regions and your own machines. Google runs in 23 locations across the US, Europe, Asia, Canada, Australia and Brazil. bochka runs only in the EU (Germany, Finland and France), with EU data residency.
Try bochka
Install the CLI, then run bochka new.
Product preview