Anchor Browser: What It Is and How to Run One

"Anchor Browser" is a search term that shows up in two different contexts, and conflating them wastes time. In one context it is a product name for a hosted browser platform aimed at AI agents. In the other, it describes a pattern: a stable, always-available browser session that an agent anchors to, rather than a throwaway local Chrome that dies with the process. This guide covers both meanings, then focuses on the part that actually matters for developers — how to run an anchored browser session you can drive over CDP with Playwright, Puppeteer, or Selenium, and what to check before you put it in production.

If you are evaluating hosted runtimes generally, start with Remote Browser for AI agents. If you want the mechanics of connecting code to a remote Chromium instance, keep reading.

What "Anchor Browser" Actually Refers To

The term gets used loosely, so it helps to separate the layers.

As a product name. Anchor Browser is a hosted browser platform positioned around AI agents and automation. Like Browserbase, Browserless, Kernel, Steel, and Hyperbrowser, it sells remote Chromium sessions with an API in front. If you searched for it by name, you are probably comparing hosted browser providers and want to know how they differ on session lifecycle, CDP access, stealth, and price.

As a pattern. An "anchor" browser is a long-lived session that persists across agent steps, tool calls, and sometimes across separate worker processes. The agent anchors to it: it holds cookies, localStorage, an authenticated login, and an open tab state. This is the opposite of the default Playwright model, where browser.newContext() gives you a clean slate every run.

The pattern is what most production agents actually need. A research agent that logs into a dashboard, navigates five pages, and files a report cannot afford to re-authenticate at every step. A QA harness that reproduces a bug needs the exact session state that triggered it. An "anchor" session is the mechanism that makes those workflows possible.

Most of the confusion in this keyword space comes from treating the product name and the pattern as the same thing. They are not. You can build an anchored session on any CDP-compatible hosted runtime, including Remote Browser, and you can use Anchor Browser's product without ever thinking about the pattern. The rest of this article is about the pattern, because that is the part you have to design.

Why Agents Need an Anchored Session

A local Chromium launched by playwright.chromium.launch() is tied to the process that started it. When the script exits, the browser exits. When the container is recycled, the profile directory goes with it. For a one-shot scrape that is fine. For an agent that runs for minutes or hours, it is a problem for four reasons.

State loss. Login sessions, cart contents, multi-step form progress, and in-page JavaScript state all vanish when the browser closes. Rebuilding them costs tokens, time, and sometimes money if the flow involves a paid action.

Concurrency collisions. If ten agent workers each launch their own Chromium, you are managing ten browser binaries, ten sets of dependencies, and ten failure modes on whatever machine runs them. Anchoring to a hosted session moves that problem to the provider.

Debugging blindness. When an agent fails on step seven, you want to see the page it was looking at. A headless local browser gives you a stack trace and nothing else. A hosted session with a live viewer gives you the actual DOM, the network tab, and the console.

Environment drift. Local Chrome versions, fonts, and OS-level rendering differ between a developer laptop and a CI runner. A hosted runtime pins the browser build, which makes behavior reproducible.

An anchored session solves all four by decoupling the browser's lifetime from the code that drives it. The agent connects, does work, disconnects, and reconnects later to the same session.

How a Hosted Anchored Session Works

The architecture is straightforward once you see the pieces.

1. Session creation. You call an API endpoint that provisions a Chromium instance on the provider's infrastructure. The response includes a session ID and a CDP WebSocket endpoint.
2. Connection. Your code connects to that endpoint over the Chrome DevTools Protocol. Playwright's connectOverCDP, Puppeteer's connect, and Selenium's remote WebDriver all speak CDP or a CDP-adjacent protocol.
3. Persistence. The session stays alive until you stop it or it hits a configured timeout. Persistent profiles let you reuse cookies and storage across sessions if you need longer-lived identity.
4. Observation. A live viewer lets a human watch the session in real time, which is useful for debugging and for human-in-the-loop approval steps.
5. Teardown. You stop the session explicitly, or the runtime reclaims it after idle timeout.

The important design decision is where the session boundary sits. If each agent step creates a new session, you have not anchored anything — you have just moved the throwaway browser to someone else's servers. If the session spans the whole task, you get the benefits above but you pay for browser-hours while the agent is thinking, not just while it is clicking.

That trade-off is real. A session that idles for two minutes between agent steps still bills. The right answer depends on your task shape: short, dense automation should use short sessions; long, sparse agent loops should either keep sessions alive deliberately or checkpoint state and reconnect.

Connecting Playwright to an Anchored Browser

The most common integration is Playwright over CDP. The pattern is the same whether you are connecting to Anchor Browser, Remote Browser, or a self-hosted Chromium with --remote-debugging-port.

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

interface SessionInfo {
  cdpUrl: string;
  sessionId: string;
}

async function createSession(): Promise<SessionInfo> {
  // Replace with your provider's session-creation endpoint.
  const res = await fetch('https://api.example.com/v1/sessions', {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
      Authorization: `Bearer ${process.env.BROWSER_API_KEY}`,
    },
    body: JSON.stringify({
      profileId: 'research-agent',
      timeoutSeconds: 900,
    }),
  });
  if (!res.ok) throw new Error(`session create failed: ${res.status}`);
  return res.json();
}

