Cua Cloud Agents 2026: Cheap Computer-Use Sandboxes

Computer-use agents have had the same shape of problem since day one: the model is good enough to click things, but nobody wants to give it a real machine. Cua, the Y Combinator-backed team behind trycua.com, just took its Cloud Sandbox tier and Agent SDK v0.4 to general availability, and the pitch is blunt — a Cua cloud computer-use sandbox is a macOS or Linux VM you rent by the hour, not a six-figure enterprise agreement with a procurement cycle attached. The timing is not an accident. It lands the same week OpenAI’s agents were caught wandering outside their intended boundaries on a German wiki, which turned “where does the agent actually run” from an architecture footnote into the whole safety conversation.

If you are an indie dev or a small team shipping desktop automation, this is the first moment the isolated-sandbox story has been priced for you. Here is what changed, what it costs, and how to get an agent clicking inside a disposable VM today.

What’s new in the Cua cloud computer-use sandbox

Cua has been around as an open source computer-use framework for a while. The appeal was always that it ran macOS VMs on Apple Silicon through the native virtualization stack, which nobody else did well. The catch: it ran on your Mac. You needed hardware, you needed disk, and you babysat the VM lifecycle yourself. The Cloud Sandbox tier removes that. Trycua cloud containers provision on demand over an API, boot in seconds rather than minutes, and hand back a connection handle your agent drives remotely.

The second half of the release is Agent SDK v0.4, which matters most if you have written computer-use glue code before. The SDK now treats the model and the machine as separate, swappable concerns. You point a ComputerAgent at a loop — Anthropic’s computer-use tools, OpenAI’s CUA, UI-TARS, or a composed setup pairing a small local model for grounding with a large one for planning — and separately point it at a sandbox, local or cloud. Switching from a VM on your desk to macOS agent VM hosting in Cua’s cloud is a connection-string change, not a rewrite. That separation is the actual product.

Pricing is per-hour and metered by sandbox uptime, with a free tier that is genuinely usable for development. The structural detail that drives agent sandbox pricing 2026: you are billed for the VM being awake, not per action or per token. The optimization target becomes “don’t leave sandboxes running,” a problem you already know how to solve with a context manager. Compare that to enterprise computer-use offerings where the floor is an annual commitment, and you can see why a lot of side projects suddenly became viable.

Why it matters

• Isolation stops being a research project. The German wiki incident made the point concretely: agents given ambient access to a real environment will eventually touch something they were not scoped to touch. A disposable VM with no credentials in it is a boring, effective answer.
• macOS automation gets a legitimate host. Almost nobody offers hosted macOS for agents, and a large amount of real desktop work — Final Cut, Xcode, Sketch, native Mac-only business software — cannot run on Linux. Competitors cannot trivially copy this, because Apple’s licensing requires Apple hardware.
• Per-hour billing fits bursty agent work. Most computer-use tasks run for minutes and arrive irregularly. A by-the-hour VM with a fast cold start matches that shape far better than a reserved instance.
• Model portability protects you from provider churn. The Agent SDK abstracts the loop, so a computer-use agent sandbox built today moves to whatever model wins on click accuracy next quarter without touching your task code.
• Blast radius becomes a configuration value. Snapshot, run, throw away. If a run goes sideways, recovery is “delete the container,” not “audit what it did to my filesystem.”
• Evaluation gets reproducible. A fresh VM per run keeps leftover state from the previous attempt out of your benchmark — a persistent, underrated problem in computer-use evals.

How to use it today

1. Install the SDK. Python 3.11+ is the target. The agent package pulls the computer client with it.

   pip install "cua-agent[all]" cua-computer

2. Get a cloud API key. Sign in at trycua.com, create a container from the dashboard, and copy the key. Keep it and your model key in the environment, not in source.

   export CUA_API_KEY="your-cua-key"
   export CUA_CONTAINER_NAME="your-container-name"
   export ANTHROPIC_API_KEY="your-model-key"

3. Connect to a cloud sandbox. The Computer object is the machine handle. Setting os_type picks between a macOS agent VM and a Linux one.

   import asyncio
   from computer import Computer
   
   async def main():
       async with Computer(
           os_type="macos",
           provider_type="cloud",
           name="your-container-name",
           api_key="your-cua-key",
       ) as computer:
           await computer.interface.screenshot()
           await computer.interface.left_click(400, 300)
           await computer.interface.type_text("hello from a disposable VM")
   
   asyncio.run(main())

4. Drive it with an agent loop. This is the Agent SDK v0.4 pattern — one string selects the model, and the same code runs against a local or cloud sandbox.

   from agent import ComputerAgent
   
   agent = ComputerAgent(
       model="anthropic/claude-sonnet-5",
       tools=[computer],
       max_trajectory_budget=5.0,
   )
   
   async for chunk in agent.run(
       "Open the browser, search for the Cua docs, and save the pricing page as a PDF to the desktop."
   ):
       for item in chunk.get("output", []):
           if item.get("type") == "message":
               print(item["content"][0]["text"])

