What is Descanto
Instant-wake, persistent Linux desktops for computer-use agents.
Descanto is a cloud desktop platform built for computer-use agents. Every
desktop is a real, persistent Linux machine that an agent (or a human) can
wake in seconds, drive over exec/files/stream, and hibernate when it's
done -- state preserved, compute stopped.
The hibernation model
A Descanto desktop always exists once created -- its disk, its generation
history, its identity -- but it isn't always running. It moves through a
small set of lifecycle states (provisioning, waking, awake,
hibernating, hibernated, destroyed; see
Desktops and lifecycle), and
compute is only billed while it's awake. Hibernated desktops cost nothing
in hourly billing and keep their full disk state, ready to wake again on the
next POST /v1/desktops/{id}/wake.
That's the whole pitch: always there, pay only when it thinks. An agent that works in bursts -- a few minutes of tool use, then long stretches of waiting on a human or another system -- doesn't pay cloud-VM prices for the idle time in between.
How Descanto is built
Everything below is driven by one versioned surface -- the same routes whether you call them from curl, an SDK, the CLI, or an MCP client.
The Descanto REST API
A small, versioned REST API (/v1/**) is the one
source of truth: create/list/get/update desktops, wake/hibernate/destroy/
fork them, run commands (blocking or
detached),
read/write/list files (including
large-file chunked transfer), get a
stream ticket, and query usage. Every mutation
(wake/hibernate/destroy/fork/restore) returns an
operation handle you can poll or long-poll,
rather than blocking your connection open, and
webhooks notify your own server about desktop
lifecycle events (desktop.created, .woken, .hibernated,
.destroyed), HMAC-signed and with a full delivery log. The
machine-readable contract is published at
descanto.com/openapi.json.
Computer use, ingress, and snapshots
Computer use drives an awake desktop's GUI
directly -- screenshot, mouse/keyboard input as a single-round-trip
batch, and live display geometry.
Port ingress publishes any guest TCP port at a
stable https://{port}-{desktopId}.canto.host URL, token-gated or
public, plus an in-browser noVNC viewer on the dashboard.
Snapshots let you list a desktop's Generation
history and restore an earlier one, with branch semantics (nothing is
ever destroyed by a restore) and read-time retention buckets.
Descanto SDKs, CLI, and MCP server
A TypeScript SDK (@descanto/sdk) and a
Python SDK (descanto-vm) wrap the API with friendlier,
promise-/async-based clients and sensible retry/wait defaults. A
CLI (descanto, from @descanto/cli) drives every route from a
shell or a CI pipeline, with a --json contract for scripting. An
MCP server (@descanto/mcp) exposes the same operations
(including computer use and port ingress) as tools, so Claude Code,
Claude Desktop, Cursor, and any other MCP client can drive a Descanto
desktop directly. The developer portal collects all of
these plus how to get API keys.
Where to go next in the Descanto docs
Quickstart
Create your first desktop, wake it, run a command, and hibernate it -- with curl, the SDK, or MCP.
Concepts
Lifecycle states, operations, org scoping, and billing.
API reference
Every route, every status code, straight from the OpenAPI contract.
TypeScript SDK
@descanto/sdk: the ergonomic client.
Python SDK
descanto-vm: sync + async, mirrors the TypeScript SDK method-for-method.
CLI
canto: drive every route from a shell or CI, with --json for scripting.
MCP server
Drive Descanto desktops from Claude Code, Claude Desktop, or Cursor.
Early access
Descanto is early access. Desktops are manually provisioned -- see Quickstart: get access for how to log in and create an API key.