Cua: A Unified Open-Source Stack for Computer-Use Agents, Drivers, and Benchmarks

What Cua Actually Solves

Computer-use agents need three things: a way to see and control a desktop, a sandbox to run in, and a way to measure progress. Most projects tackle one piece. Cua tries to cover all three in one repository. The README positions it as a stack for scaling computer-use 2.0, with open-source drivers, cross-OS fleets, and benchmarks. The target user is an engineer building an agent that clicks buttons and types, whether for testing, data generation, or model training. The project splits into four components: Cua Drivers for background automation, Cua sandboxes for isolated environments, Cua Bench for evaluation, and Lume for macOS virtualization. That breadth is both the appeal and the risk. A single repo that promises drivers, sandboxes, and benchmarks risks doing none of them deeply. The documentation suggests each piece is real, but the integration quality is something you would need to verify.

Background Drivers: The Core Mechanism

The driver component is the most distinctive part. It lets agents click, type, and verify in native desktop apps without stealing the cursor or focus. That is a hard problem on all three desktop OSes. The README claims support for macOS, Windows, and Linux, with Linux covering X11 and compositor-specific Wayland routes. The phrase 'explicit limits for raw background input' is telling. Background input on Wayland is not a solved problem. Compositors like GNOME's Mutter or KDE's KWin handle input synthesis differently, and some do not allow it at all. The driver exposes a CLI and an MCP server, so it works from Claude Code, Cursor, Codex, and custom clients. The install is a one-liner for macOS and Linux, and a PowerShell command for Windows. The mechanism appears to be a local service that injects input events at the OS level, but the README does not detail how it avoids focus stealing. That is a gap you would need to fill by reading the source in libs/cua-driver.

Sandboxes: One API for Any OS

The Cua sandbox SDK provides a single Python API for creating and controlling VMs or containers. The example is concise: import Sandbox and Image, then call methods like shell.run, screenshot, mouse.click, keyboard.type, and mobile.gesture. The same code works for Linux, macOS, Windows, and Android, according to the README. That is a strong promise. The table shows support for both cloud (cua.ai) and local QEMU, with BYOI (bring your own image) support for local. The Python API requires 3.11 or later, which is a reasonable floor. The design choice is to abstract away the runtime. You do not care if the sandbox is a Docker container or a QEMU VM; you call the same methods. That abstraction is useful for training data generation, where you want to run thousands of parallel environments without rewriting code. The trade-off is that you lose runtime-specific control. If you need to tweak QEMU flags or container networking, you are back to the underlying tools.

Cua Bench: Evaluation and Training Data

Cua Bench is the evaluation piece. It runs computer-use agents on existing benchmarks like OSWorld, ScreenSpot, and Windows Arena, plus custom tasks. The CLI is straightforward: install with uv, create a base image, then run a benchmark with an agent. The command 'cb run dataset datasets/cua-bench-basic --agent cua-agent --max-parallel 4' shows how to parallelize evaluation. The README also mentions exporting trajectories for training, which is a key feature for RL environments. This is not just a benchmark runner; it is a data generation tool. The registry at cuabench.ai suggests a growing set of tasks. The main limitation is that the benchmark suite is not described in detail. Which OSWorld version, which ScreenSpot split, and how custom tasks are defined are not covered in the README. You would need to consult the docs or the source to know if it fits your evaluation needs.

Lume: macOS Virtualization with Caveats

Lume is the macOS-specific component. It uses Apple's Virtualization.Framework to create and run macOS and Linux VMs with near-native performance on Apple Silicon. The install and usage are simple: install, download an IPSW, create a VM with an unattended preset, and run it. The presets for sequoia and tahoe configure the guest with a user, SSH, autologin, and disabled sleep. The README is honest about a known issue: the Tahoe flow is E2E verified, but Sequoia may still open the Accessibility step of Setup Assistant on first display boot. That is a concrete limitation. The default credentials are lume/lume, which is fine for a sandbox but a security risk if you expose the VM to a network. The bigger issue is that macOS virtualization only works on Apple Silicon, so this component is irrelevant for Intel Macs or non-Mac hosts.

Installation and First Steps

Getting started depends on which component you need. For drivers, run the curl or PowerShell install script, then follow post-install instructions. For sandboxes, pip install cua and use the Python API. For benchmarks, clone the repo, install with uv, and create a base image. For Lume, use the install script and then the lume CLI. The README points to docs for tutorials and references, but the core commands are all there. One thing to note: the driver install script is a remote curl pipe, which is convenient but carries supply-chain risk. You should inspect the script before running it, especially in a corporate environment. The same applies to the Lume installer. The project is MIT licensed, so you can audit the code, but the install path encourages trust in the hosted script.

Maintenance, Licensing, and Limitations

The repository is actively maintained, with recent releases for the computer server and nightly Lume builds. The MIT license is permissive, allowing commercial use and modification. The main limitations are the Wayland background input limits, the Sequoia VM issue, and the lack of detail on the benchmark suite. Also, the README is a landing page; it does not describe the architecture of the driver or the sandbox internals. That means you cannot assess security or performance without diving into the source. The cloud service (cua.ai) is a paid option, but the local QEMU path is free. The project is young, and the breadth of components means each one may have rough edges. The nightly builds suggest rapid iteration, which is good for features but bad for stability if you need a fixed version.

Editorial conclusion

Adopt Cua if you are building or evaluating computer-use agents and need a single API for sandboxes across OSes, or if you want background desktop automation without cursor stealing. Skip it if you need stable macOS VM support beyond the Tahoe preset, or if you require production-hardened background input on Wayland, which the repo explicitly limits. Before adopting, verify the current state of the Sequoia Setup Assistant issue (#2155), test the driver on your specific compositor, and confirm the cloud service availability for your target OS. The project is MIT-licensed and under active development, but the boundaries are clear: background input on Wayland, macOS VM quirks, and the maturity of the benchmark suite are the areas to check first.

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes