Jilebi vs Modal: machines you keep vs serverless you rent

Modal is serverless infrastructure for AI: decorate a Python function, get GPUs, autoscaling to zero, and per-second billing. Jilebi is persistent Linux machines: a new box boots in ~50ms, keeps your state, and auto-sleeps when idle / wakes on use.

Modal asks “what code should run?”; Jilebi asks “what computer do you want?” This post compares them on price, performance, ease of use, and technology.

TL;DR

Rates from public pricing pages at the time of writing (September 2026); Modal has separate rates for Functions vs Sandboxes and region multipliers — verify before deciding.

Price

Modal Starter is $0 base + usage ($30/mo free credits); Team is $250/mo + usage. Sandbox compute lists around $0.00003942 per physical-core-second (≈ $0.142/core-hr, where a core ≈ 2 vCPUs) plus $0.00000667 per GiB-second (≈ $0.024/GiB-hr). GPUs range from ~$0.59/hr (T4) to ~$3.95/hr (H100) to ~$7.10/hr (B300), billed per second with no minimum, plus CPU/memory on top. Scale-to-zero means idle costs nothing — the bill tracks active compute almost exactly.

Jilebi charges ~$0.009/vCPU-hr + ~$0.009/GB-hr while running, disk-only when paused, no base fee. A 4 vCPU / 8 GB box costs ≈ $0.108/hr running.

Worked example — same 4 vCPU / 8 GB shape, 240 running hours/month:

• Jilebi: ≈ $26 + nominal paused-disk.
• Modal Sandboxes: (2 cores × $0.142 + 8 × $0.024) × 240 ≈ $114.

But flip the workload to 10,000 five-minute inference bursts with scale-to-zero between them and Modal’s model shines: you pay for ~833 compute-hours and nothing between bursts. A Jilebi box auto-sleeps between bursts too (billing disk-only while asleep), but Modal’s per-request orchestration — queues, autoscaling, GPU attach — is built for exactly this shape, while on Jilebi it is your architecture to design.

The honest summary: Modal is cheaper for spiky, short-burst, massively parallel compute; Jilebi is cheaper for steady-state machines that hold state.

Performance

• Modal demonstrates 50k–1M concurrent sandboxes, autoscaling from zero to thousands of containers, with per-second billing granularity and configurable warm windows (2s–20min). Sandbox cold starts measure around 2–2.5s in independent benchmarks — far slower than microVM-first vendors (Jilebi boots new machines in ~50ms), amortized by scale. GPU access (T4 through B300) is Modal’s killer feature: one platform for CPU sandboxes and GPU training/inference.
• Jilebi gives each machine dedicated vCPUs on bare metal with local NVMe — no shared-kernel scheduling, no cold start per request. Pause/resume preserves the running machine instead of rebuilding it. There are no GPUs today, so GPU-bound work is simply out of scope for Jilebi right now.

If your bottleneck is “compile this monorepo fast on dedicated cores,” Jilebi’s shape wins. If it is “run 20,000 sandboxes for a promo event” or “train on H100s tonight,” Modal is in a different league.

Ease of use

Modal is code-first: define infrastructure with Python decorators, deploy with one command, get web endpoints, cron, queues, volumes, and secrets without touching a server. Developers who live in Python and want zero ops will feel at home; developers who want to SSH into a box and poke around will feel constrained (SSH exists for debugging, but the box is not the product).

Jilebi is computer-first: pick a shape, get a machine, SSH in, install anything, run anything, expose ports. Idle machines auto-sleep and wake on use — but there is no fleet autoscaling, no built-in job queues, no managed inference endpoints. You get a computer; what runs on it is your architecture to design.

Technology

Isolation note: Jilebi’s hardware microVM boundary is stronger per workload than Modal’s gVisor user-space kernel boundary — at the cost of Modal’s far denser multi-tenancy and faster orchestration.

Pros and cons

Jilebi — pros

• Far cheaper per running vCPU-hour for steady-state machines; disk-only pause
• Dedicated cores + NVMe on bare metal; great for big builds
• Hardware microVM isolation per machine
• Real persistent computer: dotfiles, caches, services survive for months
• No SDK lock-in, no packaging model to learn

Jilebi — cons

• No GPUs — rules out training and GPU inference entirely
• No fleet autoscaling or managed endpoints (auto-sleep/wake is per-machine)
• No million-sandbox fan-out; one machine per workload, not per request
• You architect availability/scaling yourself

Modal — pros

• Best-in-class serverless GPU catalog with per-second billing
• Massive elastic scale (100k+ concurrent sandboxes) with scale-to-zero
• Superb Python-native developer experience: functions, cron, queues, web endpoints
• $30/mo free credits on Starter; generous free tier for experiments
• Mature observability: logs, metrics, dashboard, regions

Modal — cons

• Higher per-unit CPU/memory rates than Jilebi for always-on shapes (~5–8x on CPU)
• gVisor shared-kernel isolation is weaker than hardware microVMs
• ~2s sandbox cold starts; state rebuild on wake vs true resume
• Proprietary programming model — migrating off means rewriting orchestration
• Team plan starts at $250/mo + usage

Which should you pick?

• Pick Modal if you need GPUs, elastic scale-to-zero, or a Python-native serverless platform for inference, batch, and ephemeral agent sandboxes.
• Pick Jilebi if you want cheap, persistent, pauseable Linux machines with dedicated cores for development, builds, hosted services, and long-lived agents.

GPU training on Jilebi is not a thing — we will tell you that ourselves. For everything that needs a computer that stays yours, try jilebi.ai.