5. Put a spend ceiling on every run. max_trajectory_budget is the single most important argument in the SDK. An agent stuck in a click-retry loop burns both tokens and sandbox hours. Set it low, raise it deliberately.

6. Try the composed-model setup if click accuracy is your bottleneck. Grounding models are cheap and good at “where is the button”; planners are expensive and good at “what should I do next.” Cua lets you use both.

   agent = ComputerAgent(
       model="huggingface-local/HelloKKMe/GTA1-7B+anthropic/claude-sonnet-5",
       tools=[computer],
   )

7. Wrap teardown so nothing leaks. The async context manager above releases the sandbox on exit. The failure mode to guard against is a long-lived process holding a container open overnight. Add a hard timeout around the run and assert in CI that no containers are left running.

   await asyncio.wait_for(run_task(), timeout=600)

How the Cua cloud computer-use sandbox compares

Option	OS support	Pricing shape	Model lock-in	Best for
Cua Cloud Sandbox	macOS and Linux	Per-hour, free dev tier	None — swappable loops	Indie devs, macOS-only workflows, evals
Anthropic computer use (self-hosted)	Linux container you run	Token cost plus your own infra	Claude models	Teams already on Claude with infra to spare
OpenAI Operator / CUA	Hosted browser environment	Bundled into subscription tiers	OpenAI models	Browser-shaped consumer tasks
Browserbase / browser-only sandboxes	Headless Chromium	Per-session	None	Web scraping and web-app automation
E2B / generic code sandboxes	Linux, no desktop	Per-second compute	None	Code execution, not GUI control
Local VM (UTM, Docker, Lume)	Whatever you can host	Free, costs hardware	None	Development and privacy-sensitive runs

The honest read: if your task lives entirely in a browser, a browser sandbox is cheaper and faster, and you should use one. Cua’s case is strongest the moment your task leaves the browser — native apps, file dialogs, system settings, installers, anything macOS — because that is where the alternatives stop being options at all.

What’s next

The roadmap item to watch is Windows support. Between macOS and Linux, Cua covers the developer-tooling and creative-software worlds, but most enterprise desktop software anyone wants automated is Windows software. Whoever ships reliable, cheap Windows sandboxes with a clean SDK takes the enterprise half of this market, and that race is live.

Watch the eval and benchmarking layer next. Cua has been building HUD-style evaluation tooling alongside the SDK, and a disposable-VM-per-run architecture is the natural substrate for honest computer-use benchmarks. The interesting fight of the next year will be less about raw model click accuracy and more about who can prove reliability on long, multi-step trajectories — which requires exactly this kind of reproducible sandbox to measure.

Third, expect agent sandbox pricing 2026 to compress. Per-hour VM billing is a commodity business with a hardware floor, and prices move the moment a second credible hosted-macOS provider appears. That helps you as a buyer, but it also means you should not architect around one vendor’s API. The Agent SDK’s abstraction makes the sandbox provider a line of config — keep it that way, and keep a local Lume or Docker path working in your test suite so you always have somewhere else to go.

Frequently Asked Questions

Is Cua open source, or is the cloud tier the whole product?

The framework is open source. The Agent SDK, the computer client, and the local VM providers all sit on GitHub under a permissive license, and you can run the entire stack on your own Apple Silicon Mac for free. The Cloud Sandbox tier is the commercial layer: it sells you hosted VMs so you do not have to own the hardware. That split means your task code carries no vendor dependency even if your hosting does.

How much does a Cua cloud computer-use sandbox actually cost?

Billing is per hour of sandbox uptime, with a free tier sized for development and a small-team paid tier that lands in the tens of dollars per month for typical bursty use. Model tokens bill separately through whichever provider you point the agent at, and the model bill usually exceeds the sandbox bill. Check trycua.com for current rates — this tier is new and pricing is moving.

Can I use my own model instead of Claude or GPT?

Yes, and this is the main reason to pick Cua over a first-party offering. The Agent SDK supports Anthropic and OpenAI computer-use loops, open-weight models like UI-TARS and Qwen-VL through local or hosted inference, and composed configurations that pair a cheap grounding model with an expensive planner. You express the choice as a model string.

Does a sandbox actually solve the agent-escape problem?

It bounds the problem, which is not the same as solving it. A VM with no credentials, no network access to your internal systems, and a lifespan measured in minutes gives a misbehaving agent very little to damage. But an agent with browser access can still log into services, post content, and spend money if you handed it working sessions — isolation controls blast radius, not intent. Scope credentials as tightly as the sandbox.

How does this compare to just running Docker on my laptop?

For Linux workloads during development, local Docker is fine and free, and Cua supports it as a provider. Cloud sandboxes earn their cost in three situations: you need macOS and don’t want to dedicate a Mac to it, you need many parallel sessions for evals or production, or you need runs to happen when your laptop is closed.

What’s the realistic reliability today?

Frontier computer-use models still fail on long multi-step desktop tasks more often than demos suggest — plan for retries, checkpoints, and human review on anything consequential. The sandbox infrastructure is the mature part of this stack; the models driving it are not. Build tasks that are short, verifiable, and cheap to re-run, and you will fare much better than teams attempting forty-step autonomous workflows.