trycua/cua Gains 609 Stars a Day, Open Computer-Use Infra

Open-source repository trycua/cua is currently the single fastest-growing AI-agent project on GitHub Trending, having added 609 stars in one day to reach 25,712 stars total.

The project describes itself as an effort to "scale computer-use 2.0 with open-source drivers, cross-OS fleets, and benchmarks for training, evaluation, and data generation" — a description that places it in direct contrast with the closed, vendor-controlled computer-use APIs that frontier labs have shipped over the past year. Computer-use, in this context, refers to AI agents that operate a real computer's graphical interface directly, through mouse movement, keyboard input, and screen observation, rather than calling a purpose-built function API. trycua/cua positions itself as infrastructure for the next generation, "2.0," of that category, built in the open rather than behind a single company's SDK.

Why open drivers instead of closed vendor SDKs

A closed vendor SDK may be sufficient if computer-use is treated purely as an end-user automation feature. But for teams that need to embed this capability inside a training, evaluation, or data-generation pipeline, a closed interface is a black box: there is no visibility into how the underlying driver actually talks to the operating system, no ability to deploy it at scale on one's own terms, and no way to instrument failure modes or intervene at the driver level.

An open-source driver layer turns "how an AI actually controls a computer" into infrastructure that can be audited, modified, and replicated at scale, rather than a metered service whose boundaries are only visible through a bill and a rate limit. That is the practical case for the "open-source drivers" half of the project's pitch: it moves ownership of the capability from a single vendor to the developer community.

Cross-OS fleets as a scaling problem, not a feature checkbox

The "cross-OS fleets" framing matters for a related reason. Training or evaluating an agent that can reliably operate a computer typically requires running hundreds or thousands of controlled virtual-machine instances in parallel, across Windows, macOS, and Linux, to collect trajectories, verify task completion, and generate comparison data.

If each operating system needs its own bespoke orchestration logic, that scaling process becomes unmanageable quickly. Building a unified orchestration layer across operating systems means a team can schedule, monitor, and recycle agent sessions across thousands of machines with one consistent toolset — effectively turning the "how do we scale agent training" question from an algorithmic problem into a systems-engineering one that dedicated infrastructure can absorb.

Benchmarks bundled with data generation is a pipeline signal

It is worth noting that trycua/cua pairs "benchmarks" with "data generation" in the same sentence describing its purpose, and that pairing is not incidental. A tool aimed purely at end-user automation would not need standardized benchmarks or a dedicated data-generation pipeline.

But a project aimed at feeding the next generation of models needs both: reproducible benchmarks to measure whether an agent has actually learned a given operating skill, and a controlled data-generation pipeline to keep supplying the high-quality trajectories that training requires. That combination signals the project is aimed squarely at the model-training pipeline for computer-use agents, not just at helping individual users automate a few clicks.

What the growth rate signals

Adding 609 stars in a single day, enough to make it the fastest-growing AI-agent repository on GitHub Trending that day, is a strong signal about current developer appetite. It suggests real, active demand for an open alternative to closed, vendor-controlled computer-use capability, from developers who are not satisfied simply consuming this functionality through a proprietary API.

As more teams look to train or fine-tune their own computer-use models, projects like trycua/cua that bundle drivers, fleet orchestration, and benchmarks into a single stack are well positioned to become a default piece of infrastructure for this category. What to watch next is whether the growth rate holds, and which operating-system adapters and benchmark tasks the community contributes around its driver layer.