Cua is an open-source stack for giving AI agents real computers to operate: a desktop automation driver, isolated cloud desktops, local macOS virtual machines, specialist decision models, and benchmarks for evaluating computer-use agents. It is aimed at developers who have moved past the chat window and want an agent that can open an application, click through it, and check what happened on screen — and at teams that need to do that on more than one machine at a time. The project is MIT-licensed, first appeared on GitHub in January 2025, and has gathered roughly 24,900 stars and 1,700 forks since.
What it does
The centerpiece is Cua Driver, the layer that lets an agent click, type, and verify real applications rather than describe them. It runs against macOS, Windows, and Linux desktops, so the same agent code can be pointed at whichever operating system the target software actually lives on.
The demo the channel filmed is deliberately small and makes the point well: the driver opens Calculator, computes six times seven, and then verifies that the screen really shows forty-two. That last step is the part worth noticing. Plenty of automation can send a click; what matters for an agent loop is being able to confirm the click had the intended effect instead of taking the model's word for it.
Around the driver, the repository bundles the rest of what a computer-use project ends up needing:
- Isolated cloud desktops, so an agent gets a disposable machine instead of yours.
- Local macOS virtual machines, for work that has to stay on Apple hardware.
- Specialist decision models for the agent side of the loop.
- Benchmarks for evaluating computer-use agents, plus support for training and data generation.
How it works
One driver interface sits over several very different sandboxing backends. The repository's own topics name Apple's Virtualization framework, Windows Sandbox, containerization, Swift, and the project's Lume component, which is a fair map of where the isolated desktops come from on each platform: native virtualization on macOS, the built-in sandbox on Windows, containers elsewhere.
The practical consequence is that the code you write against a single local desktop is the code that runs against a fleet. The script's claim is exactly this — the same driver scales to cloud desktop fleets — and it is the reason the project describes itself in terms of fleets rather than of one automated machine. Evaluation is wired into the same shape: if you can run one agent against one desktop, you can run many against many and score the results with the included benchmarks.
One detail to ignore: GitHub reports HTML as the main language. That statistic tends to reflect documentation and site files checked into the tree, not the automation code, so do not read it as a description of the project.
Getting started
The README opens with a path chooser rather than a single install command, because the entry point depends on what you want. The hosted route is Cua Fleets at run.cua.ai, which is the fastest way to see agent-driven desktops without setting up virtualization locally. The self-hosted route is the repository itself plus the documentation at cua.ai/docs. There is a Discord server for questions.
If you are evaluating rather than committing, reproduce the Calculator demo first. It exercises the whole chain — launch an app, act on it, read the screen back — in a few lines, and it tells you quickly whether the sandbox on your machine is set up correctly.
When to use it / when not
Reach for Cua when the thing your agent must operate only exists as a graphical application: legacy internal software, a vendor desktop client, a macOS-only tool, anything without an API you are allowed to call. It is also the right shape when you need many desktops at once — evaluation runs, data generation, parallel task execution — and when you want the agent's actions verified rather than assumed.
Skip it when the same job is reachable through an API, a CLI, or a database. Driving a GUI is slower and more brittle than calling the function underneath it, and no amount of good tooling changes that ordering. If your target is purely a website, a browser automation library is a lighter dependency than a virtualization stack. And this is a construction kit for people writing agents, not a finished product for an end user who wants their computer operated for them.
Alternatives
The obvious comparison is the hosted computer-use offerings from model vendors and agent startups — the repository's own topics nod at operator and manus. Those are rented and closed: you get a desktop, on someone else's terms, with their model in the loop. Cua's pitch is the inverse, an MIT-licensed stack you can run locally, including on your own macOS hardware, with your own choice of model. For web-only work, browser automation frameworks remain the simpler and better-understood option.
Take this repository seriously if you are building agents that have to act on real software and you have been improvising the desktop layer yourself — spawning VMs, wiring screenshots into a model, hoping the click landed. Cua replaces that improvisation with something with cross-platform drivers, fleets, and benchmarks attached, under a permissive license. If your agents live entirely inside APIs and browsers, it is a heavier answer than your question needs.