async function runTask(): Promise<void> {
  const session = await createSession();
  let browser: Browser | undefined;

  try {
    browser = await chromium.connectOverCDP(session.cdpUrl);
    const context = browser.contexts()[0] ?? (await browser.newContext());
    const page: Page = context.pages()[0] ?? (await context.newPage());

    await page.goto('https://example.com/dashboard', {
      waitUntil: 'domcontentloaded',
    });
    await page.getByRole('button', { name: 'Reports' }).click();
    await page.waitForLoadState('networkidle');

    const rows = await page.locator('table tbody tr').count();
    console.log(`rows: ${rows}`);
  } finally {
    // Disconnect without killing the remote browser if you plan to reconnect.
    await browser?.close();
  }
}

runTask().catch((err) => {
  console.error(err);
  process.exit(1);
});

Three details matter here and are easy to get wrong.

`browser.close()` semantics. With connectOverCDP, calling close() disconnects your client. Whether it also terminates the remote browser depends on the provider and the connection mode. Check the docs before assuming. If you want to reconnect later, you usually need to leave the session running and stop it via the API.

Context reuse. browser.contexts()[0] returns the existing context if the session was created with one. Creating a new context on a persistent session can silently discard the profile state you were relying on.

Timeouts. CDP connections can drop on long idle periods. Wrap reconnects in a retry loop with backoff, and treat a dropped connection as recoverable rather than fatal.

For the protocol-level details, the Chrome DevTools Protocol documentation is the authoritative reference, and Playwright's connectOverCDP docs cover the client-side behavior.

Comparing Anchored Session Options

There is no single best runtime. The right choice depends on how much control you need, how much infrastructure you want to own, and how your agent's task shape maps to billing.

The hosted row is where most production teams land, but "hosted" is not a monolith. When comparing providers, ask:

• Does the session survive client disconnects? If not, you cannot anchor across worker restarts.
• Is the CDP endpoint a raw WebSocket or a proxy? Proxies can add latency and occasionally drop frames; raw endpoints are simpler to debug.
• What happens at idle timeout? A session that dies at 60 seconds of inactivity is not usable for agent loops that think for minutes.
• Can you pin the browser version? Reproducibility depends on it.
• How is usage metered? Browser-hours, sessions, or actions — each shapes your cost model differently. See pricing for how Remote Browser meters usage.

Production Criteria for an Anchored Browser

Once you have a working connection, the hard part is keeping it working. These are the criteria that separate a demo from a system.

Session isolation. Each agent task should get its own browser context or session. Sharing a session across concurrent tasks causes cookie bleed and race conditions that are miserable to debug. Confirm that the runtime isolates storage, cache, and network state per session.

Persistent profiles. For workflows that need a logged-in identity across sessions, persistent profiles let you save and reload cookies and localStorage. This is different from session persistence: profiles survive session teardown. Use them deliberately, and scope them per user or per tenant.

Configurable browser settings. Proxy configuration, user-agent, locale, timezone, and viewport are the settings that most often need to vary per task. "Stealth" is a loaded term — what you actually get varies by provider, so verify specific capabilities against each provider's documentation rather than assuming they are included. Prefer runtimes that let you set these explicitly.

Live viewer. Being able to watch a session in real time is the single highest-leverage debugging feature. It turns "the agent failed" into "the agent clicked the wrong button because the modal was still animating."

Usage controls. Concurrency limits, per-session timeouts, and spend caps prevent a runaway agent from burning through your budget overnight. Check what the runtime enforces versus what you have to enforce in your own code.

Observability. Session logs, network captures, and console output should be retrievable after the fact. If you have to reproduce a failure to see what happened, you will spend more time debugging than building.

Common Mistakes When Anchoring a Browser

A few failure modes show up repeatedly in agent codebases.

• Anchoring too early. Creating a session before the agent knows what it needs to do means paying for idle browser time during planning. Create the session when the first navigation is imminent.
• Anchoring too long. A session held open for an hour of agent reasoning is expensive and fragile. Checkpoint state and reconnect if the task allows it.
• Ignoring reconnect logic. CDP connections drop. If your code treats a dropped connection as a task failure, you will see spurious failures that are actually recoverable.
• Sharing sessions across tasks. This is the most common cause of "works in isolation, fails in parallel." Isolate.
• Assuming `close()` kills the browser. It often does not, and orphaned sessions bill until timeout.

When to Use a Hosted Anchored Browser

The pattern pays off when at least one of these is true:

• Your agent runs longer than a single request-response cycle.
• You need session state to survive worker restarts or horizontal scaling.
• You want a human to be able to watch or intervene in a live session.
• You do not want to own Chromium patching, scaling, and isolation.

It pays off less when your workload is a single short scrape per invocation, or when you have strict data-residency requirements that a hosted runtime cannot meet.

If you are still deciding between local and hosted, Remote Browser online walks through the trade-offs, and remote web browser covers the runtime model in more depth. For the control-plane side — how to drive a session programmatically from an agent loop — see remote control browser.

Getting Started

The shortest path from zero to an anchored session is:

1. Create a session via the API and capture the CDP endpoint.
2. Connect with chromium.connectOverCDP().
3. Reuse the existing context and page rather than creating new ones.
4. Add reconnect logic with exponential backoff.
5. Stop the session explicitly when the task completes.

The documentation covers session creation, profile management, and the viewer. If you are wiring this into an existing Playwright or Puppeteer codebase, most of your selectors and page logic will port unchanged — the only real change is where the browser lives and how long it lives for.

"Anchor Browser" as a keyword will keep pulling in people looking for a specific product. But the underlying question — how do I give my agent a browser it can rely on across steps — is the one that determines whether your automation holds up in production. Answer that first, and the provider choice becomes a much simpler decision.