Tier 0 — the lightest compute tier
Your own code, in a plain runc container — the weakest isolation boundary and the fastest, cheapest tier. No managed tool/MCP catalog.
Tier 0 runs your own code in a plain runc container — the same
code-execution capability as every other tier, just with the lightest isolation boundary: a shared
kernel, not a gVisor sandbox or a microVM. It is the tier for work that is fast and doesn't need a
stronger boundary than a hardened container gives you.
Tier 0 does not mean this platform manages a tool or MCP catalog on your behalf. That was an
earlier framing, corrected in ADR-012 of the decision log; the platform
is a compute provisioner of isolation tiers, nothing more. Tier 0 is
just a runc container that runs the code you send it — whether that code implements a tool-calling
loop, calls out to your own MCP servers, or does something else entirely is up to you. The platform
provides the runtime, not the catalog.
Capability
| Executes | The same kind: code / kind: command model every tier uses — your own code or a plain shell command |
| Isolation | A hardened runc container: non-root, capabilities dropped, RuntimeDefault seccomp, read-only root, no service-account token. Shared kernel — the weakest boundary of the three tiers in production today |
| Filesystem | Ephemeral, writable /tmp and /workspace, discarded at session end unless a volume is attached |
| Network | Default-deny, opt-in by policy allowlist, same egress model as every other tier |
| Resources | 1–4 vCPU, 256 MiB–8 GiB memory, 64 MiB–10 GiB disk |
| Process creation | Unrestricted inside the container, unlike Tier 1's gVisor sandbox |
Why it's the fastest, cheapest tier
No gVisor sentry to start, no microVM to boot — a plain container is the lightest thing this platform can schedule. That's the entire latency and cost argument for Tier 0: it trades isolation strength for speed, not capability. Tier numbers map directly to isolation strength: Tier 0 (shared kernel) < Tier 1 (gVisor) < Tier 2 (Kata microVM).
When to use it
- Work that genuinely doesn't need protection from its own code misbehaving — trusted, reviewed code you wrote yourself, not arbitrary model-authored code you haven't reviewed.
- The lowest-latency, lowest-cost option when Tier 1's gVisor overhead isn't needed.
When not to use it
- Running arbitrary model-authored code you haven't reviewed — that's what Tier 1's gVisor sandbox is for. Tier 0's shared-kernel isolation is the weakest boundary available; don't put untrusted code behind it expecting the same containment Tier 1 or Tier 2 give you.
- Anything needing a real shell workflow with installed tooling — see Tier 2.
API
Tier 0 uses the same session API as every other tier — see Sessions and
Runs and exec. The only difference is "tier": 0 on creation:
curl -sS "$WB_BASE_URL/sessions" \
-H "Authorization: Bearer $WB_API_KEY" -H "Content-Type: application/json" \
-d '{ "tier": 0, "execution_mode": "one_shot", "runtime": "python3.12" }'