Cua

A one-sentence summary

Cua is an open-source infrastructure designed for Computer-Use AI agents; it enables models to monitor screens, click, type, execute code, and record reproducible actions within isolated Linux, Windows, macOS, or Android environments.

Tool Introduction

Cua was developed by Cua AI, Inc., and is intended for teams involved in the development, evaluation of AI agents, as well as in tasks related to reinforcement learning and data generation. It offers both a local, open-source sandbox, as well as dedicated machine clusters for cloud deployment, BYOC, or local use, which can be requested as needed.

The product is not a chatbot designed for ordinary users; rather, it is a set of tools for driving, sandboxing, SDK development, virtualization, and benchmarking. Users need to have an understanding of Python, virtual machines, containers, operating system permissions, and proxy security.

Core components

Main functions

Cross-operating-system sandbox

The same Sandbox and Image interfaces can be used to create Linux containers, Linux virtual machines, as well as macOS, Windows, and Android environments. These environments can run on local Docker, QEMU, Hyper-V, or Apple virtualization backends, or they can be migrated to Cua Cloud.

Screen and input control

Agents can take screenshots, read window status, move the mouse, click, enter text via the keyboard, manage the clipboard, and perform gestures typical of mobile devices. By combining GUI operations with command execution, it is possible to replace software that offers only a graphical interface without stable APIs.

Background desktop driver

Cua Driver can send input to a specified application window, trying not to interfere with the user’s current mouse cursor, focus, or desktop space. It is suitable for carrying out both manual tasks and proxy tasks on the same machine, but it still requires screen recording capabilities, accessibility features, or appropriate system permissions.

Image building

An Image is an immutable, chainable description of an environment; it allows for the installation of system packages, Python dependencies, files, and initialization commands. Custom environments can also be created from OCI images, local disks, or ISOs.

Temporary, Persistent, and Connection Modes

Temporary sandboxes are destroyed after a task is completed, making them suitable for CI and one-time evaluations; named persistent sandboxes can retain their state across different processes; the Connect mode only connects to existing machines and is not responsible for creating or deleting them.

Snapshots and forks

Users can save the state of a disk that has undergone an expensive initialization process as an Image, and then start multiple write-time replication branches in parallel. Each branch has its own writable disk, without altering the original snapshot or the other branches.

Parallel machine clusters

Cua Fleets expands individual sandboxes into a pool of preheated machines, enabling the acquisition of environments in milliseconds and allowing for the parallel execution of evaluation tasks, reinforcement learning rounds, or data generation tasks. The official website currently offers dedicated clusters upon application.

Trajectory and data generation

Each screen observation and action can be recorded as a replayable trajectory, which is useful for debugging, evaluation, and training. The provider also offers data delivery services that include evaluators, manually reviewed optimal trajectories, and acceptance criteria.

Permission policy

Cua Driver allows you to specify, using YAML or Rego, which tools, applications, browser channels, and directories a proxy is allowed to access. These policies are enforced at the runtime level on the local machine; SDKs, CLI tools, MCP protocols, or socket calls cannot bypass these rejection rules.

Operating system and backend execution

The first tutorial on local sandboxes

1. Prepare a supported Python and Docker environment, and ensure that there are sufficient virtualization resources available.
2. Install the Cua Python package, and import Sandbox and Image into the project.
3. Choosing a Linux container for the initial testing helps avoid direct control of a personal host.
4. Start the environment using a temporary lifecycle, and first execute harmless system information commands.
5. Test the clipboard, screenshots, and mouse input, then save the results in a separate directory.
6. After the task is completed, verify that the temporary environment has been destroyed and that no sensitive files remain.
7. When reuse is needed, create explicitly named images or snapshots; do not misuse persistent sandboxes.

Install and restrict the Cua Driver

1. Install the stable version of the driver on supported macOS, Windows, or Linux devices.
2. Run diagnostic commands to check the binary, installation directory, telemetry, and platform dependencies.
3. Grant screen monitoring and auxiliary control permissions as indicated by the system; testing should be conducted only on dedicated accounts.
4. Prefer the standard or bounded mode; do not use the unrestricted mode by default.
5. Use YAML or Rego to explicitly permit screenshotting, window inspection, and necessary input tools; deny all other requests.
6. After starting the service, connect to MCP or SDK to verify the boundaries using a non-sensitive application.
7. Test strategies such as rejection, session cancellation, and abnormal termination are used, with authorization levels being increased gradually thereafter.

