Browser Infrastructure for Computer Use Agents: Pointing Claude or OpenAI at a Hosted Browser

What does a computer-use agent need from a browser?

A computer-use agent needs four things from its browser: pixel-accurate screenshots at a fixed viewport, low-latency input execution (clicks, typing, scrolling), a stable connection that survives a loop of dozens of round trips, and an environment that websites don't immediately flag as a bot.

That's because computer-use tooling, whether it's Claude's computer tool or OpenAI's computer_use_preview, doesn't browse on its own. The model only ever sees screenshots and returns action requests. Your application owns the browser, executes each action through an automation library like Playwright, and sends the resulting screenshot back. The loop looks like this:

1. Capture a screenshot of the page and send it to the model with the task.
2. The model responds with an action: click at coordinates, type text, press a key, scroll.
3. Your code executes that action in the browser.
4. Capture a new screenshot and send it back.
5. Repeat until the model stops requesting actions.

One detail that trips people up: the viewport must match the display dimensions you declare to the model. Both the Claude and OpenAI integrations use 1024x768. If the browser renders at a different size, the model's click coordinates land in the wrong place.

Nothing in that loop requires the browser to run on your machine. It requires a browser your code can drive over the Chrome DevTools Protocol (CDP), which is exactly what a hosted wss endpoint gives you.

How do you point Claude Computer Use at a hosted browser?

Connect Playwright to the Browserless WebSocket endpoint with connectOverCDP, then run Claude's computer-use loop against that page. The connection is one line; everything else is the standard Anthropic loop.

import { chromium } from "playwright-core";
import Anthropic from "@anthropic-ai/sdk";

const browser = await chromium.connectOverCDP(
  `wss://production-sfo.browserless.io?token=${process.env.BROWSERLESS_API_KEY}`,
);

try {
  // Use the default context: a new one would not inherit Browserless
  // launch settings like the configured profile or proxy.
  const context = browser.contexts()[0];
  const page = context.pages()[0] ?? (await context.newPage());
  await page.setViewportSize({ width: 1024, height: 768 });
  await page.goto("https://example.com");

  const anthropic = new Anthropic();
  const response = await anthropic.beta.messages.create({
    model: "claude-sonnet-4-6",
    max_tokens: 1024,
    betas: ["computer-use-2025-11-24"],
    tools: [
      {
        type: "computer_20251124",
        name: "computer",
        display_width_px: 1024,
        display_height_px: 768,
      },
    ],
    messages: [
      {
        role: "user",
        content: "Find the pricing page and summarize the plans.",
      },
    ],
  });
  // ...run the action loop here...
} finally {
  await browser.close();
}

From there you parse each tool_use block, execute the requested action with Playwright (page.mouse.click, page.keyboard.type, page.mouse.wheel), screenshot the page as base64 PNG, and return it as the tool_result. The full working loop is in the Browserless docs, including the action handler for clicks, typing, key presses, and scrolling.

Because the browser is remote, the agent process itself is a small stateless Node or Python service. You can run it on a serverless function, a queue worker, or a laptop, and it behaves identically.

How do you run OpenAI computer-use against a remote browser?

The same pattern works for OpenAI's computer-use tooling: connect Playwright over CDP to a Browserless endpoint, declare a 1024x768 display, and drive the loop through the Responses API with the computer-use-preview model.

import os
from playwright.sync_api import sync_playwright
from openai import OpenAI

with sync_playwright() as p:
    browser = p.chromium.connect_over_cdp(
        f"wss://production-sfo.browserless.io/chromium/stealth?token={os.environ['BROWSERLESS_API_KEY']}",
        timeout=60000,
    )
    try:
        # Use the default context; a new one would not inherit
        # Browserless launch settings like the profile or proxy.
        context = browser.contexts[0]
        page = context.pages[0] if context.pages else context.new_page()
        page.set_viewport_size({"width": 1024, "height": 768})
        page.goto("https://example.com")

        client = OpenAI()
        response = client.responses.create(
            model="computer-use-preview",
            tools=[
                {
                    "type": "computer_use_preview",
                    "display_width": 1024,
                    "display_height": 768,
                    "environment": "browser",
                }
            ],
            input=[{"role": "user", "content": "Find the pricing page and summarize the plans."}],
            truncation="auto",
        )
        # ...run the action loop here...
    finally:
        browser.close()

The loop mechanics differ slightly from Anthropic's: you look for computer_call items in the response, execute the action, then send a fresh screenshot back referencing previous_response_id. When the response contains no more computer_call items, the task is done. The OpenAI CUA integration guide has the complete loop.

Note the connection URL above uses the /chromium/stealth route. Computer-use agents move like humans but connect like bots, and plenty of sites block them at the first request. The stealth route runs a browser hardened against fingerprinting, which is the difference between an agent that works in a demo and one that works on real sites.

Running Gemini instead? The loop is the same shape, and there's a dedicated Gemini computer-use guide in the docs.

How do you deploy a browser agent to production?

