Browser Use AI: Hosted Chromium for Reliable Agents

# Browser Use AI: Hosted Chromium for Reliable Agents

Browser use AI is the practice of letting a language model drive a real browser — clicking, typing, reading the DOM, and navigating — to complete a task on the open web. The model is the decision layer. The browser is the execution layer. Most teams get the first part working in an afternoon and then spend months fighting the second part. This post is about that second part: what a browser-use AI workload actually needs from its runtime, where local Chrome breaks down, and how to wire a hosted Chromium session into a Playwright or CDP client without rewriting your agent.

If you already have a working agent loop and you are now hitting flaky sessions, missing profiles, or a laptop that can't hold twenty concurrent browsers, you are the target reader. If you are still deciding whether agents should touch a browser at all, start with Remote browsers for AI agents and come back.

What "browser use AI" actually means in practice

The term covers a spectrum. At one end is a scripted Playwright test that happens to be generated by a model. At the other end is a fully autonomous agent that receives a natural-language goal, plans steps, observes the page after each action, and decides what to do next. Both are browser use AI. They have very different runtime requirements.

The autonomous end of the spectrum is where the interesting engineering lives. An autonomous agent needs:

• A persistent observation loop. It reads the page state after every action, so the browser must stay alive and addressable between steps — not spin up and tear down per call.
• A stable session identity. Login state, cookies, and localStorage must survive across steps and often across runs. A fresh incognito context every time means re-authenticating on every task.
• Deterministic control surfaces. The agent needs to click a specific element, not "somewhere near the button." That means CDP or a Playwright-compatible driver, not screenshot-and-guess.
• Isolation between tasks. Two agents running concurrently must not share cookies, storage, or a browser process. Cross-contamination produces bugs that look like model failures but are actually runtime failures.

None of these are model problems. They are infrastructure problems, and they are the reason browser use AI projects stall after the demo.

Why local Chrome stops working

The default path is to launch Chromium on the same machine that runs the agent. It works for one agent doing one task. It degrades predictably as you scale.

The concurrency row is the one that usually forces the decision. A single headless Chromium context is not enormous, but twenty of them plus the agent processes plus the model calls will exhaust a typical developer machine. Teams respond by containerizing, then by writing a scheduler, then by discovering they have built a browser orchestration layer they now have to maintain. That layer is the product category Remote Browser occupies.

There is a second, subtler failure. Local Chrome carries the developer's fingerprint — their extensions, their fonts, their timezone, their IP. When a task fails in production but succeeds locally, you are debugging an environment difference, not an agent bug. Hosted sessions remove that variable.

The runtime contract: what your agent needs from the browser layer

Before comparing tools, define the contract. A browser-use AI runtime should expose:

1. A session lifecycle API. Create, connect, keep alive, and terminate. Sessions should have IDs you can log and correlate with agent traces.
2. CDP access. The Chrome DevTools Protocol is the lowest common denominator. Anything that speaks CDP can drive the session. See the Chrome DevTools Protocol documentation for the full surface.
3. Playwright/Puppeteer/Selenium compatibility. You should not have to abandon your existing driver. Playwright's connectOverCDP is the standard entry point — the Playwright CDP docs cover the connection semantics.
4. Persistent profiles. Named profiles that survive session restarts, so authentication is a one-time cost per identity.
5. Isolation. Per-session storage, cookies, and cache. No shared state unless you opt in.
6. Observability. A live viewer for humans, and logs or events for machines.
7. Usage controls. You need to know what a session costs and be able to cap it. Current rates and limits live on the pricing page.

If a candidate runtime is missing items 3 through 5, it is a demo tool, not a production one.

Connecting a Playwright agent to a hosted session

The connection pattern is the same whether you are running a scripted flow or an autonomous loop. You obtain a CDP endpoint for a session, connect over it, and drive the resulting browser object exactly as you would a local one.

import { chromium, Browser, Page } from "playwright";

// The endpoint comes from your session-creation call.
// Treat it like a secret: it grants full control of the browser.
const CDP_ENDPOINT = process.env.REMOTE_BROWSER_CDP!;