Batch evaluation workflow

1. Define the task, initial image, success criteria, timeout, and prohibited operations.
2. Multiple independent environments are created from a single unified snapshot, thereby preventing interference between different rounds.
3. Fix the model, prompt, random seed, and software version for each agent.
4. Run tasks in parallel and record the screen, actions, commands, rewards, and reasons for failures.
5. Use the automated evaluator to check the results, and then sample tracks for manual review.
6. Separate statistics are kept for environmental failures, agent decision errors, and evaluator misjudgments.
7. When publishing the results, record the Cua version, image hash, and license to ensure reproducibility.

Which users are it suitable for

• AI agent researchers: Developing cross-system Computer-Use benchmarks and reinforcement learning environments.
• Model evaluation team: Runs tasks in parallel to reproduce them and collect trajectory data along with success rates.
• Developer: Integrate screen monitoring, input control, and command execution with their own proxy.
• Desktop software team: Tests installation, file handling, and GUI workflows in an isolated environment.
• Data team: Generates operation trajectory data that has been automatically evaluated and manually reviewed.
• Enterprise AI Platform Team: A cluster of controlled desktop agents is established either using BYOC or through local deployment.

Typical use cases

• Test whether the agent can perform the same task with different themes, fonts, languages, and screen sizes.
• Have the encoding agent install applications on a temporary desktop, carry out GUI steps, and save screenshots.
• Parallelly evaluate tasks for browsers, Office, design, CAD, or legacy Windows software.
• Create an Android environment to install the test package and perform tap, swipe, and multi-touch gestures.
• Control specific application windows in the background of macOS, without moving the user’s current cursor.
• Organize the paths of success and failure into training, regression test, or behavior audit data.

Comparison of permission modes

The permission model only determines the default autonomous boundaries; user policies and administrator policies can be made more restrictive, but not beyond the built-in limits. Policies are loaded at the time a process starts, and any changes to them usually require restarting the process in order to take effect.

Price and deployment methods

As of August 2026, Cua does not provide any public pricing details for its cloud services on an hourly basis, per machine, or per seat. The local versions of Sandbox, Driver, Bench, and Lume are available via GitHub; for dedicated Fleets, hosted solutions, BYOC options, and local deployments, a customized plan must be requested.

The fact that it is open source and free does not mean that there are no costs associated with its use. Licensing for Windows and macOS, cloud hardware, storage, model invocation, manual annotation, and security operations can all become significant sources of expense.

Safety and privacy

• The Computer-Use agent can view the screen, type text, access the clipboard, and control applications; its permissions are equivalent to those of a powerful remote control capability.
• Give priority to using one-time sandboxes, test accounts, simulated data, and short-term credentials; avoid connecting directly to personal desktops.
• By default, the Cua Driver sends product telemetry without any content; this setting can be disabled via a command, allowing one to check the fixed events that will be sent.
• When telemetry is turned off, the anonymous installation identifier is retained; resetting it will delete this ID as well as any event markers.
• The official privacy policy states that AI functions may transfer inputs, outputs, and personal data to third-party AI service providers, including OpenAI.
• Personal information is retained for the purposes of providing services and in compliance with legal requirements; no fixed deadline is specified.
• The official website lists SOC 2 Type I, BYOC, and on-premises capabilities; however, companies should still request information regarding the current scope of the audit as well as the contract attachments.
• Before installing third-party mirrors, APKs, and proxy tools, it is necessary to verify the source, hash value, license, and for any signs of malicious activity.

Open source and licenses

The main repository of trycua/cua is licensed under the MIT license, which permits use, modification, distribution, and commercialization, provided that the copyright and license notices are retained. The software is provided as is, without any warranties regarding its marketability or suitability for a particular purpose.

Technical requirements

Product advantages

• A set of interfaces is available for Linux, Windows, macOS, and Android, facilitating the replication of experiments across different platforms.
• Placing code execution and GUI control within the same sandbox is suitable for real desktop tasks.
• Temporary environments, snapshots, and forks reduce the risk of tasks interfering with each other and lower the costs associated with repeated initialization.
• Open-source SDKs, drivers, virtualization technologies, and benchmarking tools facilitate auditing and expansion.
• Permission policies are applied uniformly within the native runtime environment, covering various types of access methods.
• It can be developed locally and gradually expanded to the cloud, BYOC, and dedicated parallel clusters.

