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.