workspaces.build
Agent compute as an API. Five isolation tiers, from a lightweight container to a full VM — each metered per second and billed to the organization or the end user that used it.
The tier model in one picture
Tiers 0–3 are built and match this diagram: runc, gVisor, and Kata (a real microVM) — Tier 3's
browser capability runs on that same Kata runtime, confirmed live, not a separate isolation tier.
Tier 4 is this site's own product vision, not the current engineering plan — which stops at four
tiers, not five, and folds browser capability into Tier 2 rather than giving it a separate tier. See
the tier model's own status note for the detail.
Who this documentation is for
Developers
You are calling the API from an agent framework, an application backend, or an SDK. Start with the quickstart, then choosing a tier and the API design principles.
Infrastructure
You run the fleet: hypervisors, warm pools, egress proxies, the metering pipeline. Start with the system overview, then scheduler and warm pools and the SLOs.
What the platform does
workspaces.build sells agent execution, not virtual machines. The unit of sale is a bounded agent action — a code evaluation, a shell command, a browser task (confirmed live), and (as product vision, not yet built — see the tier model's status note) a desktop task — executed inside the weakest isolation boundary that can safely contain it, charged for exactly as long as it ran. There is no platform-managed tool/MCP catalog (decision log, ADR-012): your own code calling a tool is ordinary code the platform runs, not a separate product surface.
Three things follow from that framing and shape the whole design:
- Tiering is a first-class product concept, not an implementation detail. Callers declare a tier. The tier fixes the capability set, the isolation boundary, the start-latency class and the price. See tier model.
- Start latency is a product feature. An agent loop that waits four seconds for a sandbox is a different product from one that waits forty milliseconds. Warm pools, snapshot restore and pool-aware placement are the designed answer to that — not yet built; today's cold boot is the only path. See scheduler and warm pools.
- Billing has two subjects. The organization is always the payer. The end user — the
organization's own customer — is the optional second subject usage is attributed to:
end_user_idis a real, captured field today, letting a reseller meter and attribute usage per seat. The actual caps, rebilling and invoicing on top of that attribution are designed, not yet built. See end-user billing.
Start reading
Core concepts
Organizations, projects, sessions, runs, templates, volumes, snapshots, policies.
System overview
Edge, control plane, data plane and the metering pipeline, end to end.
Metering model
Every meter, its unit, where it is emitted and how it is rated.
Dashboard surface map
What the customer console and the infra console each own.