Skip to content
DrumsDocs

Get started

Drums documentation

Isolated Linux desktops for computer-use agents. Create one, act in it, fork it, and score it through one API.

Drums gives your agents real Linux desktops to work in: each desktop is an OSWorld Ubuntu machine with a 1920 x 1080 screen, restored from a checkpoint for every episode. You drive a desktop with pyautogui code or shell commands, read it with screenshots, and score it with the task's own checker. Every episode also carries a gate report that says whether the desktop was correctly restored and isolated, so you train or report only on rewards from valid episodes. A running desktop can be saved, or forked into N independent copies of the same state, which is how group rollouts start from one reached state. Desktops run on a worker host dedicated to your workspace, behind a gateway that checks your API key, its scopes, your quotas and your spend cap.

  1. Workspace
    console.drums.run
  2. API key
    Your code
    pip install drums-sdk
  3. HTTPS
    Gateway
    beta.drums.run/gw
  4. bound host
    Worker host
    single-tenant, runs drumsd
  5. restore · fork
    Desktops
    1 … N per host
  1. 1

    Workspace. Members and roles, limits and spend cap, audit log. A member creates an API key here; it is shown once.

  2. 2

    Your code. The drums Python package, the MCP server, or any HTTP client, sending the key as a Bearer token over HTTPS.

  3. 3

    Gateway. Checks the key, its scopes, your quotas and spend cap; maps ids to your workspace; writes the audit log.

  4. 4

    Worker host. A Linux host that serves your workspace only. One running OS and application set, shared by every desktop on it.

  5. 5

    Desktops. OSWorld Ubuntu, 1920 × 1080, 4 vCPU and 4 GiB each, in separate namespaces with no network. Restored from a template, forked, stepped and verified.

People manage the workspace in the console. Programs use an API key against the gateway, which serves only the worker host bound to that workspace.

Start here

What is available in this version

CapabilityHowStatus
Create, act in, observe and close desktopsPython SDK or HTTP API, with an API keyAvailable
Score an episode with the task's checker, with its validityenv.verify() / POST /v1/slots/{id}/verifyAvailable
Save a desktop's state; fork N copiesenv.save(), env.fork(n) / capture, branchAvailable
Drive desktops from Claude Code, Cursor or CodexMCP server: the gateway's /mcp endpoint or drums mcpAvailable
Watch a desktop from the consoleScreenshot viewer, observation onlyAvailable
Scripted test runsRuns > New run in the console, POST /v1/runs or client.create_run(); keystroke recipesAvailable for a few OSWorld tasks
Model evaluation runs from the consoleRuns > New run, model endpointNot offered yet: none verified end to end on this deployment
Training runsNot offered in this version
BillingNot enabled. Compute cost is measured and labelled "not billed"

You can evaluate a model today by driving desktops from your own code: see Evaluate a model on OSWorld tasks.

Names

The console, the SDK and the HTTP API grew up with different words for the same things. They are interchangeable:

ConsolePython SDKHTTP API
ComputerEnvslot (/v1/slots)
Snapshot (saved state)State, from env.save()checkpoint (/v1/checkpoints), made by capture
Forkenv.fork(n)branch
Template (base image)image="osworld-ubuntu"checkpoint id osworld-ubuntu
Restartenv.reset()reset
Terminateenv.close()DELETE /v1/slots/{id}

Ids are shared: the computer id in the console is env.id in the SDK and the {id} in /v1/slots/{id}.

Endpoints

URL
Consolehttps://console.drums.run (invited teams)
Gatewayhttps://beta.drums.run/gw
OpenAPI documenthttps://beta.drums.run/gw/openapi.json
MCP server (remote)https://beta.drums.run/gw/mcp