Cua Launches Computer Platform for AI Agents With Cloud and Driver Tools
Cua releases agent computer infrastructure with isolated cloud machines, operation drivers, virtualization, and evaluation.
A computer-use agent infrastructure called Cua has been released. Coverage of trycua on GitHub Trending describes the development goal as follows.
Give AI agents computers they can use.
Users bring their own agents and models. Cua provides the computers and automation tools. Its scope covers open machine-operation automation, isolated cloud machines, local macOS virtual machines, and benchmark tasks for evaluation. Pooled compute resources for getting started are available at run.cua.ai.
The public documentation outlines four onboarding paths. They are: provisioning a Linux machine, running commands and saving a screenshot; operating a calculator and verifying the result; creating a Tahoe virtual machine and connecting via SSH; and building and verifying a mock task. Each is structured to deliver a first result in a short time.
Four Components Offered by Cua
Cua is not a single tool but a set of four components. The first is Fleet, which provides isolated cloud machines. The second is Driver, which operates machine apps and browsers. The third is Lume, which manages local virtual machines on Apple Silicon. The fourth is Bench, which builds computer-use tasks.
The four work together through the Sandbox SDK and command interfaces. Local sandboxes and Fleet share the same SDK. Credentials, images, operations, and runtime requirements differ, however. The design calls for selecting the environment using runtime support documentation. When operating on your own hardware, refer to the local sandbox lifecycle management documentation.
This separation has operational significance. Developers can focus on model selection and task design. Provisioning and cleanup of compute resources follow the infrastructure procedures. Note that paid capacity may remain after requests end.
How the Isolated Cloud Infrastructure Fleet Works
Fleet provides isolated cloud machines at run.cua.ai. Fleet itself maintains sandbox capacity. User code requests machines from the pool. After provisioning, users run commands, capture screens, and operate apps via the Sandbox SDK.
The first result is clearly defined. Provision a Linux machine and run uname -a. Save a screenshot and delete the cloud resources. Tutorials cover credentials, dependencies, and cleanup. The pool may retain paid capacity after requests end. Compliance with cleanup procedures is therefore required.
A demonstration involving Omarchy machines is also provided. A 50-second video shows two Driver sessions. It processes grid selection in LibreOffice Calc and object selection in Inkscape in parallel. In the foreground, a terminal remains in front. After watching the video, users can try Omarchy on Fleet.
Role of Driver in Native Operation
Driver is a tool for inspecting and operating machine apps and browsers. Supported OSes are macOS, Windows, and Linux. Connection methods are CLI, MCP, and typed SDKs. Installation is run via a distribution script. Shell scripts are provided for macOS and Linux, and a PowerShell script for Windows.
The first result is verification with a calculator. It asks an agent to calculate 6x7. It has the agent autonomously confirm that the display shows 42. Tutorials cover OS-specific setup, permissions, and connection procedures. Integration guides for Claude Code, Codex, Cursor, OpenClaw, and others are also provided. Detailed design documentation is located at libs/cua-driver/README.md.
The background delivery feature is also distinctive. When the app and infrastructure support it, it does not move the pointer. It proceeds with work in the background without stealing focus. Check the infrastructure support documentation for coverage boundaries. Avoiding foreground occupation has significant practical value. This aligns with the automation trend shown in AMD ROCm.AI Aims Beyond CUDA With AI Code Optimization.
Lume Features Leveraging Apple Virtualization
Lume handles creation and management of local virtual machines. It targets macOS and Linux on Apple Silicon. It uses Apple’s Virtualization.Framework. Installation is run via a distribution script.
The first result is a Tahoe virtual machine. It creates a clean virtual machine from Apple’s restore image. After booting, connect via SSH. Tutorials use the Lume CLI directly. Unattended-setup defaults are also explained.
Local virtualization is effective for ensuring reproducibility. Machine environments can be replicated without relying on cloud resources. It is also suitable for testing permissions and network configurations. As noted in AppleCare Plus Prices to Rise for Mac and iPad, which covers maintenance costs for Mac and iPad, operating costs for Apple hardware cannot be ignored. Balancing local and cloud resources is a key design consideration.
Aim of Bench for Performance Evaluation
Bench is an infrastructure for building computer-use tasks. It handles creation and verification of mock tasks. The public documentation is concise. Detailed specifications await future documentation releases.
Even so, its positioning is clear. Machine provisioning and operation drivers alone do not establish evaluation. Tasks that can be re-run under identical conditions are needed. Bench covers that layer.
Developing evaluation infrastructure is a condition for wider adoption. Without reproducible tasks, comparison is impossible. A yardstick for judging automation success is required. Bench is expected to become the foundation for development competition.
Technical Background of Computer-Use 2.0
The public documentation presents a concept called Computer-Use 2.0. It refers to moving between code, APIs, and graphical interfaces within the same task. Conventional automation often forced a choice between interfaces or APIs. The new concept assumes combined use of both.
This interplay complicates implementation. State acquisition spans both screens and structures. Operations are distributed across keyboard input, pointers, and command execution. Verification requires both displayed content and return values. The division of labor among Driver, Fleet, and Lume addresses this complexity.
Advances on the model side are also part of the background. Long-context processing and tool calling have reached practical levels. As shown in Anthropic Declares Fable 5 Is Back, interest in sustained execution is high. Preparing receivers on the computer side is the next focus. Cua aims to be that receiver.
Editorial Opinion
On short-term impact. Over the next three to six months, combinations of evaluation tasks and cloud machines are expected to be tested in development settings. Minimum tasks such as calculator verification and uname execution have low adoption barriers. The coverage of background delivery will determine practical fit, in our assessment. If supported apps increase, pilot cases will grow, in our view.
On the long-term view. In one to three years, combined use of code, APIs, and graphical interfaces is expected to become standard design. Balancing local virtual machines and isolated cloud machines will take hold as operational knowledge, in our assessment. The availability of evaluation infrastructure may become part of model-selection criteria. Cleanup and cost management for compute resources will also become operational requirements, in our view.
Questions from the editorial team. The first issue is the safety boundary. Are isolation and permission settings sufficient. The second issue is reproducibility. How far can tasks and environment pinning go. The third issue is cost burden. Who monitors residual cloud capacity. These questions remain unverified. Accumulated operational records will provide material for discussion, in our assessment.
References
- “trycua / cua”, by trycua — GitHub Trending, 2026-09-20 (ARR)
- Source URL: https://github.com/trycua/cua
Frequently Asked Questions
- What is Cua?
- It is infrastructure for letting AI agents use computers. It consists of four elements: isolated cloud machines, machine-operation drivers, local virtual-machine management, and evaluation-task construction. Users bring their own models and gain compute resources and automation tools.
- What is the difference between Cua Fleets and Cua Driver?
- Fleets provides isolated cloud machines at run.cua.ai. It performs command execution and screen capture via the Sandbox SDK. Driver is a tool for operating apps and browsers on macOS, Windows, and Linux. It connects via CLI, MCP, and typed SDKs.
- What are the requirements for using Lume?
- It targets macOS and Linux virtual machines on Apple Silicon. It uses Apple's Virtualization.Framework. Tutorials show the procedure for creating a Tahoe virtual machine from a restore image and connecting via SSH after boot.
Comments