Daytona builds fast, API-driven sandboxes for running AI-generated code: spin one up in milliseconds, run the task, tear it down. Jilebi builds persistent Linux machines for developers and agents: provision once, keep your state, auto-sleep when idle, wake where you left off.
They overlap (both run isolated agent workloads) but optimize for opposite ends of the lifecycle spectrum. This post compares them across price, performance, ease of use, and technology.
TL;DR
| Dimension | Jilebi | Daytona |
|---|---|---|
| Price model | ~$0.009/vCPU-hr + ~$0.009/GB-hr while running, disk-only when paused | $0.0504/vCPU-hr + $0.0162/GiB-hr while reserved, disk-only when stopped/paused |
| Unit economics | ~5x cheaper per running vCPU-hour; wins on long-lived machines | Competitive for sub-minute ephemeral runs at massive scale |
| Performance | Bare-metal microVMs, ~50ms boot, auto-sleep/wake; 1–16 vCPU / up to 16 GB / 30–65 GB NVMe per machine | Sub-90ms sandbox create; default 1 vCPU / 1 GB / 3 GiB, org cap ~4 vCPU / 8 GB / 10 GB |
| Ease of use | Console + SSH + HTTPS exposure; machine feels like your own server | Python/TS SDK + CLI + API; sandbox feels like a function call |
| Technology | Cloud Hypervisor microVMs, btrfs snapshots, pause/resume | Docker containers by default (Kata/VM opt-in), fork / pause / snapshot |
Prices from public pricing pages at the time of writing (September 2026); verify current rates before deciding.
Price
Both bill per second, but the unit rates differ substantially:
- Daytona: $0.0504 per vCPU-hour, $0.0162 per GiB-hour of RAM, ~$0.000108 per GiB-hour of disk. Started sandboxes bill all reserved resources; stopped or paused (VM) sandboxes bill disk only. A default 1 vCPU / 1 GB sandbox costs roughly $0.067/hr while started.
- Jilebi: ~$0.009 per vCPU-hour, ~$0.009 per GB-hour of RAM, nominal disk-only billing when paused. The same 1 vCPU / 1 GB shape costs roughly $0.018/hr while running — about a quarter of Daytona’s running rate — and drops to disk-only when paused.
Worked example — a 2 vCPU / 4 GB agent box running 8 hours a day, 30 days (240 hrs), paused the rest:
- Daytona: (2 × $0.0504 + 4 × $0.0162) × 240 ≈ $39.70 + disk for the paused hours.
- Jilebi: (2 × $0.009 + 4 × $0.009) × 240 ≈ $12.96 + nominal disk while paused.
Daytona includes $200 in free compute to start, which is generous for evaluation. At sustained volume, Jilebi’s lower per-unit rates win for anything that lives longer than a few minutes; Daytona’s model is tuned for very short-lived sandboxes created and destroyed by the thousand, where per-unit rate matters less than orchestration speed and SDK ergonomics.
Performance
- Daytona advertises sub-90ms sandbox creation — among the fastest cold starts in the category — and independent benchmarks put its create/resume in the ~0.7–1.3s range for real workloads. The tradeoff is size: default sandboxes are small (1 vCPU / 1 GB / 3 GiB disk) with organization caps around 4 vCPUs / 8 GB / 10 GB disk. That is plenty for code execution, insufficient for a big Rust/Nix build.
- Jilebi provisions larger machines (1–16 vCPUs, 1–16 GB RAM, 30–65 GB NVMe) on bare-metal hosts with no nested virtualization. New machines boot in ~50ms — sandbox-class startup — and once running, you get dedicated cores and local NVMe for compiles that need them. Idle machines auto-sleep and wake on use, so pause/resume keeps filesystem and process state without you managing it.
Rule of thumb: Daytona wins when you need thousands of tiny sandboxes right now; Jilebi wins when each workload needs real cores, real disk, and hours of life.
Ease of use
Daytona is SDK-first: Daytona() in Python or TypeScript, create → run code → snapshot/fork → delete, with dashboard observability, preview URLs, and self-hosting options for enterprise. If your product is an agent platform that programmatically mints sandboxes, Daytona’s API is the interface you want.
Jilebi is machine-first: create a machine in the console (or API), SSH in, install your stack from the software catalog (nix, opencode, claude code, codex, docker), expose ports over *.jilebi.dev with TLS when needed. Idle machines auto-sleep and wake when you come back. If you (or your long-lived agent) want a computer that persists across sessions — dotfiles, editor, build cache, running services — Jilebi’s model needs no application rewrite.
Technology
| Aspect | Jilebi | Daytona |
|---|---|---|
| Isolation | Cloud Hypervisor microVM per machine (own kernel, hardware boundary) | Docker container by default; Kata Containers / dedicated VM sandboxes opt-in |
| Lifecycle | Persistent machines: auto-sleep / wake / snapshot, state kept indefinitely | Ephemeral-first: create / fork / pause / snapshot / archive / delete; stopped VMs bill disk only |
| Sizes | 1–16 vCPU, 1–16 GB RAM, 30–65 GB NVMe per machine | 1–4 vCPU, 1–8 GB RAM, 1–10 GB disk per sandbox (org limits) |
| Networking | No public IP by default; selective HTTPS exposure via proxy | Preview URLs, configurable egress, region selection |
| GPU | Not offered today | GPU sandboxes (H100/H200/5090-class, hourly) |
| Self-host | Roadmap is managed-first | Managed + self-hosted options |
The isolation row deserves emphasis for untrusted-code workloads: Jilebi’s microVM boundary is hardware-enforced per machine; Daytona’s default container boundary shares a host kernel (with stronger Kata/VM options available when you ask for them).
Pros and cons
Jilebi — pros
- Much lower per-unit running cost (~$0.009/vCPU-hr vs $0.0504), disk-only sleep
- Larger machines: up to 16 vCPU / 16 GB / 65 GB NVMe for real builds
- ~50ms boot for new machines; idle machines auto-sleep and wake on use
- Hardware microVM isolation per machine by default
- Persistent state across sessions without snapshot gymnastics
- Simple console + SSH + HTTPS model, no SDK required
Jilebi — cons
- No GPU options today; no self-hosted tier today
- SDK/API surface is younger than Daytona’s mature Python/TS SDKs
- Not designed for 100k-concurrent ephemeral fan-out
Daytona — pros
- Extremely fast sandbox creation at high concurrency
- Mature SDKs, snapshots, forking, preview URLs, regions
- GPU sandboxes and Windows/macOS runtimes for specialized tasks
- Stopped/paused billing drops to disk-only; archived sandboxes bill nothing
- Self-hosting for enterprise compliance needs
Daytona — cons
- ~5x higher per-vCPU-hour running rate adds up for long-lived boxes
- Default/max sandbox sizes too small for heavyweight compiles
- Default isolation is container-grade unless you opt into Kata/VM
- Ephemeral-first model fights you if you want a persistent dev home
Which should you pick?
- Pick Daytona if you are building an agent platform that needs thousands of short-lived, SDK-managed sandboxes per day, with GPUs and enterprise self-hosting on the roadmap.
- Pick Jilebi if you (or your agents) want persistent, pauseable Linux machines with real cores and disk at low running cost — dev boxes, long builds, hosted services, PR previews.
Many teams end up wanting both primitives. Try the persistent one at jilebi.ai.