Usage restrictions and precautions

• The desktop agent is sensitive to changes in the interface, latency, fonts, language, and pop-ups; its success rate cannot be determined just once.
• Some of the capabilities driven by the backend rely on mechanisms built into the operating system or related accessibility features; compatibility issues may arise after an upgrade.
• Local multi-system virtualization requires substantial hardware resources, and macOS and Windows are subject to licensing restrictions.
• There are no publicly available standard prices for cloud-based and dedicated clusters; the budget for such projects needs to be discussed separately.
• Although the main repository is MIT, the available models, parsers, mirrors, and applications each come with their own licenses.
• Incorrect policy configuration may inadvertently expose files, terminals, the clipboard, or the logged-in browser.
• The trajectory may contain personal information, keys, and customer data on the screen; it should be encrypted, minimized, and a deadline for its deletion should be set.
• Before performing actions such as deletion, purchase, sending messages, or public publication, manual confirmation is required.

API, SDK, and MCP

Cua provides a Python SDK, CLI, MCP server, and local Driver interface. Developers can use a unified Sandbox API to control commands, take screenshots, manage the mouse and keyboard, access the clipboard, and handle touch gestures; they can also integrate the Driver with MCP clients such as Claude Code, Cursor, and Codex.

SDKs and MCPs are merely entry points for accessing certain capabilities; for actual use in production, it is necessary to implement additional policies at the process boundaries, system permissions, network levels, and at the level of business operations. Do not rely on the model’s ability to reject natural language requests as the only means of ensuring security.

Basic information

Recommendation score

Its rating is 4.6 out of 5 points. Cua covers a wide range of systems, has well-defined open-source boundaries, and connects sandboxing, drivers, evaluation tools, and scalable clusters into a cohesive technical framework.

The main obstacles are the complexity associated with virtualization and security, the lack of transparency regarding cloud pricing, and the instability of desktop agents themselves. It is suitable for development and platform teams, but not for ordinary automation users who lack the capabilities for isolation and auditing.

Frequently Asked Questions

Is Cua free?

Local open-source frameworks can be used free of charge, but the costs related to hardware, system licenses, models, and maintenance must be borne by the user themselves. Cloud services, dedicated Fleets, BYOC options, and data services require a quote for pricing.

Which operating systems is Cua compatible with?

It supports Linux, Windows, macOS, and Android. Different systems use backends such as Docker, QEMU, Hyper-V, or Apple’s virtualization technology.

Is Cua an open-source project?

Yes, the main repository is licensed under the MIT license. Optional dependencies such as OmniParser, operating system images, and cloud-based commercial services require separate evaluation.

Can I control the current computer?

It is possible to connect to the current desktop using the Cua Driver, but this approach carries a higher level of risk compared to using an isolated sandbox. It is advisable to employ the bounded mode, grant minimal permissions, and use dedicated test accounts.

Is it possible to operate macOS applications in the background?

The driver allows events to be sent to a specific window without moving the main cursor, making it suitable for background operations. Compatibility still depends on the application, system version, and permissions.

Is MCP provided?

Available. MCP is suitable for connecting Drivers to proxy clients that support this protocol, with permission policies still being enforced locally at runtime.

Is it necessary to upload data to the cloud?

Not necessarily; the local mode can operate on one’s own hardware. When using Cua Cloud, third-party models, or hosted data services, the data path changes.

Can telemetry be turned off?

Yes. By default, the driver enables product telemetry without any specific data; users can turn this feature off, view the events, and reset the anonymous installation identifier.

Is it suitable for production automation?

It can serve as infrastructure, but it is necessary to first carry out isolation, permission setting, regression testing, manual approval, and fault recovery. A research demo cannot be considered equivalent to production-level reliability.

Can Android apps be installed?

APKs can be installed in Android images, and gestures such as tapping, swiping, and multi-touch can be performed. The installation packages still need to have their source, signature, and security verified.

Summary

Cua offers an open technology stack for Computer-Use agents, enabling transition from single local sandboxes to parallel clusters across multiple systems, while also taking into account tracking, evaluation, permissions, and various access methods.

It is recommended to first carry out minimal experiments in a temporary Linux environment, and then introduce persistent images, desktop drivers, and cloud clusters gradually as needed; each time new capabilities are added, permissions should be tightened accordingly and data boundaries verified.