Most "computer-use" demos in 2026 share a dirty secret: the agent is not actually using a computer. It is typing into a single browser tab, fighting for the cursor, and collapsing the moment a popup steals focus. A project called Cua (trycua/cua) just crossed 20,214 GitHub stars and pulled 1,341 forks by attacking that exact gap. It gives an AI agent a real, isolated machine to drive, and it does it with open-source drivers that run in the background.

The repo is not a toy. It is a stack of four interlocking pieces: agent-ready sandboxes, background drivers, a benchmark suite, and a macOS virtualizer. Together they answer a question every founder building an AI operator has hit: how do I let a model click, type, and verify inside real desktop apps without wrecking my own machine or the user's?

What Cua Actually Ships

The core package is Cua, an SDK that spins up "agent-ready sandboxes" for any operating system through one API. You ask for a Linux container, a Linux VM, macOS, Windows, or Android, and the same Sandbox.ephemeral() call hands your agent a screen to see, a mouse to click, and a keyboard to type. The code reads almost like a normal script:

async with Sandbox.ephemeral(Image.linux()) as sb:
    result = await sb.shell.run("echo hello")
    screenshot = await sb.screenshot()
    await sb.mouse.click(100, 200)

The second piece is the part that separates Cua from most competitors. Cua Drivers let an agent drive native desktop apps in the background. On macOS and Windows it clicks and types without stealing the cursor or focus. That sounds minor until you try to run an agent on a laptop you also need for meetings. The driver installs with a one-line script and exposes both a CLI and an MCP server, so it drops into Claude Code, Cursor, Codex, or a custom client without rewrites.

Then there is Cua-Bench, which runs agents against OSWorld, ScreenSpot, and Windows Arena tasks and exports the trajectories for training or fine-tuning. And Lume, a near-native macOS virtualizer built on Apple's own Virtualization.Framework, so you can stand up a Tahoe or Sequoia VM on Apple Silicon with a couple of commands. The whole thing is MIT licensed, with optional AGPL components clearly flagged.

Why Background Computer-Use Is the Real Unlock

The headline number is 20K stars, but the architectural bet is more interesting. The first wave of computer-use tools, the ones behind viral Manus-style clips, treated the agent as a guest on a shared screen. That design breaks the instant a notification lands or the human touches the trackpad. Cua flips the model: the agent gets its own machine, or it works behind the scenes on yours.

This matters because reliability, not capability, is the wall stopping computer-use from shipping. Models can already read a screenshot and decide where to click. What they cannot do is survive a real desktop's chaos: modal dialogs, OS updates, focus theft, and apps that hang. Background drivers and disposable sandboxes turn "the agent crashed my laptop" into "the agent's sandbox got reset and retried." That is the difference between a demo and a product.

The cross-OS coverage is the other quietly important part. Most open computer-use work is Linux-only because that is where the cloud lives. Cua's matrix includes macOS and Windows locally via QEMU and in the cloud via cua.ai, plus Android. For any founder automating white-collar desktop work, Windows and macOS are the actual battlefield. A benchmark that only runs on Linux tells you little about production.

How It Compares to the Alternatives

Cua is not alone. OpenAI's Operator and Anthropic's Claude computer-use target the same outcome, but they are closed and wired to specific models. Microsoft's OmniParser is an open perception layer Cua actually depends on for some paths. The gap Cua fills is the infrastructure between "the model sees a screen" and "the agent finished the task on a real OS."

The trade-off is operational complexity. Running a macOS VM through Lume needs Apple Silicon and a restore image download. Cloud sandboxes cost money per hour. This is not a copy-paste npm package you drop in and forget. It is closer to standing up a small fleet, which is exactly why the project ships fleet management and benchmarks rather than just a single driver. They are building for teams running many agents, not one curious script.

Layer Cua's Offering Closed Alternatives
Sandbox / VM Open, cross-OS (Linux, macOS, Windows, Android), local or cloud Tied to one vendor's runtime
Driver Background, cursor-safe, MCP + CLI Usually foreground, focus-stealing
Benchmark Cua-Bench with trajectory export for training Rarely open or exportable
License MIT core Proprietary

The key takeaway: if you need a model-agnostic, own-your-stack foundation for computer-use, Cua is the most complete open option today. If you want a managed black box and never want to think about VMs, a closed operator product will feel simpler until you hit its walls.

What This Means

For builders, Cua lowers the cost of experimenting with autonomous desktop agents from "stand up a lab" to "pip install cua." That democratization is the real story behind the star count. We are about to see a wave of small startups shipping computer-use features because the plumbing is finally free and open. The 20K stars are a leading indicator of demand, not just hype.

For incumbents, the pressure is on the closed operators. When the open stack gives you background drivers, cross-OS sandboxes, and a training-ready benchmark under MIT, the justification for a proprietary wall shrinks. The defensible value moves up the stack to data, reliability, and managed fleets, not to the driver itself.

The near-term risk is the same one that hits every infra project: the hard part is not spawning the VM, it is making 1,000 agents run all day without silent failures. Cua has the bones, but fleets at scale will expose gaps in recovery, observability, and cost control. Whoever closes those gaps on top of this open base will own the computer-use layer the way Vercel owned the deploy layer. The land grab is open right now.