Agents
web agents
browser automation ai

Browser Agents

AI agents that navigate and interact with web browsers. Browser-use, Playwright-based agents, BrowserBase pattern.

Capability notes

Browser automation agents in 2026 use vision-language models (VLMs) to navigate websites, fill forms, extract data, and execute multi-step web tasks — without DOM access or pre-written selectors. The agent sees pixels (screenshot) and generates actions (click coordinates, type text, scroll). This approach works on any website, including SPAs with Shadow DOM, canvas-rendered UIs, and sites that block Selenium. WebVoyager and WebArena benchmarks: GPT-4V/Vision achieves 65-75% task completion on real-world web tasks (book a flight, find a product, fill a multi-page form). Open-weight VLMs trail: [Qwen 3 32B](/models/qwen-3-32b) with vision achieves 45-55%, [Llama 3.3 70B](/models/llama-3-3-70b) multimodal variants ~55-65%. The gap comes from visual grounding accuracy — the model must map a textual intent ("click the checkout button") to exact pixel coordinates on a 1920×1080 screenshot. Off by 20 pixels, and it clicks the wrong element. Playwright provides the execution layer: the agent issues Playwright commands (page.click, page.fill, page.screenshot) based on VLM reasoning. The VLM receives: user task, current screenshot, page URL, and action history. It returns: next action + reasoning. This loop continues until task completion, failure, or timeout (typically 15-30 steps). [DeepSeek V4](/models/deepseek-v4) multimodal leads open-weight browser agent performance when paired with a dedicated vision encoder. [Aya Expanse 32B](/models/aya-expanse-32b) provides multilingual browser interaction — navigating non-English websites (Japanese e-commerce, German government forms) where English-centric models fail on UI text comprehension. Critical operational constraint: each step costs 500-2000 tokens (screenshot encoding + prompt + response). At 20 steps per task, that's 10K-40K tokens per web task. With API models at $5-15/M tokens, each web task costs $0.05-0.60. Local inference eliminates per-task cost but requires GPU capacity.

If you just want to try this

Lowest-friction path to a working setup.

