Shells vs Modal

Compute as a primitive vs sandboxes as a product.

Modal is an excellent serverless compute platform — functions, GPUs, scheduled jobs — and sandboxes are one primitive within it. Shells is the opposite shape: the sandbox is the whole product, with a human console, an agent gate, and lifecycle controls as the core surface rather than a corner of an SDK.

The matrix

Dimension by dimension.

Green check marks where we believe one side has a real edge. A dash means it's genuinely close — read the words, not just the dots.

Isolation model

Shells

Per-shell runtime class selection (wasm / container / microvm), sealed network by default.

Modal

gVisor-based containers under a Python-first serverless runtime.

Agent / MCP integration

Shells

MCP server is a shipping interface with product-native tools and entitlement gating.

Modal

Sandboxes SDK works well from agent code; MCP not the primary interface.

Lifecycle safety

Shells

Named capabilities incl. wipe_state and reinstall_os; danger-zone confirmation in the console.

Modal

Programmatic termination and timeouts; lifecycle is code-managed, console is observability-focused.

Credentials handling

Shells

Masked, short-lived term credentials for live sessions.

Modal

Workspace tokens and secrets store for code; standard platform auth.

Breadth of compute

Shells

Sandboxes only. No GPUs, no cron fleets, no batch pipelines — on purpose.

Modal

GPUs, autoscaling functions, volumes, scheduling — a full compute platform.

Pricing model

Shells

Per-second by isolation class; flat platform fee on Pro.

Modal

Per-second by CPU/GPU/memory consumed across the platform.

Choose Modal when…

  • You need GPUs, ML batch jobs, or a general serverless platform — that's their home turf.
  • Your team lives in Python decorators and wants infra expressed as code end-to-end.
  • Sandboxes are a minor part of a larger compute pipeline you'd rather keep on one vendor.

Yes, we mean it. Wrong-fit customers are expensive for everyone.

Choose Shells when…

  • You want a sandbox product with a real human console, not a primitive behind an SDK.
  • Agents are first-class callers and you want MCP + entitlements, not embedded SDK code.
  • You want wasm-class instant sandboxes for cheap, frequent, short-lived runs.
  • Filesystem-safe teardown (wipe_state) needs to be a product guarantee, not a convention.

Migration notes

Moving from Modal

The honest version: most migrations are a week of mapping calls, not a quarter of replatforming.

01

Identify which Modal workloads are actually sandboxes (untrusted/ephemeral code) — move only those.

02

Modal Sandbox.create → ShellsClient.create; map images to language presets or container runtime.

03

Replace terminate-and-recreate patterns with restart / reinstall_os / wipe_state as appropriate.

04

Keep Modal for GPU and batch — Shells doesn't pretend to do that.