Computer-Use Agents Got A Lighter Gym: Inside Berkeley’s CUA-Lite

Training a computer-use agent, one that clicks through a desktop, a browser or a phone, has carried a cost that rarely appears in papers: every task boots a virtual machine. The standard OSWorld benchmark runs its desktop inside QEMU with KVM, which means every rollout needs hardware virtualization, every fleet needs beefy hosts, and every research group without a cluster is priced out. Berkeley's CUA-Lite, released in September 2026 by the Berkeley RDI group, replaces that runtime with a Docker container and, in doing so, drops the memory footprint from roughly 4.1 GB to about 0.9 GB while keeping OSWorld's own tasks and evaluators unchanged.

That is the headline number, and unlike most headline numbers in agent infrastructure, it is verifiable by anyone who can run two containers and watch memory usage. The more consequential contribution is architectural: CUA-Lite standardises three interfaces that computer-use research has so far left scattered, environments, supervised data and model harnesses, so that any agent can plug into any environment, any dataset can train any agent, and evaluation, fine-tuning and reinforcement learning share one infrastructure. This article works from Berkeley's own release post, read in full, and covers what each abstraction does, what is actually integrated today, and where the lighter runtime does not replace the heavier one.

The fragmentation problem, stated plainly

Computer-use agents operate desktop, browser and mobile applications. Developing one requires environments with verifiable tasks, supervised data to learn from, and a harness, the code that runs a model inside an environment. Open-source work exists for all three, but each piece arrived separately: every environment has its own interface and runtime, every supervised dataset its own format, every model its own action space, prompt format and rollout code.

The cost is invisible until a team tries to scale, and then it shows up as months of duplicated engineering. Without a shared standard, connecting a new model to a new environment means writing the same three pieces again, an action mapping, a context window and a rollout loop. Resources cannot be pooled, results cannot be compared, and evaluation, supervised fine-tuning and reinforcement learning end up as three separate codebases that drift apart. Anyone who has ported an agent from one benchmark to another recognises the tax immediately.

CUA-Lite closes that gap with three abstractions and ships the integrations to make them worth using, which is the difference between a specification and a platform: Lite.Gym for environments, Lite.Sample for supervised data, and one harness per model shared across evaluation, supervised fine-tuning and reinforcement learning. The release reports 15 or more benchmarks, 10 or more datasets and 30,000 or more verifiable tasks already plugged in.

Lite.Gym: one interface, any environment

Within CUA-Lite, Lite.Gym wraps any environment behind a Gym-style loop: reset returns the first screenshot and the task, step takes actions and returns observations, rewards and termination flags, and close releases resources. Observations standardise to a screenshot, text or both per tool call. Actions standardise to one GUI action space per platform, issued as tool calls: click and type on desktop and browser, tap and swipe on mobile, plus per-environment extras such as bash in the desktop sandboxes.

In CUA-Lite the design choice that matters is wrapping rather than replacing. Lite.Gym sits in front of whatever runtime the environment already uses, a VM, a browser or a mobile emulator, so existing benchmarks keep their own machinery and their own evaluators. What changes is the surface a model sees, which is now identical everywhere.

The optional addition is the VM-free desktop sandbox: a Docker container replicating OSWorld's desktop at much lower cost, holding more than 30,000 verifiable training tasks. It needs no /dev/kvm, the hardware virtualization that VM-based benchmarks require, so it runs on any host with Docker, including a laptop. Lite.OSWorld runs OSWorld's own tasks and evaluators unchanged, which is what makes the comparison credible: the cheap runtime is validated against the expensive one rather than against itself.

Beyond OSWorld, the same base runs browser and desktop tasks and even real scientific desktops, including GMAT for orbital mechanics and PyMOL for protein visualisation, with 369 benchmark tasks plus more than 2,000 synthesised ones across ten desktop applications. That range is CUA-Lite's strategic claim: a lightweight container is not a benchmark shortcut but a substrate for a family of sandboxes, including domains where VM cost previously made training data impractical to generate.

Lite.Sample: convert once, train everywhere

The second CUA-Lite abstraction attacks data. Lite.Sample is one schema shared across every environment, agent and task type: metadata describing platform and task type, a list of screenshots, and messages whose tool calls are the interface's actions and whose tool results are its observations. A GUI grounding label and a full multi-step rollout end up in the same shape.