Start with [Cline](/tools/cline) running a browser agent via its built-in Puppeteer integration. Install [Ollama](/tools/ollama) with a vision-capable model: ```bash ollama pull llama3.3:70b ``` In Cline, prompt: "Go to [https://example.com/products], find the top 3 products under $50, and extract their names and prices into a CSV." Cline opens a headful browser, navigates, takes screenshots, and extracts data. Task completion takes 30-120 seconds depending on page complexity. For simpler browser automation, use Playwright directly with an AI step function in Python: ```python from playwright.sync_api import sync_playwright import ollama def ai_action(page, task, screenshot_path): page.screenshot(path=screenshot_path) # Encode screenshot as base64, send to Ollama vision model response = ollama.chat(model='llama3.3:70b', messages=[{ 'role': 'user', 'content': task, 'images': [screenshot_path] }]) # Parse action from response, execute via Playwright return response ``` Start with narrow, deterministic tasks: "go to url, search for X, extract the first result." Success rate on narrow scope is 80-90%. Multi-step open-ended tasks ("find the best deal on a laptop with these specs") drop to 50-70% because the agent gets lost in navigation branches. Hardware: any GPU with 24+ GB VRAM ([RTX 4090](/hardware/rtx-4090), [RTX 3090](/hardware/rtx-3090)) for vision-capable 70B. Vision context adds 2-8 GB overhead per screenshot. On [MacBook Pro 16" M4 Max](/hardware/macbook-pro-16-m4-max) 64GB, 70B vision runs on SoC via [MLX LM](/tools/mlx-lm) at 3-5 seconds per step. Don't start with a 7B vision model — their visual grounding accuracy drops below 35%, making them unusable for reliable browser automation.

For production deployment

Operator-grade recommendation.

Production browser agents run as a headless Playwright pool with VLM backend and structured action validation. **Agent architecture.** Orchestrator receives task → decomposes into subtasks → dispatches to Playwright worker → worker runs agentic loop: (1) take screenshot, (2) send to VLM with task + action history, (3) receive action dict {`type`: "click"|"type"|"scroll"|"navigate"|"extract"|"done", `args`: {...}}, (4) validate action (coordinate in bounds, selector exists, URL is expected domain), (5) execute via Playwright, (6) capture result, (7) repeat or terminate. **Action validation is critical.** The VLM may hallucinate coordinates outside the viewport (click at (2500, 800) on a 1920×1080 viewport) or generate CSS selectors that don't exist. Validate: coordinate bounds, URL domain allowlist, CSS selector existence (query page before clicking). Invalid actions: re-query VLM with error context ("coordinate (2500, 800) is outside viewport bounds 1920×1080. Choose coordinates within bounds."). Over 2 consecutive invalid actions: escalate to human. **Model routing.** Simple tasks (single-page extraction, known-site form filling): [Qwen 3 32B](/models/qwen-3-32b) vision at 2-5 seconds per step. Complex tasks (multi-page workflows, dynamic SPAs, visual reasoning): [Llama 3.3 70B](/models/llama-3-3-70b) vision at 5-10 seconds per step. Frontier tasks (CAPTCHA-like visual puzzles, densely packed UIs): [DeepSeek V4](/models/deepseek-v4) multimodal at 10-20 seconds per step. Route by task description complexity and target site predictability. **Concurrency model.** Browser automation is I/O-bound (waiting for page loads, animations, network), not compute-bound. One GPU serving VLMs can drive 10-30 concurrent Playwright workers because VLM inference is the bottleneck, not browser interaction. Pool architecture: 1 [NVIDIA L40S](/hardware/nvidia-l40s) + 20-30 Playwright workers (each in isolated Chromium context). Workers queue for VLM inference; GPU continuous-batches inference requests from the queue. **Failure recovery.** Agent tracks task progress as a state machine. If a step fails (navigation timeout, selector not found, VLM hallucination): retry with alternative approach (scroll and re-screenshot if element not visible, navigate directly to URL if link click fails). After 3 retries on a step, re-plan the subtask. After 2 re-plans, fail the task and log for human review.

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 Browser 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-$2,500 GPU).** [RTX 4090](/hardware/rtx-4090) 24GB is the minimum for vision-capable 70B models — each screenshot adds 2-8 GB context overhead. At Q4, [Llama 3.3 70B](/models/llama-3-3-70b) vision fits in 24GB with small screenshots (640×480). 1920×1080 screenshots may OOM — downscale before sending. [RTX 5090](/hardware/rtx-5090) 32GB handles full-resolution screenshots at Q4 with headroom. [MacBook Pro 16" M4 Max](/hardware/macbook-pro-16-m4-max) 64GB runs 70B vision on SoC at 25-35 tok/s — the most practical single-user browser agent machine due to large unified memory. **SMB ($6,000-$15,000).** [NVIDIA L40S](/hardware/nvidia-l40s) 48GB runs [Llama 3.3 70B](/models/llama-3-3-70b) vision at FP8 with high-res screenshots and 16K context — 10-20 concurrent browser workers at 5-10 seconds per step. [RTX 6000 Ada](/hardware/rtx-6000-ada) 48GB is the workstation equivalent. 48GB is the sweet spot for concurrent browser agent serving. **Enterprise ($25,000+).** [NVIDIA H100 PCIe](/hardware/nvidia-h100-pcie) 80GB runs [DeepSeek V4](/models/deepseek-v4) multimodal at FP8 — 20-40 concurrent browser workers at 10-20 seconds per step. 80GB handles full-page screenshots at native resolution with 32K+ context for long action histories. [NVIDIA H200](/hardware/nvidia-h200) 141GB handles DeepSeek V4 with 128K context — supports 100+ step browser sessions without context truncation. **Distributed browser pool.** Browser workers are CPU/RAM-intensive (1-2 GB RAM per Chromium instance), not GPU-intensive. Run Playwright workers on cheap CPU nodes (ARM64, low-cost VMs) and centralize VLM inference on GPU node(s). Typical ratio: one [NVIDIA L40S](/hardware/nvidia-l40s) serves 20-30 browser nodes. The GPU becomes a VLM API that browser nodes call synchronously. Vision context overhead is the main cost driver. A 1920×1080 screenshot encoded as tokens consumes 500-1500 tokens. At 20 steps per task: 10K-30K tokens in screenshot encoding alone. This dominates the token budget — prompt text is negligible by comparison. Optimize: downscale screenshots to 1024×768 unless detail is required, crop to region of interest, reuse screenshots when the page hasn't changed (detect via hash).

Runtime guidance

**If building a browser agent with Playwright** → Python/Node.js Playwright + [Ollama](/tools/ollama) with vision model. The agentic loop: screenshot → VLM → action dict → Playwright execution → verify. Use Playwright's locator API as a fallback — if the VLM outputs a CSS selector, try locating the element first (more reliable than coordinate click). Use coordinates only as fallback. **If using Cline's built-in browser agent** → [Cline](/tools/cline) with [Ollama](/tools/ollama) and a vision model. Cline's browser tool opens Chromium, executes VLM-guided actions, and returns results to the agent. Setup: install Cline, configure model to Ollama with vision model, prompt with a web task. Note: Cline's browser agent is part of the broader agent loop — it can navigate the web as one tool among others (file read, terminal, search). **If building a production browser agent service** → [vLLM](/tools/vllm) for VLM serving + Playwright pool on separate nodes. vLLM's continuous batching handles concurrent VLM requests from multiple workers. Playwright pool can use AWS Lambda (headless Chromium layer) or Kubernetes pods for scale-to-zero when idle. **If extracting structured data from websites** → Use Playwright + VLM in "extract" mode rather than interactive mode. The VLM receives a screenshot + extraction schema (JSON) and returns structured data. This is more reliable than interactive clicking because each step can't derail the task. Combine with traditional scraping (BeautifulSoup, Cheerio) for known-selector extraction; use VLM only for pages where selectors are unreliable. **If navigating non-English websites** → [Aya Expanse 32B](/models/aya-expanse-32b) with vision. English-centric VLMs misread button text, form labels, and error messages in Japanese, Korean, Arabic, etc. Aya's multilingual training improves non-English web task completion 15-25 percentage points. **If on Apple Silicon** → [MLX LM](/tools/mlx-lm) with vision model via [LM Studio](/tools/lm-studio). MLX's unified memory handles large vision context efficiently — 64GB M4 Max runs 70B vision at 25-35 tok/s with 1920×1080 screenshots. Use Playwright Python (or Swift Playwright bindings); the Mac's native GPU handles Chromium rendering efficiently.

Setup walkthrough

  1. pip install browser-use (Browser-Use — open-source browser agent framework).
  2. Install Ollama → ollama pull qwen2.5-vl:7b (~5 GB — vision-language model for seeing web pages).
  3. Python script:
from browser_use import Agent
import asyncio

async def main():
    agent = Agent(
        task="Go to wikipedia.org, search for 'artificial intelligence', and extract the first paragraph of the article.",
        llm=ChatOllama(model="qwen2.5-vl:7b"),
    )
    result = await agent.run()
    print(result)
asyncio.run(main())
  1. The agent opens a browser (Chromium via Playwright), navigates to Wikipedia, types the search, clicks the result, extracts text, and returns it. First run in 20-60 seconds.
  2. For complex multi-step tasks: "Log into my email, find the latest invoice from Amazon, download it, and save to ~/invoices/." The agent handles login, navigation, dropdowns, file downloads.
  3. The agent sees screenshots (VLM) + reads DOM elements (accessibility tree). The VLM decides "what to click" by analyzing the screenshot.

The cheap setup

Used RTX 3060 12 GB (~$200-250, see /hardware/rtx-3060-12gb). Runs Browser-Use with Qwen2-VL 7B at ~20-40 seconds per agent step (see → decide → act). A 5-step task (search, click, scroll, click, extract) takes 2-4 minutes. For automation of daily web tasks (form filling, data extraction, monitoring): $400 handles 10-30 tasks/day. Pair with Ryzen 5 5600 + 32 GB DDR4 + 512 GB NVMe. Total: ~$390-440. The bottleneck is VLM inference speed (5-10 seconds per screenshot) and reasoning quality.

The serious setup

Used RTX 3090 24 GB ($700-900, see /hardware/rtx-3090). Runs Browser-Use with Qwen2-VL 72B at ~30-60 seconds per agent step — the 72B handles complex UIs (enterprise SaaS dashboards, multi-step forms, CAPTCHA workarounds) that confuse the 7B. For production browser automation (web scraping at scale, automated testing): Qwen2-VL 7B on RTX 4090 ($2,000, see /hardware/rtx-4090) achieves 10-15 agent steps per minute. Total: ~$1,500-2,500. Browser agents are a VLM throughput problem — faster screenshot analysis = faster agent.

Common beginner mistake

The mistake: Running a browser agent on your personal Chrome profile (with saved passwords, cookies, banking sessions) — giving the AI access to your entire digital life. Why it fails: The agent can click anything. It can navigate to your email → forward sensitive messages → delete evidence. It can access your bank → initiate transfers. Even if the prompt seems benign ("check my Amazon orders"), the agent might misclick into account settings, change your password, or order 100 copies of a book. The fix: Always use a dedicated browser profile. Create a separate Chrome/Chromium profile with only the logins the agent needs. Use incognito mode + manual login per session for sensitive tasks. Never give a browser agent access to your primary browser with saved passwords and active banking/email sessions. The agent is a program executing LLM decisions — it has no judgment about what's safe to click. Sandbox it.

Recommended setup for browser 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 browser agents locally. Each links to a diagnose+fix walkthrough.

Before you buy

Verify your specific hardware can handle browser agents before committing money.

Hardware buying guidance for Browser 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