The right sandbox for every agent action.

Run the code, shell commands and browsers your agent needs through one API. Each action gets its own isolated sandbox, sized to the job. It starts in milliseconds and bills by the second.

One API
Code, shells and browsers. Desktops later.
Per action
Isolation picked per call, from container to microVM.
~400×
Cheaper when your agent's steps are split by what each needs.
Per customer
Usage, quotas and spend caps for every end user.

Your agent can write the code. Running it is the hard part.

  1. One prompt injection away from your servers.

    Agents follow instructions an attacker can influence. Run model output on a shared host and a poisoned web page can become a shell on your infrastructure.

  2. Every cold start, multiplied.

    An agent makes dozens of calls per task. A slow sandbox start gets paid on every one of them, and your users feel it.

  3. A bill nobody can explain.

    Teams keep big VMs warm to avoid cold starts, then pay for idle. And when a customer's agent runs away, nobody can say which customer it was.

One API for everything your agent does outside the model

Your agent decides. workspaces.build starts the sandbox, runs the action, streams the result back and tears it all down.

  1. CodegVisor sandbox

    Run code

    Execute Python or Node your model just wrote, in a gVisor sandbox with its own kernel. Get stdout, the exit code and the cost back in one call.

    df.groupby("month").refunds.sum().plot()
    exit 0  · 412 ms · chart.png
    Code agent tier
  2. ShellDedicated microVM

    Work in a shell

    Give your agent a real Linux machine with root, git and your toolchain. Clone, build, test and migrate inside a dedicated microVM, with a /workspace that persists between calls.

    /workspace $ git clone … && pnpm test
    142 passed  · 38 s
    CLI agent tier
  3. BrowsermicroVM + Chromium

    Drive a browser

    Headless Chromium for JS-heavy pages, logins and sites with no API. Every request goes through a filtering proxy your agent can't route around.

    egress portal.example.com  allowed
    egress unknown-host.io     blocked
    Browser agent tier
  4. DesktopComing later

    Use a desktop

    A full VM with a real screen for software that has no API at all, like legacy desktop apps and Windows-only clients.

Don't run a tool call in a desktop VM

Most sandbox platforms hand every task the same heavy machine. workspaces.build gives you five sizes, called tiers, from a plain container to a full VM. You pick one per action. Capability, isolation, start time and price all move together, so you only pay for the boundary you need.

  1. Tier 01×
    Your own trusted code

    Hardened container · 5 ms start target

  2. Tier 1~8×
    Code the model wrote

    gVisor sandbox · 90 ms start target

  3. Tier 2~25×
    Shells, CLIs, real files

    Dedicated microVM · 180 ms start target

  4. Tier 3~25×
    Browsers

    microVM + Chromium

  5. Tier 4~150×
    DesktopsComing later

    Full VM, no co-tenancy

Relative cost, Tier 0 = 1×. Units, not prices, until the rate card is published.

~400× cheaper.

The same four-step agent costs about 34 units split by action, versus 13,500 in one desktop session.

Rule of thumb. If an API will do, don't open a browser. If a browser will do, don't boot a desktop.

The tier you ask for is the tier you get. No silent upgrades, no surprise line items.

Everything under the action, handled

Starts before your model finishes thinking

Sandboxes come from warm pools, not cold boots. Start a session while the model is still generating, and the start disappears into inference time.

Tier 0 · 5 msTier 1 · 90 msTier 2 · 180 ms
  • Locked down by default

    Planned

    No outbound network access until your policy allows a destination. Every connection is logged with the rule that allowed or blocked it.

  • Pick up exactly where you left off

    Planned

    Snapshot a session with its memory, shut it down and restore it hours later with your dev server still listening. Volumes keep a repo or dataset around between sessions.

  • Pay for seconds, not servers

    Every session is metered by the second and shows its cost to date. Read usage by meter within about a minute.

Reselling agents? Know what every customer costs.

If your product runs agents for your own customers, "what did this cost?" is a per-customer question. workspaces.build answers it with one field.

  1. Tag it once.

    Add end_user_id to any session and every second, CPU cycle and byte it uses is tagged to that customer.

  2. Cap each customer.

    Planned

    Set concurrency limits per tier and a spend cap per customer. A free-plan user with no desktop allowance simply can't start a desktop. No prompt injection changes that.

  3. Rebill with real numbers.

    Export usage per session with its rated cost and turn it into invoices, credits or fair-use limits. Your pricing stays your decision.

Tag from day one. Usage is attributed when it's recorded, so it can't be backfilled later.

# tag the session
POST /v1/sessions
{
  "tier": 2,
  "end_user_id": "cust-4821"
}

GET /v1/usage?group_by=end_user_id

  • cust-4821Tier 2841,100 s
    1,842 units
  • cust-1190Tier 3182,200 s
    924 units
  • untagged
    12 units

The untagged line is the leak. Watch it shrink to zero.

From API key to running action in one call

  1. Pick a tier.

    Choose the smallest sandbox that can do the job: a container, a code sandbox, a microVM or a browser.

  2. Send the action.

    POST /runs with your code or command. We start the sandbox, run it and release it. Need state? Open a session and run as many commands as you like against the same /workspace.

  3. Get the result and the cost.

    You get stdout, the exit code, the duration and a usage block covering CPU, memory, time and egress on every run.

Built on the assumption that your agent will be tricked

We assume every instruction reaching a sandbox could be attacker-influenced. So no single control is trusted, and each layer assumes the one above it has already failed.

  1. Real isolation, not just containers

    Model-written code runs in gVisor, with no direct syscalls to the host. Shell and browser work gets a dedicated microVM with its own kernel.

  2. No way out unless you allow it

    Default-deny egress, DNS through the proxy and a hard block on cloud metadata endpoints.

  3. Nothing to steal inside

    A sandbox holds no platform keys and no cloud credentials. We never need your model API keys.

Get early access

We're letting teams in over several waves. Tell us what your agent does and we'll set you up on the right sandbox from day one.

What does your agent need to do? Select all that apply

Do you run agents for your own customers?

One email when your spot opens. No spam.

An API that runs the things your AI agent does outside the model, like executing code, running commands and driving a browser, in isolated sandboxes. You pay by the second for exactly the sandbox each action needs.

Three things. One API covers code, shells and browsers, with desktops coming later. You choose the isolation level per action instead of getting one size for everything. And usage can be tagged and capped per end customer, which matters if you resell agents.

Any of them. Your agent loop and model calls stay with you. We never see your model keys. Any framework that can make an HTTP call can use workspaces.build.

You pay per second of sandbox time plus the resources used, at a different rate per tier. We'll publish the rate card before general access. Until then, the relative costs above show how the tiers compare.

We're opening in waves. Join the waitlist and tell us what your agent does, and we'll reach out when there's a spot that fits.

Stop paying desktop prices for tool-call work.

Give every agent action the smallest sandbox that can do it. Declare the tier, run the action, pay by the second.