Capability notes
Computer-use agents in 2026 control a desktop OS (mouse, keyboard, screen) via pixel-level vision-language models — the agent sees the screen and generates mouse clicks, keyboard input, and window management actions. Claude Computer Use (Anthropic API) defines the benchmark: a VLM receives screenshots at each step, outputs mouse coordinates and keyboard events, and iterates. Open-weight equivalents use [Llama 3.3 70B](/models/llama-3-3-70b) or [Qwen 3 32B](/models/qwen-3-32b) with vision encoders, achieving 45-60% task completion vs Claude's 70-80% on desktop tasks.
The modality is fundamentally different from web agents — the agent sees the entire desktop (multiple windows, overlapping UIs, notification popups, OS chrome) rather than a single browser viewport. This expands capability to: file operations (open Finder/Explorer, organize files), multi-application workflows (copy data from Excel to an email), system settings (change display resolution, configure WiFi), and legacy app interaction (interact with a Windows 95-era enterprise application that exposes no API).
Spatial reasoning is the binding constraint. The model must map a task instruction ("click the Save button in the top-left toolbar") to exact pixel coordinates on a variable-resolution screen. Success depends on: (1) screen resolution — 4K (3840×2160) requires 4× the grounding precision of 1080p; (2) UI density — macOS menu bar at 72px vs Windows taskbar at 48px; (3) visual clutter — overlapping windows, dark mode, high-contrast accessibility settings.
Claude Computer Use achieves 70-80% task completion by using a specialized vision-action model trained on desktop screenshots. Open-weight VLMs, trained on natural images (COCO, ImageNet), achieve significantly lower desktop-grounding accuracy because they lack exposure to OS UI element layouts. Fine-tuning VLMs on desktop interaction datasets (OSWorld, OmniACT) closes the gap 10-15 percentage points.
If you just want to try this
Lowest-friction path to a working setup.
Computer-use agents require a desktop environment (real or virtual) + a VLM with vision capability. The simplest path: run a VM with a lightweight Linux desktop, connect a VLM via [Ollama](/tools/ollama), and use open-source orchestration frameworks.
OSWorld provides a benchmark + execution environment for desktop agents. Install in a Linux VM, connect to [Llama 3.3 70B](/models/llama-3-3-70b) vision via Ollama:
```bash
ollama pull llama3.3:70b
# In a Ubuntu 22.04 VM with GNOME desktop:
git clone https://github.com/xlang-ai/OSWorld
cd OSWorld
python run_agent.py --model ollama/llama3.3:70b --task "open Firefox, navigate to gmail.com"
```
For ad-hoc desktop tasks, a simpler approach: screenshot your desktop → send to VLM with instructions → VLM returns action → execute via Python automation (pyautogui for mouse/keyboard). This manual loop runs at 5-10 seconds per step — functional for one-off tasks, not for continuous automation.
Expect failure. Desktop AI is 2-3 years behind browser AI in reliability. Tasks that you'd expect to be simple ("close all Finder windows and open the Downloads folder") fail ~40% of the time on open-weight VLMs. Start with the narrowest possible tasks: single application, single window, 1-3 steps. Multi-application workflows ("extract data from this PDF, paste into Excel, create a chart") fail ~70% of the time.
Hardware: [RTX 4090](/hardware/rtx-4090) 24GB + sufficient system RAM for a desktop VM (8 GB). Vision-capable 70B at Q4 fits 24GB at reduced screenshot resolution. [MacBook Pro 16" M4 Max](/hardware/macbook-pro-16-m4-max) 64GB handles 70B vision + macOS automation natively via AppleScript/Shortcuts — no VM needed.
For production deployment
Operator-grade recommendation.
Production computer-use agents require a sandboxed desktop environment, action validation layer, and task decomposition engine.
**Sandbox architecture.** Each agent instance runs in an isolated VM or container with a virtual display (Xvfb, Wayland headless). The VM provides: full GNOME/KDE desktop, applications (browser, office suite, file manager), user home directory, and network access (policy-controlled). Docker containers with xvfb + lightweight window manager (Fluxbox) work for Linux-targeted tasks; full VMs (QEMU/VirtualBox) needed for Windows/macOS targets. One GPU serves VLM inference for 10-50 VM instances.
**Action validation.** The VLM outputs an action: {`type`: "click"|"type"|"key_combo"|"scroll"|"drag"|"wait"|"screenshot"|"done", `params`: {...}}. Before execution: (1) Validate coordinates within screen bounds. (2) Validate keyboard input — block dangerous key combos (Ctrl+Alt+Del, Super+L, rm -rf in terminal). (3) Check action against a blocklist (open terminal, modify system settings, access /etc, install software). (4) Rate-limit: max 1 action per 500ms (prevents runaway agents). Invalid actions → re-query VLM with correction. 3 consecutive invalid → terminate agent session.
**Task decomposition.** Complex tasks ("organize my Downloads folder, create expense report from receipts, email it to accounting") must be decomposed into subtasks by a planner model ([DeepSeek V4](/models/deepseek-v4) or [Llama 3.3 70B](/models/llama-3-3-70b)) before an executor model ([Qwen 3 32B](/models/qwen-3-32b) vision) executes each subtask. Decomposition reduces error compounding — each subtask has its own error boundary. If a subtask fails, the planner re-plans from the current state rather than restarting the entire task.
**Action-granularity tradeoff.** High-level actions ("fill the login form") require the VLM to generate multiple low-level actions (click username field, type username, click password field, type password, click login). Each low-level action is a failure point. Alternative: use accessibility APIs (AT-SPI on Linux, UI Automation on Windows, Accessibility on macOS) to expose high-level actions ("set value of textfield 'username' to X") — eliminates coordinate grounding errors but requires the target application to expose accessibility tree. Hybrid approach: try accessibility API first; fall back to pixel-level VLM if accessibility tree is unavailable.
**Monitoring.** Track per-task: steps taken, task completion rate, failure reason classification (wrong coordinates, wrong action type, application not found, unexpected UI state, agent timeout). Pattern: tasks fail primarily due to unexpected UI states (popup appeared, application updated, dark mode changed) rather than VLM grounding errors — the desktop environment is adversarial.
What breaks
Failure modes operators see in the wild.
- **Output quality degradation under load.** Symptom: response quality drops under high concurrency — outputs become shorter and less detailed. Cause: [vLLM](/tools/vllm) under GPU memory pressure reduces effective context or switches generation parameters. Mitigation: monitor per-request quality scores, set max concurrency based on memory headroom, scale horizontally when metrics degrade.
- **Confidence hallucination.** Symptom: outputs are confident and well-structured but factually wrong. Cause: LLMs generate by probability not factual verification. Confident-sounding outputs are harder to detect as errors. Mitigation: implement deterministic validation on outputs (numeric bounds, schema checks). Flag for human review when validation fails. Never trust LLM self-reported confidence.
- **Edge case collapse.** Symptom: model performs well on common Computer Use Agents tasks (90%+) but fails catastrophically on rare edge cases. Cause: training distribution under-represents edge cases; model defaults to nearest common pattern. Mitigation: build regression test suite of edge cases, run before every model update, track edge case pass rate separately from general accuracy.
- **Context pollution in long sessions.** Symptom: after 20-30 exchanges the model mixes information from earlier conversation parts, producing contradictions. Cause: long contexts dilute attention — relevant context competes with noise. Mitigation: periodically summarize and reset context every 15-20 exchanges, store key findings externally, trigger summarization at 80% context window capacity. For models see [Llama 3.3 70B](/models/llama-3-3-70b).
Hardware guidance
**Hobbyist ($1,500-$3,000 total).** Computer-use agents require: GPU for VLM inference + machine for the desktop environment. [RTX 4090](/hardware/rtx-4090) 24GB for VLM + a separate machine (or dual-boot) for the desktop VM. VLM: [Llama 3.3 70B](/models/llama-3-3-70b) vision Q4 at 1920×1080 screenshots — 3-8 seconds per step. [RTX 5090](/hardware/rtx-5090) 32GB runs 70B fully in VRAM at 4-10 fps (steps per second) with full-resolution screenshots. [MacBook Pro 16" M4 Max](/hardware/macbook-pro-16-m4-max) 64GB is uniquely suited: unified memory handles 70B vision + macOS desktop simultaneously — no VM overhead, native AppleScript automation, single machine.
**SMB ($6,000-$15,000).** [NVIDIA L40S](/hardware/nvidia-l40s) 48GB runs [Llama 3.3 70B](/models/llama-3-3-70b) FP8 at 80-100 tok/s with 1080p screenshots. Serves 10-30 concurrent desktop VM instances. Pair with 3-5 Intel NUCs or similar mini-PCs running Linux VMs as desktop hosts. Each NUC runs 5-10 isolated desktop environments (KVM VMs with xvfb).
**Enterprise ($25,000+).** [NVIDIA H100 PCIe](/hardware/nvidia-h100-pcie) 80GB runs [DeepSeek V4](/models/deepseek-v4) vision at 140-170 tok/s — 5-10 steps per second, approaching real-time desktop interaction. Serves 50-100 concurrent desktop VMs. Desktop VM fleet: Kubernetes cluster with VM-isolated pods, each running Xvfb + Fluxbox + target applications.
**Cost per task.** A 20-step desktop task using [Llama 3.3 70B](/models/llama-3-3-70b) vision: 20 screenshots × 800 tokens each + 20 prompts × 300 tokens each + 20 responses × 200 tokens each = ~26K tokens. At local inference on [NVIDIA L40S](/hardware/nvidia-l40s) (~$2/hr): ~$0.003 per task. At API rates (Claude Computer Use): $0.05-0.15 per task. For 10,000 tasks/month: $30 on local vs $500-1,500 on API.
Desktop VMs are the dominant infrastructure cost, not GPU. A KVM VM with desktop + applications needs 2-4 GB RAM and 1-2 vCPUs. At $0.01-0.03/hr per VM, running 50 VMs 24/7 costs $360-1,080/month. GPU inference adds $50-200/month. Total for 10,000 tasks/month: $400-1,300/month — the VMs cost 5-10× more than the GPU.
Runtime guidance
**If using Claude Computer Use** → Anthropic API with the computer-use beta. Highest reliability (70-80% task completion), but code (screenshots) goes to Anthropic. Setup: create API key, use Anthropic's reference implementation (Python Docker container). The reference agent runs in Docker with xvfb + Fluxbox, sends screenshots to Claude API, and executes returned actions. Use for prototyping to establish baseline — then decide whether to migrate to local models.
**If using open-weight VLMs for desktop automation** → [Ollama](/tools/ollama) with [Llama 3.3 70B](/models/llama-3-3-70b) vision + custom action loop. Open-source frameworks (OS-Copilot, UFO, CogAgent) provide the agentic loop, action parsing, and VM integration. These frameworks are research-grade — expect to debug and modify them.
**If automating macOS natively** → [MLX LM](/tools/mlx-lm) with vision model + AppleScript/JXA (JavaScript for Automation). AppleScript provides high-level actions ("click menu item 'Save' of menu 'File'") without coordinate grounding, eliminating the primary failure mode. Combine: VLM for visual understanding (what's on screen?) + AppleScript for action execution (click this named element). This hybrid approach achieves 20-30% higher reliability than coordinate-based clicking on macOS.
**If automating Windows** → Windows UI Automation (UIA) API + VLM via [Ollama](/tools/ollama) or [LM Studio](/tools/lm-studio) on Windows. UIA provides element-level access (name, type, position, value) for most Win32 and UWP applications. The VLM maps task intent to UIA elements; UIA executes the action. Coordinate-based clicking is the fallback for applications without UIA support (Electron apps, older Win32, custom rendering).
**If automating Linux** → AT-SPI (Assistive Technology Service Provider Interface) + VLM. AT-SPI exposes UI element tree for GTK/Qt applications — same hybrid high-level approach. Xdotool for coordinate-based fallback. The combination covers ~80% of Linux desktop applications.
**If running agents in a server environment (no physical display)** → Docker with xvfb-run + Fluxbox. No GPU needed on the VM host for display (xvfb is software-rendered). VLM inference GPU is separate. This is the standard architecture for scaled desktop agent fleets.