The schema alone would be trivia without adapters, and CUA-Lite ships an adapter per model family that packs a LiteSample into the exact training format the model needs. The release illustrates the payoff with prefix-extender architectures: six steps of a trajectory pack into two forward passes, because the adapter knows how to extend the last tape rather than re-rendering every step. That is the kind of efficiency that only appears when the harness and the data format are designed together.

More than ten datasets are already on Hugging Face, covering grounding, understanding and use corpora, preprocessed into Lite.Sample, plus fresh rollouts from frontier computer-use agents. The CUA-Lite release also issues an open call for data contributors, with the argument that data matters only while models can train on it, and that one conversion lets the whole community train on a contribution.

Harnesses: eval, SFT and RL on one spine

The third CUA-Lite abstraction is the model harness, one per model family, implemented for fourteen families. Through its harness a model runs in every integrated environment, evaluation and reinforcement learning consume the rollouts it produces, and the same adapter that renders data for supervised fine-tuning matches what the model saw live. That last alignment is a quiet but significant property: when the SFT prompt differs from the inference prompt, models learn a distribution they will never meet in production, and unifying the two paths eliminates an entire class of silent failure.

The practical CUA-Lite workflow is three commands. Rollout for evaluation, setting a model id and an environment id. Download a corpus and export a model-ready parquet for supervised fine-tuning. Then train with GRPO or another method on the Slime trainer. Reinforcement learning runs inside the same environments, which means the reward comes from the environment's own verifiers rather than from a proxy.

What the lighter runtime does not replace

The CUA-Lite release is unusually careful here, and the care is worth repeating because it is the difference between a useful tool and a misleading one. The VM-free sandboxes are an addition, not a replacement: the original OSWorld VM sits alongside Lite.OSWorld, and the mobile benchmarks still require a VM or an emulator. The 0.9 GB container buys cheap desktop training tasks, not universal coverage.

There is also a security consideration that a lighter runtime makes more acute rather than less. A container shares the host kernel, while a VM does not, so an agent that runs arbitrary code or reaches unexpected system state has a shorter path to the host in the container model. For training runs on trusted tasks with controlled network access, that trade is usually acceptable and standard container hardening applies. For evaluating untrusted agents on hostile inputs, the VM's isolation remains the stronger boundary, and teams should keep the VM path for that purpose. Berkeley's framing for CUA-Lite, addition not replacement, is consistent with that reading.

The third CUA-Lite limit is scope of validation. OSWorld parity is claimed and testable; the 2,000-plus synthesised tasks and the scientific sandboxes are newer and less independently exercised. Task suites belong to their originators, and CUA-Lite's contribution is the runtime, the interface and the integration, which means quality of results still depends on the underlying benchmarks.

What a training run actually looks like

For a team that wants to try CUA-Lite rather than read about it, the realistic first session is smaller than the release's scope suggests, and knowing that in advance saves a wasted day.

The starting point is a single benchmark on a single host. Install the package, pull a container, run the preflight environment check, then run one rollout against one task with a small model and watch what the harness renders. That first run answers the questions that matter for everything after: does the model's action space map cleanly onto the interface, does the observation format match what the model expects, and does the reward signal appear at the right moment. Failures here are configuration, not research, and they are cheap to fix when caught on one task instead of a thousand.

The second session is a data conversion. Download one of the preprocessed corpora, run the export to produce a model-ready parquet, and inspect what the adapter packed. The release's prefix-extender example is worth reproducing on your own model, because the number of forward passes per trajectory determines whether a fine-tune fits your budget. If six steps pack into two forwards instead of six, the training run is three times cheaper before a single hyperparameter is tuned.

The third session is the comparison that decides whether the platform earns a place in your workflow: run the same agent on the same task set under the container runtime and under the original VM runtime, and compare scores. If the numbers agree, the cheap runtime is validated for your workload and you can scale data generation on ordinary hardware. If they diverge, the divergence itself is the finding, and it is exactly the kind of thing CUA-Lite's dual-runtime design makes possible to check. That check is the practical expression of the release's central claim, and it costs an afternoon rather than a grant application.

Why this matters for the agent-training stack

The release lands in a year when agent training infrastructure has been consolidating on exactly this pattern: standardise the interface, keep the verifiers, and let training, evaluation and data share one spine. EnvHarness made the same move for environments, wrapping frozen benchmarks so training surfaces can be reshaped while the goal predicate stays untouched. CUA-Lite makes it for computer use, where the runtime cost was the binding constraint rather than the curriculum.

