Runtime vs Modal Sandboxes
Runtime gives each agent sandbox its own microVM kernel. It costs 84% less than Modal for an agent that mostly waits on a model.
Switch in one line. Your Modal Sandbox code keeps working. Change the
import and set RUNTIME_API_KEY.
TypeScriptimport { ModalClient } from "withruntime/modal"; // was: from "modal"Pythonfrom withruntime import modal # was: import modalModal's own sandbox examples run on it unchanged, except the features listed below. Those stop with an error naming Runtime's alternative.
The saving: 1,000 one-minute runs of a 2 vCPU, 4 GiB sandbox cost $0.64 on Runtime and $3.97 on Modal. At 100,000 runs a month that is $63.89 against $396.60, $333 a month saved.
Comparing more than two? Modal Sandbox alternatives ranks the other providers by the cost of the same job.
Updated
On this page
84% less than Modal
Compute only, at list rates checked 25 October 2026 (Modal pricing). Plan fees, network, taxes and free credits are left out. The worked example below shows the arithmetic.
Where Runtime is better#
- You pay for the CPU you use. Modal bills whichever is higher, the CPU a sandbox requested or the CPU it used. So a requested core is billed while it waits. Runtime measures the CPU your code actually uses, with a floor of a twentieth of a vCPU. There is no request to size in advance.
- Waiting costs storage, not compute. A Runtime sandbox left idle for 300 seconds pauses by itself and keeps its memory. It then pays $0.08 per GB (10⁹ bytes) a month until a request wakes it.
- An uptime promise that pays itself. Paid accounts are promised 99% API uptime each month. A month below it returns 10% of that month's charges as credit. No claim is needed (Uptime Promise).
- Lower rates on both meters. A vCPU-hour costs $0.025 on Runtime. Modal charges $0.1419 per physical core-hour, $0.071 per vCPU. Memory costs $0.0075 per GiB-hour against Modal's $0.0240. Even with every CPU busy the whole time, the example job costs $1.33 on Runtime and $3.97 on Modal.
- Its own kernel per sandbox. A microVM puts a hardware virtualization boundary between sandboxes. Modal uses gVisor, a user-space kernel that intercepts system calls. See security.
- Pause with memory, on every sandbox. A paused Runtime sandbox wakes with its processes still running, kept while you have credit. Forks copy a running sandbox, memory and processes included.
- Nothing to set up first. One call creates a sandbox, with no app or project. Outside Modal, a Modal sandbox needs an App.
- Teams at no extra charge. Single sign-on over SAML or OIDC (Okta, Microsoft Entra ID, Google Workspace), SCIM, roles and an audit log come with every account (single sign-on). Modal puts SAML single sign-on and audit logs on its Enterprise plan.
- Custom domains and a fixed address without a plan. A paid account serves a sandbox port at your own hostname. It sends from a dedicated outbound address for $5 a month (networking). Modal's custom domains and static IP proxy come with its Team plan, $250 a month.
- Keys the sandbox never sees. Store an API key once. The sandbox holds a placeholder. Runtime's proxy adds the value only to HTTPS requests to the hosts you name. A prompt injection has nothing to leak (security).
- Your credit matched. Credit you add within 30 days of signing up is matched, up to $1,000 in total (welcome match).
- Your agent sets itself up. It runs
npx withruntime sandboxes run -- ..., shows you a link, and starts once you approve in the browser. No API key goes into a prompt or a config file. The MCP server reuses the same connection.
Also included: a code interpreter, network allow and deny lists, custom images, volumes backed up daily, private previews, a Linux desktop, metrics, webhooks, OpenTelemetry export, S3, R2 and GCS bucket mounts, MCP servers from a catalog and identity tokens for AWS and Google Cloud. Paid accounts add TCP ports and WireGuard private networks. See products.
At a glance#
Modal's figures come from its public pricing and documentation, checked 25 October 2026.
| Runtime | Modal Sandboxes | |
|---|---|---|
| Isolation | Firecracker microVM, own kernel | gVisor, a user-space kernel that intercepts system calls |
| CPU billing | $0.025 per vCPU-hour of measured CPU, with a small floor | $0.1419 per physical core-hour (2 vCPUs), request or use |
| Memory billing | $0.0075 per reserved GiB-hour | $0.0240 per GiB-hour, request or use |
| Plan fee | None; prepaid credit from $10 | Starter $0 with $30 a month of compute; Team $250 a month |
| Free start | 100 free hours of a 1 GB machine in the first 30 days, no card | $30 of compute a month on Starter |
| Session length | No time limit: runs while it works, pauses itself after 300 seconds idle | Up to 24 hours; snapshots carry state beyond that |
| Setup | One call; no app or project | A Modal App is needed outside Modal |
Cost for the same job#
Take 1,000 runs of a sandbox with 2 vCPUs (one physical core on Modal) and 4 GiB. Each run lasts 60 seconds and keeps the CPU busy for 20 CPU-seconds. This is an agent that spends most of its time waiting for a model.
- CPU
- 1,000 × 20 s / 3,600 × $0.025
- $0.14
- Memory
- 1,000 × 60 s / 3,600 × 4 × $0.0075
- $0.50
- CPU
- 1,000 × 60 s × 1 core × $0.00003942
- $2.37
- Memory
- 1,000 × 60 s × 4 × $0.00000667
- $1.60
- Saving: 84%, or $3.33 per 1,000 runs.
- Per month: at 100,000 runs, $63.89 on Runtime against $396.60 on Modal.
- Busier work: with both CPUs busy for the whole minute, $1.33 on Runtime against $3.97 on Modal. At this size, Runtime is cheaper however busy the sandbox is.
A smaller request lowers Modal's figure. It also caps what the sandbox can use when it needs more. Plan fees, storage, network, taxes and free credits are left out of both. On Runtime, inbound traffic is free. Each account's first 100 GiB out a month is free. After that, outbound traffic costs $0.02 per GB (10⁹ bytes). See pricing for Runtime's terms.
How to switch#
Give your coding agent the one instruction in migration. It replaces the Modal calls on a branch, tests them on the free usage, and tells you what you save each month. Your old code stays on the main branch until you merge.
Change one import
Runtime's SDK runs code written for Modal's Sandboxes, as this page describes
from version 0.25.0 (Python 0.23.0), for Modal's JavaScript SDK 0.11.1 and
Python SDK 1.6.2. Change the import and set RUNTIME_API_KEY:
TypeScriptimport { ModalClient } from "withruntime/modal"; // was: from "modal"Pythonfrom withruntime import modal # was: import modalA Modal token is never needed or sent. Apps group sandboxes by name. Images
build from the same registry tags and Dockerfile steps. Commands run as
root, as in a Modal container. A timeout (timeoutMs) ends the sandbox. An
idle_timeout (idleTimeoutMs) pauses it with its memory kept, waking at
the next command, file call or tunnel request. Outbound domain and CIDR
allowlists, tunnels, tags, names, file calls and watches, filesystem snapshots,
and in Python memory snapshots work as Modal documents them. Each of Modal's
sandbox examples was run against Runtime on 18 October 2026, in both
languages.
What the drop-in refuses
These stop with a CompatibilityError before anything is created. The
message names what to use on Runtime:
- GPUs. Runtime runs on CPUs.
- Modal Classes, Dicts, Queues, web endpoints and Functions without a
schedule. Run the code in a sandbox. A Function with a
scheduledeploys as a job. - Named secrets (
Secret.from_name,secrets.fromName). Runtime's secrets are used without being seen. Store one withruntime.secrets.set, or pass values withSecret.from_dict(secrets.fromObject). - Secrets in image build steps. A Runtime build keeps no secret. Use the secret when the sandbox runs instead.
- Volumes made on first use (
create_if_missing, ephemeral volumes) and volume sub-paths. A Runtime volume has a fixed size. Create it first, then mount all of it. - Sidecars. Start a second sandbox and join both to a private network.
- Connect tokens and custom domains on a tunnel. Share the port as a private preview instead.
- Directory snapshots and exit snapshots. Take a filesystem snapshot
before
terminate(), then start new sandboxes from it. - Proxies and inbound CIDR allowlists. Use Runtime's static outbound addresses and network rules.
COMPATIBILITY.md in each package lists every mapping.
Or port the calls
Modal:
Pythonimport modalapp = modal.App.lookup("my-app", create_if_missing=True)sb = modal.Sandbox.create(app=app)process = sb.exec("python3", "-c", "print(sum([125, 250, 375]))")print(process.stdout.read())sb.terminate()Runtime:
Pythonfrom withruntime import Sandboxwith Sandbox.create() as box: box.files.write("/workspace/invoice.py", "print(sum([125, 250, 375]))\n") print(box.exec("python3 /workspace/invoice.py", check=True).stdout)When Modal may fit better#
- GPUs. Modal sandboxes can use GPUs. Runtime runs on CPUs.
- A wider platform today. Functions and web endpoints sit beside sandboxes in the same account and SDK. Runtime has scheduled jobs beside its sandboxes, but not functions or endpoints.
Sources#
Checked 23 September 2026; plan features checked 27 September 2026.
Try it on your own work. Sign up, then paste the setup prompt into your coding agent.