Tier 4 — Computer-use agent

A full graphical desktop with screen, keyboard and mouse, in a full VM from a warm pool. Seconds and highest cost.

Tier 4 gives the agent a whole computer: a graphical desktop it sees as pixels and drives with a virtual keyboard and mouse. It is the tier of last resort, and the most expensive thing the platform sells.

Not built, and not in the current engineering plan

Tiers 0–3 are built and confirmed live (runc, gVisor, Kata microVM — Tier 3 runs a real browser on that same Kata runtime as Tier 2). The engineering side's current tier decision (ADR-0013 in workspaces-build-compute, final) stops at four tiers, not five — its Tier 3 ("machine agents": full cloud VMs via a provider SDK, for GPUs and long-lived workloads) is the last rung in that plan. There is no fifth tier in it today. Treat this page as this site's own product vision — a graphical desktop agent is a real possible future, but not a confirmed, numbered tier in the current build roadmap.

Capability


Desktop	X11 or Wayland session, XFCE by default, GNOME and Windows on request
Input	Absolute and relative mouse, full keyboard, scroll, drag, clipboard
Output	Screenshots, continuous video stream, OCR-assisted screen text
Applications	Anything installable in the template, including native and GUI apps
Network	Through the egress proxy, same posture as tier 3
Peripherals	Virtual camera, virtual microphone, virtual printer, on request
Resources	2–16 vCPU, 4–64 GiB, 20 GiB–1 TiB disk, optional vGPU
Co-tenancy	None on the physical core — tier 4 runs at 1:1
Lifetime	Idle timeout 1–60 m, maximum lifetime up to 12 h

Runtime: full VM from a warm pool

Tier 4 is a conventional hardware-virtualised guest with a complete device model, because a desktop needs devices a microVM does not have: a framebuffer, input devices, sound, sometimes a GPU.

The device model has to be full, because a desktop needs devices a microVM deliberately omits. Placement compensates: no co-tenancy on the physical core.

The warm pool is what makes tier 4 usable at all. A cold desktop VM — boot, display server start, session login, application preload — is around 45 seconds. Pool instances are pre-booted to a logged-in desktop and held at a memory snapshot, so a claim resumes rather than boots.

Warm pool depth is a cost decision

Every pooled tier 4 instance occupies real, non-oversubscribed capacity whether or not anyone is using it. Pool depth per template is an explicit, priced choice — a customer that needs guaranteed sub-10-second starts for twenty concurrent desktops is buying reserved capacity, not just usage. See capacity planning.

Latency


Warm p50	2.5 s
Warm p95	6 s
Cold p95	45 s

The warm path is memory-snapshot resume plus display attach. The cold path is a real boot. For latency-sensitive products, create the session speculatively while the model is still planning.

Automation surface

Observe

curl -sS "$WB_BASE_URL/sessions/$SESSION/desktop/screenshot?format=webp&scale=0.5" \
  -H "Authorization: Bearer $WB_API_KEY"

Response includes the image plus optional structured hints:

{
  "image_b64": "…",
  "width": 1280, "height": 800, "scale": 0.5,
  "windows": [
    { "id": "w_3", "title": "Invoices — LedgerPro", "rect": [0, 24, 1280, 776], "focused": true }
  ],
  "text_regions": [
    { "text": "Export to CSV", "rect": [812, 140, 104, 24], "confidence": 0.98 }
  ]
}

windows comes from the guest's window manager and text_regions from guest-side OCR. Both exist so the model does not have to locate everything from raw pixels, which is slow, costly and error-prone.

Act

curl -sS "$WB_BASE_URL/sessions/$SESSION/desktop/act" \
  -H "Authorization: Bearer $WB_API_KEY" -H "Content-Type: application/json" \
  -d '{
    "actions": [
      { "type": "move",  "x": 864, "y": 152 },
      { "type": "click", "button": "left" },
      { "type": "key",   "combo": "ctrl+s" },
      { "type": "type",  "text": "q3-invoices.csv" },
      { "type": "key",   "combo": "Return" },
      { "type": "wait",  "ms": 500 }
    ],
    "observe_after": true
  }'

Coordinates are in the full-resolution screen space regardless of the scale used for observation; the platform rescales so a model working from a half-scale screenshot does not have to.

Live view

wss://connect.workspaces.build/v1/sessions/{id}/desktop?token=wb_st_…

WebRTC video plus an input channel. Used by the dashboard's live view and by human-in-the-loop handoff, where a person takes over a stuck agent's desktop. Handoff is a first-class flow: the platform downgrades the agent's input channel to read-only, grants the human input, and records the transition in the audit log.

Metering

Meter	Unit	Notes
`tier4.session_s`	seconds	Wall clock in `running`, the dominant line
`desktop_s`	seconds	Desktop session active, separate from VM uptime
`cpu_ms`, `mem_gib_ms`, `disk_gib_ms`	—	As tier 2
`vgpu_s`	seconds	When a vGPU is attached
`egress_gb`	GiB	At the proxy
`recording_gib_month`	GiB-month	Screen recordings
`pool_reservation_s`	seconds	Reserved warm-pool capacity, billed whether claimed or not

pool_reservation_s only appears for organizations that have bought reserved pool depth. It is the honest way to price a latency guarantee: the capacity is being held for you, so it is billed.

Security posture

Tier 4 has the widest blast radius in the product, so the compensating controls are the strictest:

No co-tenancy on the physical core. Tier 4 hosts run at 1:1 vCPU-to-core and never mix with other tiers, which removes the whole class of cross-VM side-channel concerns between tenants.
Disk is encrypted per session with a key held by the control plane and destroyed at teardown.
The VM is destroyed, never reused. A released tier 4 instance is torn down and its pool slot refilled from a clean snapshot. No session's state is ever visible to the next.
Recording defaults off, retention is explicit. A desktop recording may contain anything the agent saw, including credentials typed into a form.
Clipboard and file transfer are mediated through the API and logged, not through a transparent host-guest channel.

See isolation model.

When to use it, honestly

Tier 4 is correct when there is no programmatic surface: a vendor's Windows-only thick client, a legacy ERP, an installer, a desktop application under test. It is incorrect whenever a web UI, an API or a CLI exists — which is most of the time.

Before committing to tier 4, check in order: is there an API (tier 0), a CLI (tier 2), a web UI (tier 3)? Only when all three are no is a desktop the right answer.