Daytona vs Tensorlake
Daytona starts each sandbox as a container and sells Linux VM, Windows and GPU classes on top. Tensorlake gives every sandbox its own microVM that can freeze its memory and wake up warm, and its Pro plan runs up to 1,000 at once.
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
Tensorlake
Tensorlake is a San Francisco company that sells infrastructure for AI agents, with sandboxes as its main product.
Tensorlake Sandboxes are microVMs, backed by Firecracker and Cloud Hypervisor, that you create through an API and that boot in a few hundred milliseconds. Named sandboxes suspend when idle and keep their memory and running processes, and you can copy a running sandbox into several warm clones. Around them Tensorlake sells versioned file systems, hosted Git, an orchestration layer and a bring-your-own-cloud option, aimed at teams running coding agents, evals and RL rollouts.
- Headquarters
- San Francisco
- Investors shown
- Redpoint and Amplify Partners
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 | Tensorlake: price rank | bochka: price rank |
|---|---|---|---|
| Software factory 100 at once · 4 vCPU / 8 GB · 2,200 sessions of 8 h a month All three fit; bochka adds /dev/kvm and coding agents on every machine, Daytona needs its Linux VM class for /dev/kvm, and Tensorlake has none. | 15th cheapest of 367 $4,111 a month | 5th cheapest of 367 $1,010 a month | 3rd cheapest of 367 $634 a month |
| Always-on AI employees 50 machines 24/7 · 2 vCPU / 4 GB | 24th cheapest of 366 $6,104 a month | 9th cheapest of 366 $1,381 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 and Tensorlake both fit lots of one-minute runs, while bochka's start-rate limits make big bursts a compromise. | 25th cheapest of 345 $271 a month | 24th cheapest of 345 $250 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 at once need 600 vCPU, more than Daytona's Tier 4 pool of 500, while Tensorlake Pro and bochka both fit. | 154th of 361, with limits $2,000 a month | 5th cheapest of 361 $471 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 Tensorlake fits a thousand rollouts at once from one warm state; Daytona's vCPU pool and bochka's start-rate limits make it a compromise. | 130th of 360, with limits $8,261 a month | Cheapest of 360 $5,637 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 | 24th cheapest of 364 $506 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 Daytona caps a sandbox at 4 vCPU by default, so bigger CI jobs need a raised limit; Tensorlake and bochka both fit. | 308th of 377, with limits $805 a month | 54th cheapest of 377 $424 a month | 4th cheapest of 377 $86 a month |
| 24/7 dev boxes 1 machine 24/7 · 4 vCPU / 8 GB bochka fits a box that stays on all day; Daytona keeps billing the full reservation and Tensorlake is built around suspending idle sandboxes. | 183rd of 368, with limits $245 a month | 185th of 368, with limits $250 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 All three fit: Daytona has VNC on Linux and Windows, Tensorlake has an XFCE desktop over VNC, and bochka streams a 60fps desktop. | 26th cheapest of 369 $1,198 a month | 9th cheapest of 369 $294 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 | 93rd of 367, with limits $598 a month | 13th cheapest of 367 $250 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 | 22nd cheapest of 346 $250 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 | 121st of 338, with limits $3,484 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 | 4th cheapest of 360 $250 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 has published GPU rates; Tensorlake offers GPU sandboxes by request, and bochka has no 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 | Tensorlake | bochka |
|---|---|---|---|
| Isolation | Container by default; Linux VM and Windows VM classes have their own kernel | Firecracker and Cloud Hypervisor microVMs with their own kernel; GPU sandboxes use gVisor | Full VM with its own kernel on dedicated AMD Ryzen 9 9950X hosts |
| CPU speed (Node.js build-and-test, 4 vCPU / 8 GB) | 21.52 runs/s on the Linux VM class; the container class reported no result | No published result | 26.69 runs/s |
| Nested virtualization | /dev/kvm on the Linux VM class, once KVM is turned on for your organization | No: sandboxes set SANDBOX_KVM_AVAILABLE=0 | /dev/kvm on every machine, so Android emulators and VMs run |
| Docker inside | Yes, in all classes | Yes, on the tensorlake/ubuntu-systemd image | Yes, with root and systemd on every machine |
| Memory snapshots and clones | Linux VM and Windows classes pause and fork with memory kept; containers do not | Named sandboxes suspend with memory; a running sandbox copies into many warm clones | Fork a running sandbox (disk); resume reboots from disk |
| Files after a stop | Disk is kept and billed while stopped; archived containers are free | Named sandboxes suspend, billed as snapshot storage; ephemeral ones end on idle | Snapshots every minute and on stop; a stopped sandbox costs nothing |
| Desktop and computer use | VNC desktop (xfce4) and a computer-use API on Linux and Windows | XFCE desktop with Firefox over VNC, with screenshot, mouse and keyboard calls | 60fps desktop and Chromium, computer use and browser control, embeddable stream |
| Coding agents | Guides install agents and run them through process exec | You bring and run your own agent; managed images are plain OS bases | 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 headers for allowed hosts | Stored secrets are injected into the sandbox | AI credentials proxy for model providers and any HTTPS API; real keys never enter the sandbox |
| Reaching the sandbox | HTTPS preview URLs on any port, token-protected or public; SSH; no raw TCP | HTTP, WebSocket and gRPC through an authenticated proxy; no raw TCP | HTTPS URLs for up to 50 ports, token-protected, plus raw TCP and a dedicated IP |
| Outbound internet | Tier 1 and 2 reach only registries, git and AI APIs; Tier 3 and up get open internet and allowlists | Open internet, with allow and deny lists by domain, IP or CIDR on every sandbox | Open internet on every plan; set your own firewall as root |
| Running at once | A vCPU pool: 10 to 500 vCPU from Tier 1 to Tier 4; 4 vCPU / 8 GB per sandbox by default | Pro allows 1,000 sandboxes at once, up to 16 vCPU / 64 GB each | 100 to 2,000 sandboxes by plan, with a starts-per-minute limit |
| GPUs and Windows | Nvidia and AMD GPUs by the hour, from RTX 4090 to B300; Windows VM sandboxes | GPU sandboxes by request with no published rate; no Windows | No GPUs; no Windows guests (Wine for Windows apps) |
| Where it runs | US and EU, plus dedicated regions or your own machines | US and EU, or your own AWS, GCP, Azure, CoreWeave, Nebius or bare-metal account | EU only: Germany, Finland, France, with EU data residency |
Every feature Battleships tracks (43)
| Feature | Daytona | Tensorlake | bochka |
|---|---|---|---|
| Full VM (own kernel) | No | Yes | Yes |
| Docker inside | Yes | Yes | Yes |
| Nested virtualization | Yes | No | Yes |
| Root | Yes | Yes | Yes |
| Systemd | Not published | Yes | Yes |
| Desktop GUI | Yes | Yes | Yes |
| Browser | Yes | Yes | Yes |
| Computer-use API | Yes | Yes | Yes |
| SSH | Yes | Yes | 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 | Yes | No |
| Wake on request | No | Yes | 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 | No | No |
| GPU | Yes | Yes | No |
| Windows | Yes | No | No |
| Arm64 | No | No | No |
| Self-hosting | No | No | No |
| BYOC | Yes | Yes | 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 | No | 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 | Yes | 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. Daytona's default container class reported no result, and Tensorlake has no published result on this benchmark, so there is no CPU number to compare for Tensorlake.
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). Tensorlake 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 | Tensorlake, 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) | $250 · Pro | $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) | $250 · Pro | $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) | $1,030 · 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 | $2,000 · Tier 4 ($2,000 top-up every 30 days) · with limits | $293 · Pro | $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 | $1,127 · Pro | $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).
Tensorlake: Tensorlake Pro is $250 per billing cycle, which includes $250 of usage, then $0.01 per CU. CPU is billed only while it is actively working, RAM and disk on what you allocate while running, and a suspended sandbox pays snapshot storage.
Tensorlake: Small users can skip Pro and buy prepaid Usage Credits packs from $5 at higher rates; sandboxes stop when the balance hits zero. The table prices the Pro path, so it overstates very small workloads.
Tensorlake: 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, up to 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 there. Tensorlake Pro allows 1,000 sandboxes at once and fits both. Daytona also opens the internet only from Tier 3, and an ephemeral Tensorlake sandbox ends after 10 idle minutes by default. bochka fits 300 user sandboxes but queues the 1,000-job burst, because even its $2,000 plan starts at most 90 machines a minute before queuing.
| Scenario | Daytona | Tensorlake | 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 | None that bite |
| Sandboxes for your users |
| None that bite | None that bite |
| 1,000 short jobs at once |
| None that bite |
|
Which one should you use?
Use Daytona when
your agents need GPUs by the hour or Windows desktops, or you want to start with no plan fee.
- GPUs by the hour. Useful if your agents train or test models: Daytona rents Nvidia and AMD GPUs by the hour, from RTX 4090 to B300.
- Windows sandboxes. Useful if an agent must drive Windows apps: Daytona runs Windows VM sandboxes with computer use, and Tensorlake has no Windows.
- No plan fee to start. Daytona bills per second from a prepaid wallet with $200 of free compute, so small teams pay only for what they run.
Use Tensorlake when
every sandbox needs its own kernel, or you fan out about a thousand short rollouts at once from one warm state.
- A microVM for every sandbox. Every Tensorlake sandbox has its own kernel by default, while on Daytona you must pick the VM class to get one.
- Warm clones from memory. Useful for RL and evals: Tensorlake can save a running sandbox's memory and copy it into many warm clones.
- 1,000 at once on Pro. Tensorlake Pro runs 1,000 sandboxes at once, where Daytona's biggest tier caps the total at 500 vCPU.
Where bochka fits
If your agents work for hours, installing, building, testing and running Docker or emulators, look at bochka. Every bochka sandbox is a full VM with /dev/kvm, a 60fps desktop and coding agents built in, and it stays on with no session cap on paid plans. For thousands of short jobs started at once, Daytona or Tensorlake fit better.
Emulators and VMs run inside
Tensorlake sandboxes have no /dev/kvm, so an Android emulator never starts. Daytona has it only on the Linux VM class, after KVM is turned on for your organization. bochka has /dev/kvm on every machine.
Faster CPU in the same test
In the same benchmark run, bochka did 26.69 runs per second and Daytona's VM class did 21.52, so each build takes about a quarter longer there. Tensorlake has no published result.
Agents driven from outside, keys kept outside
On both you install the agent yourself and write the code that prompts and watches it, and Tensorlake injects secrets into the sandbox. bochka ships the agents with a prompt, steer and events API and keeps real keys in a proxy.
Use bochka when your agents do real work for hours: installs, builds, tests, Docker and emulators on a full, faster VM with a desktop and coding agents built in. Compare it one to one: bochka vs Daytona and bochka vs Tensorlake.
Questions people ask
Is Daytona cheaper than Tensorlake?
For one coding agent on workdays, yes: $56 a month on Daytona against $250 on Tensorlake Pro, which has a $250 minimum. At scale Tensorlake is cheaper: 50 agents in parallel come to $2,682 on Daytona and $1,030 on Tensorlake. On bochka the same two cost $20 and $317.
Which is faster, Daytona or Tensorlake?
There is no comparable number. Daytona's Linux VM class did 21.52 runs per second in StarSling's Node.js benchmark at 4 vCPU / 8 GB, and Tensorlake has no published result there. bochka did 26.69 in the same run.
Are Daytona and Tensorlake sandboxes containers or VMs?
Daytona's default class is a Linux container, with Linux VM and Windows VM classes on request. Every Tensorlake sandbox is a Firecracker or Cloud Hypervisor microVM, except GPU sandboxes, which run on gVisor. Every bochka sandbox is a full VM.
Can Daytona and Tensorlake run Docker?
Yes. Daytona runs Docker in all classes, and Tensorlake runs it on its tensorlake/ubuntu-systemd image. Only Daytona's Linux VM class has /dev/kvm for emulators; Tensorlake has none, and bochka has Docker, systemd and /dev/kvm on every machine.
Which one has GPUs?
Daytona rents Nvidia and AMD GPUs by the hour, on demand or preemptible. Tensorlake offers GPU sandboxes by request, with no published rate. bochka has no GPUs.
Where do Daytona and Tensorlake run?
Both run in the US and the EU. Daytona also offers dedicated regions and your own machines, and Tensorlake can run in your own cloud account through BYOC. bochka runs only in the EU (Germany, Finland, France).
Try bochka
Install the CLI, then run bochka new.
Product preview