Deploying a browser agent to production means solving problems that don't show up in a demo: keeping session state between runs, running many agents concurrently, avoiding bot detection, controlling where traffic exits, and bounding what the agent is allowed to do. With a hosted browser backend, most of these are a query parameter or an API call, not a system you have to build and babysit.

Session persistence between runs

Agents constantly re-encounter login walls, cookie banners, and multi-step flows. Recreating that state on every run burns model tokens and adds failure modes. Browserless gives you two mechanisms:

• The Session API: POST /session with a TTL returns connect, stop, and browserQL URLs for a session whose cookies, localStorage, and cache persist in an isolated userDataDir, surviving full browser restarts for up to days depending on plan.
• Authenticated Profiles: log in once, save the profile, then replay it into any number of parallel sessions with ?profile=<name>. This is how you give a fleet of agents the same authenticated identity without sharing one browser.

curl -X POST 'https://production-sfo.browserless.io/session?token=YOUR_API_TOKEN' \
  -H 'Content-Type: application/json' \
  -d '{ "ttl": 300000 }'

The response includes a connect URL you pass straight to connectOverCDP, so a follow-up agent run resumes with the state the last run left behind.

Concurrency

A local Chrome container gives you one browser per container and a scaling problem per browser. A hosted endpoint pools browsers for you: every connectOverCDP call gets a clean, isolated browser, and running fifty agents means opening fifty connections, not orchestrating fifty containers. Plan limits meter concurrent browsers, so capacity planning is a pricing-page decision instead of a Kubernetes one.

Bot detection and proxies

Computer-use agents fail most often at the network layer, not the reasoning layer. Datacenter IPs and default headless fingerprints get blocked before the model sees a single screenshot. In production you'll want:

• The /chromium/stealth route for a hardened fingerprint.
• Built-in residential proxies with country targeting (proxy=residential&proxyCountry=us), or bring your own proxy if you already have one.
• CAPTCHA solving in-session when a challenge does appear.

Regions and latency

The screenshot-action loop is chatty, so browser-to-agent latency compounds. Browserless runs regional endpoints (production-sfo, production-lon, production-ams); pick the one closest to where your agent service runs.

Security boundaries

Everything the model sees on a page is untrusted input. A malicious page can embed text designed to redirect the agent (prompt injection), and the model may follow it. Anthropic's Computer Use guidance covers this in depth; the short version for a browser backend:

• Isolate each run. Every Browserless connection gets its own browser instance, so one poisoned session can't read another's cookies or state.
• Scope credentials to the task. An Authenticated Profile should hold the one login the agent needs, never a catch-all identity with access it doesn't.
• Keep a human approval step in front of consequential actions: purchases, consent, account changes.
• Where the task allows it, restrict the agent to an allowlist of trusted domains.

None of this is optional hardening for later. An agent that browses the open web will eventually land on a page that tries to steer it.

Do you need to self-host a browser for computer-use agents?

No. Anything that speaks CDP works against a hosted wss endpoint, and for most teams that removes an entire category of infrastructure work: Chrome versioning, zombie processes, memory leaks, and fingerprint maintenance.

Self-hosting is still the right call for some environments, typically compliance regimes where browser traffic can't leave your network. Browserless is one of the few browser platforms you can self-host with Docker under an Enterprise license, so the same agent code runs against a cloud endpoint today and an in-VPC deployment later by changing one URL.

If you'd rather not build the loop at all, the Browserless MCP server exposes browser automation as tools that Claude and other MCP clients call directly, with the session, stealth, and proxy handling built in.

Conclusion

Computer-use models are converging on the same contract: screenshots in, actions out. The model API is the easy half. Whether the agent survives contact with real websites gets decided on the browser side, and none of that engineering has to be yours. Point your loop at wss://production-sfo.browserless.io?token=YOUR_TOKEN, set the viewport to 1024x768, and you get sessions, stealth, proxies, and concurrency without running a single Chrome process. Grab a free API key and connect your agent in the time it takes to read the docs page.

FAQ

What is the best browser infrastructure for Computer Use agents?

The best browser infrastructure for a computer-use agent is a hosted CDP endpoint: it gives the agent an isolated, production-grade browser per run without you operating Chrome. Browserless provides this over wss:// with documented integrations for Claude, OpenAI, and Gemini computer-use tooling, plus stealth fingerprints, residential proxies, and persistent sessions for production use.

Can Claude Computer Use control a remote browser?

Yes. Claude Computer Use never touches the browser directly; your code executes its actions through Playwright or Puppeteer, and those libraries connect to a remote browser over CDP. Connecting to wss://production-sfo.browserless.io?token=YOUR_TOKEN with chromium.connectOverCDP is all it takes.

How do agents stay logged in across runs?

Use the Browserless Session API to persist cookies, localStorage, and cache between connections, or Authenticated Profiles to capture a login once and replay it into many parallel sessions. Both survive full browser restarts, so agents skip the login step entirely on subsequent runs.

How is this different from using the OpenAI or Anthropic sandboxed browser environments?

Hosted computer-use demos and sandboxes are fine for evaluation, but production agents need control over proxies, fingerprints, session state, and region. Running your own loop against a browser backend gives you that control while the model API stays exactly the same.