For teams building computer-use products, the immediate effect is that the price of a training corpus falls. Thirty thousand verifiable desktop tasks runnable on ordinary Docker hosts, in a schema that exports straight into a model's training format, changes the arithmetic from cluster-scale to workstation-scale for the experimentation phase. For the research community, the compound effect matters more: every new sandbox and every converted dataset makes every integrated agent better, which is the network effect the release's contributor calls are explicitly trying to start. The same economics show up in this site's coverage of harness costs and inference caching: the wins in agent infrastructure keep coming from removing repeated overhead, not from adding capability.

Where the numbers stop

• The memory figures, roughly 0.9 GB against 4.1 GB, describe container versus VM footprint as reported by the release. They do not capture host requirements for the GPU running the agent model itself, which will dominate real deployment cost.
• Task and dataset counts, 15 or more benchmarks, 10 or more datasets and 30,000 or more verifiable tasks, are the release's own inventory at publication and will change as contributors add more.
• The 369 benchmark tasks plus 2,000-plus synthesised tasks in the scientific sandbox family are described but not benchmarked in the release; no accuracy results for agents trained on them are published here.
• The claim that Lite.OSWorld uses OSWorld's own tasks and evaluators unchanged is testable and is the strongest part of the parity argument, but no independent comparison of agent scores between the VM and container runtimes appears in the release.
• The Slime trainer and GRPO path are named, not measured: no training curves or model checkpoints from CUA-Lite runs are reported.
• I have not run the platform. Every capability described is cited from Berkeley's release post.

FAQ

What is CUA-Lite?

It is an open platform from UC Berkeley's RDI group for developing computer-use agents, built on three standardised abstractions: Lite.Gym for environments, Lite.Sample for supervised data, and one model harness per model family shared across evaluation, supervised fine-tuning and reinforcement learning. It integrates 15 or more benchmarks, 10 or more datasets and 30,000 or more verifiable tasks, and provides optional VM-free Docker desktop sandboxes that replicate OSWorld's desktop at much lower memory cost while running OSWorld's own tasks and evaluators unchanged.

How much lighter is the VM-free sandbox?

The release reports a Docker container footprint of roughly 0.9 GB against around 4.1 GB for the VM-based OSWorld desktop, and the container needs no /dev/kvm hardware virtualization, so it runs on any host with Docker. That removes the cluster requirement for generating training data on desktop tasks. The trade is isolation: a container shares the host kernel, so the VM remains the stronger boundary for evaluating untrusted agents, which is why the release positions the sandbox as an addition rather than a replacement.

Why do three interfaces matter more than the memory savings?

Because fragmentation was the actual blocker. Environments, datasets and models each carried their own interface, format and action space, so connecting a new model to a new benchmark meant rewriting an action mapping, a context window and a rollout loop every time, and evaluation, fine-tuning and reinforcement learning lived in separate codebases. Standardising those three surfaces lets any agent run in any environment, any dataset train any agent, and one harness serve all three stages, which is what makes pooled compute and comparable results possible. The memory savings help, but they are the enabler rather than the contribution.

The short version

CUA-Lite replaces computer-use research's expensive default, a virtual machine per task, with a Docker container that is roughly four times lighter and needs no hardware virtualization, while keeping OSWorld's own tasks and evaluators intact. Around that runtime it standardises three interfaces, environments, supervised data and model harnesses, and ships 15 or more benchmarks, 10 or more datasets and 30,000 or more verifiable tasks already connected, with adapters for fourteen model families and a training path through GRPO on the Slime trainer. The release is honest about scope: the container is an addition beside the VM, mobile still needs an emulator, and container isolation is weaker than virtualisation. What it changes is the price of experimentation, from cluster-scale to workstation-scale, which is the constraint that has kept computer-use training out of most teams' reach.

Sources

• UC Berkeley RDI, Introducing CUA-Lite, an open platform for computer-use agents, covering Lite.Gym, Lite.Sample, the model harnesses, the VM-free sandboxes and the integration inventory: https://rdi.berkeley.edu/blog/cua-lite
• The CUA-Lite code repository and project site linked from the release, including the environment guide, leaderboard and contribution paths: https://github.com/uc-berkeley-nlp/cua-lite