async function runAgentTask(goal: string): Promise<string> {
  let browser: Browser | undefined;

  try {
    browser = await chromium.connectOverCDP(CDP_ENDPOINT, {
      timeout: 30_000,
    });

    // A hosted session usually exposes one persistent context.
    const context = browser.contexts()[0] ?? (await browser.newContext());
    const page: Page = context.pages()[0] ?? (await context.newPage());

    await page.goto("https://example.com/login", {
      waitUntil: "domcontentloaded",
    });

    // Persistent profiles mean this only runs on the first task
    // for a given identity.
    if (await page.locator("#login-form").isVisible()) {
      await page.fill("#username", process.env.APP_USER!);
      await page.fill("#password", process.env.APP_PASS!);
      await page.click("button[type=submit]");
      await page.waitForLoadState("networkidle");
    }

    // Hand control to the agent loop. The agent observes and acts
    // against the same live page object.
    const result = await agentLoop(page, goal);
    return result;
  } finally {
    // Disconnect the client. Whether this also terminates the
    // session depends on your session policy — check the docs.
    await browser?.close();
  }
}

async function agentLoop(page: Page, goal: string): Promise<string> {
  // Your model call, observation extraction, and action dispatch.
  // The important part: `page` stays alive across every step.
  throw new Error("implement your agent loop");
}

Three details matter here. First, connectOverCDP does not launch a browser — it attaches to one that already exists, which is why the session must be created before this call. Second, browser.close() on a CDP connection disconnects the client; it does not necessarily kill the remote browser. Confirm your provider's semantics so you do not leak sessions. Third, the persistent context is what makes login state survive; if you call newContext() on every task you have thrown that away.

For the full connection surface — including how to attach to an already-running session and how to handle reconnects — see the documentation.

Where browser use AI differs from test automation

A Playwright test suite and a browser-use AI agent share a driver but not a workload profile.

Tests are deterministic and short. They run for seconds, assert on known selectors, and either pass or fail. Retries are cheap because the whole test is cheap.

Agents are non-deterministic and long. A single task may run for minutes, take an unpredictable path, and encounter pages the developer never saw. Retrying from scratch is expensive because the agent has to re-derive its plan.

This changes the runtime requirements. Agents benefit disproportionately from:

• Long-lived sessions. Restarting a browser mid-task forces the agent to rebuild context.
• Persistent profiles. Re-authentication is a multi-step sub-task the agent must plan around.
• Live inspection. When an agent gets stuck, a human needs to see the page state at the moment of failure, not a screenshot from three steps ago.
• Session recording. Replaying the exact sequence of actions is the fastest path to a fix.

If you are coming from a test-automation background, the mental shift is that the browser is not a fixture you set up and tear down per test. It is a long-running resource the agent holds for the duration of a task.

Choosing between self-hosted and hosted

The honest answer is that self-hosting is viable if you have the operational appetite. Running Chromium in containers behind a scheduler is a solved problem, and if you already run Kubernetes you can do it.

The trade-off is where your engineering time goes. Self-hosting means owning:

• Browser image updates and security patches
• Session scheduling and bin-packing
• Configurable network egress and per-session proxy settings
• Profile storage and backup
• Debugging tooling for stuck sessions
• Cost attribution per agent task

A hosted runtime moves that list to a vendor and gives you a connection string. The cost is per-session metering and a dependency on someone else's uptime. For teams whose differentiator is the agent, not the browser fleet, the hosted path usually wins on time-to-production.

This is the same trade-off discussed in Browser-As-A-Service vs self-hosted Playwright infra, and it is worth reading before you commit either way.

Practical criteria for evaluating a browser-use AI runtime

When you compare options — hosted providers, self-hosted stacks, or the CLI tools that wrap them — score them against these:

• Does it speak CDP? If not, you are locked into one driver.
• Can you keep a session alive across agent steps? Test this explicitly; some providers tear down on disconnect.
• Are profiles first-class? Named, persistent, and isolated per identity.
• Is there a live viewer? You will need it the first time an agent loops.
• Can you set proxy and browser settings per session? Configurable settings matter more than any single feature claim.
• Is usage metered transparently? You should be able to predict cost per task before you scale.
• What happens on failure? Can you retrieve the session state, or is it gone?

A runtime that passes all seven is production-grade. One that passes four is a prototype tool.

Getting started

The shortest path is to create a session, grab its CDP endpoint, and point your existing Playwright code at it. If your agent already works against local Chrome, the change is one line — the connection call — plus moving session creation out of your process.

From there, the work is in the agent loop, not the browser. Persistent profiles remove re-authentication. Session isolation removes cross-task contamination. The live viewer removes the guesswork when something hangs.

Start with the documentation for the session API and connection details, and check pricing for current metering before you size a fleet. If you want the conceptual background first, Remote web browser covers why the browser belongs in the cloud rather than on the agent host, and Remote control browser covers the control-plane patterns that keep long-running agents debuggable.

The model will keep getting better. The runtime is the part you have to get right yourself.