Agents
desktop agents
os agents
computer use ai

Computer-Use Agents

Agents that operate desktop applications via screenshot + mouse/keyboard. Anthropic Computer Use API, OS-Atlas, ShowUI.

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.

Setup walkthrough

  1. Install Ollama → ollama pull qwen2.5-vl:7b (~5 GB — vision required for seeing desktop screenshots).
  2. pip install pyautogui pillow (screenshot capture + mouse/keyboard control).
  3. Basic computer-use agent loop:
import ollama, pyautogui, time
def computer_use_agent(task):
    for step in range(10):
        screenshot = pyautogui.screenshot()
        ss_bytes = screenshot.tobytes()
        resp = ollama.chat(model="qwen2.5-vl:7b", messages=[{
            "role": "user",
            "content": f"Task: {task}\nDescribe what you see and what action to take next. Format: ACTION: click(x,y) or ACTION: type('text') or ACTION: done",
            "images": [ss_bytes]
        }])
        action = resp["message"]["content"]
        # Parse action and execute via pyautogui
        print(f"Step {step}: {action}")
        if "done" in action: break
        time.sleep(2)

computer_use_agent("Open Notepad, type 'Hello World', save to Desktop as hello.txt")
  1. First agent loop in 30-90 seconds for a 3-5 step task on 12 GB GPU. The VLM analyzes each screenshot, decides the next action.
  2. For production: use OS-Copilot or UFO (Microsoft's Windows agent framework) which add accessibility-tree reading + grounding for higher reliability than screenshot-only.
  3. Reality: computer-use agents are early-2026 research-grade. They succeed on simple tasks ~70% of the time and fail on complex UIs (modal dialogs, drag-and-drop, multi-monitor).

The cheap setup

Used RTX 3060 12 GB (~$200-250, see /hardware/rtx-3060-12gb). Runs Qwen2-VL 7B at 5-10 seconds per screenshot analysis — a 5-step task completes in 1-2 minutes. For automating repetitive desktop tasks (file organization, data entry, screenshot annotation): $400 is viable for tasks you'd otherwise spend 30+ minutes on. Pair with Ryzen 5 5600 + 16 GB DDR4 + 512 GB NVMe. Total: ~$360-405. Computer-use agents at $400 work for simple, well-defined, repeatable tasks. They fail at novel tasks and complex multi-app workflows.

The serious setup

Used RTX 3090 24 GB (~$700-900, see /hardware/rtx-3090). Runs Qwen2-VL 72B at 10-20 seconds per screenshot — the 72B offers dramatically better UI understanding, element grounding, and error recovery. For RPA (robotic process automation) replacement with AI agents: the 72B correctly navigates enterprise apps (SAP, Salesforce, Oracle) that confuse 7B models. Total: ~$1,800-2,200. Computer-use agents are one of the few tasks where the jump from 7B to 72B is transformative — the larger model correctly reads error dialogs, dropdown menus, and nested tabs that the 7B misidentifies.

Common beginner mistake

The mistake: Running a computer-use agent on your main desktop while you're also using it — the agent randomly clicks on your browser, closes your tabs, moves your files. Why it fails: The agent sees screenshots of the entire screen. It doesn't know which windows are "yours" vs. "its workspace." If you open Slack while the agent is running, the agent might click on a message, type garbage, or send a message. The fix: Run the agent in a VM or a dedicated workspace. Windows Sandbox (built into Windows Pro) or a VirtualBox VM provides an isolated desktop. The agent can do whatever it wants in the VM — it can't touch your real files. For tasks that need your real desktop, quit all other apps before running the agent. Or: use a dedicated computer (old laptop) as the agent's workspace. The agent has the impulse control of a toddler — don't give it access to anything you care about.

Recommended setup for computer-use agents

Recommended runtimes

Browse all tools for runtimes that fit this workload.

Reality check

Local AI workloads have real hardware constraints that vary by task type. VRAM ceiling decides what model fits; bandwidth decides decode speed; compute decides prefill speed. Pick the GPU tier that fits your actual workload, not the spec sheet.

Common mistakes

  • Buying for spec-sheet VRAM without modeling KV cache + activation overhead
  • Underestimating quantization quality loss below Q4
  • Skipping flash-attention support (real perf gap on long context)
  • Ignoring sustained-load thermals (laptops thermal-throttle within 30 min)

What breaks first

The errors most operators hit when running computer-use agents locally. Each links to a diagnose+fix walkthrough.

Before you buy

Verify your specific hardware can handle computer-use agents before committing money.

Hardware buying guidance for Computer-Use Agents

Agent workflows run multiple tool calls in sequence — sustained tok/s matters more than peak. The guides below frame the buyer decision.

Specialized buyer guides
Updated 2026 roundup