Linux desktop instance API for LLM tool use

A service or library that gives your agent loop a fresh Linux machine with a graphical desktop, exposed through a programmatic interface (start/stop, screenshot, click, type, run a shell command, list files), so an LLM with computer-use tool calls can act on a real OS without touching your laptop.

Four that I would call canonical. E2B Desktop Sandbox, open source at github.com/e2b-dev/desktop, Linux with Xfce, Python and TypeScript SDKs. Scrapybara, hosted out of Y Combinator, with Ubuntu, Browser, and Windows instance types and a published price list of free, $29, $99, and Enterprise. Anthropic's reference computer-use-demo Docker container, the one their team ships at github.com/anthropics/anthropic-quickstarts under computer-use-demo, with VNC on port 5900 and a Streamlit UI on 8501. And E2B's Open Computer Use, a separate repo specifically for driving the E2B Desktop with open source LLMs. There are smaller variants and forks; everyone else worth naming is a wrapper over one of these.

Because Linux is the only desktop OS you can legally and cheaply spin up by the thousand inside someone else's cloud. Windows desktop instances exist (Scrapybara has them) but the licensing math is meaner, and macOS instances effectively cannot exist this way at all because Apple's licensing only allows macOS guests on Apple hardware. So the entire instance category is shaped by the Linux license: it is the cheapest disposable desktop you can build a per-call billing model on top of.

Anthropic's own README is explicit about this: do not send the model screenshots above XGA. The default in their reference container is 1024x768. You can override with WIDTH and HEIGHT environment variables, but if you exceed XGA the recommended pattern is to scale down before sending to the model, let it interact with the scaled image, and map coordinates back proportionally. The reason is image resizing on the model side: high-resolution captures get downsampled anyway, and the click coordinates the model returns are inferred from the size it actually saw.

An instance API gives the agent a fresh, stateless Linux box that has nothing in it, by design. A native desktop agent runs on the user's actual logged-in machine and inherits everything the user is already authenticated to, including their browser session, their email, their calendar, their open Slack threads. The two solve different problems. Instance APIs are right when the model needs a sandbox to do work that nobody is watching (a long scrape, a destructive experiment, a multi-hour data job). A native agent is right when the model needs to act on real state the user is in the middle of. Calling them substitutes is the most common mistake in this space.

All four expose the same five-ish primitives: take a screenshot, move the mouse, click, type a string, and run a shell command. Scrapybara also exposes a structured 'computer' tool that wraps these into a single Anthropic-compatible function-call schema; E2B Desktop's SDK gives you a sandbox object with .screenshot(), .mouse_move(), .left_click(), .write(), .run_command(); the Anthropic reference container exposes them as the computer_20241022 tool spec the model is trained against. The differences between the APIs are mostly auth, billing, and which tool spec your loop is already wired to.

Fazm is in the other category, the native one, on macOS only. It does not give you a Linux desktop instance. It is a Mac app that uses the macOS Accessibility API on the user's actual machine. The point of mentioning it on a page about Linux desktop instance APIs is to draw the line. If your prompt is 'do something on a fresh Linux box', pick one of the four above. If your prompt is 'do something in the user's real Chrome and their real Mac apps', no Linux instance API can reach there. The honest contrast also surfaces a failure mode native agents have to handle that instance APIs do not, which is at AppState.swift:517 and described below.

On a Linux desktop instance you control the entire OS image, so the AT-SPI accessibility tree is consistent. On a user's Mac you do not. Some apps publish a clean accessibility tree (most native AppKit apps, most Catalyst apps, most Electron apps via the AX shim). Other apps return AXError.cannotComplete because they are Qt, OpenGL, or Python bindings that never wired up the AX shims, with PyMOL being the named example in the source. Fazm's AppState.swift function testAccessibilityPermission cannot tell from a single .cannotComplete whether the system permission is genuinely broken or whether the frontmost app just does not implement AX. So it falls back to running the same probe against Finder, which is a known good AX target, and only declares the permission broken if Finder also fails. Lines 480 to 534 of AppState.swift in github.com/m13v/fazm. There is no equivalent to this in any Linux desktop instance API because the provider chose every app on the image.

E2B Desktop and Open Computer Use are. The Anthropic reference container is open source code wise, but the agent loop you point at it can call a paid Anthropic, AWS Bedrock, or Vertex API. Scrapybara has self-hosting on the Enterprise tier per their pricing page, otherwise it is a hosted SaaS. Fazm is also open source and MIT-licensed at github.com/m13v/fazm, but again, different category, native macOS, not a Linux instance.

Spin up Anthropic's reference Docker container locally. One docker run, ANTHROPIC_API_KEY in an env var, and you have a Linux desktop with a Streamlit UI, a VNC server, and an agent loop that drives Claude on it. The model API tokens are the only cost. After that, if you want hosted infrastructure, Scrapybara has a free tier of 10 compute hours per month and E2B Desktop's hosted version comes with the broader E2B free tier. The cost ladder is roughly: local Docker free, hosted free tier for prototyping, $29 to $99 for production-ish use, Enterprise from there.