Anchor Browserbase: Hosted Chromium for AI Agents

# Anchor Browserbase: Hosted Chromium for AI Agents

"Anchor Browserbase" is a search that usually means one of two things: you are comparing Anchor and Browserbase as hosted browser providers, or you are trying to anchor a Browserbase-style session into your own agent stack. Both questions come down to the same production decision — which hosted Chromium runtime your agent connects to, and how that connection is wired. This guide covers the comparison criteria that matter, the CDP mechanics that make any of these providers interchangeable at the code level, and where a runtime like Remote Browser fits when you want hosted sessions without locking your agent to one vendor's SDK.

The short version: Anchor and Browserbase are both managed Chromium providers. They differ in session model, stealth and proxy handling, pricing structure, and how much of the agent loop they own. If your agent already speaks CDP, the provider is a configuration detail, not an architecture decision. If it doesn't, that is the first thing to fix.

What "Anchor Browserbase" actually refers to

The phrase gets used loosely, so it helps to separate the meanings:

• Anchor as a provider. Anchor is a hosted browser service aimed at AI agents, with session creation, stealth-oriented browser settings, and proxy support. It shows up in most 2026 cloud-browser comparisons alongside Browserbase, Browserless, Steel, Kernel, and Hyperbrowser.
• Browserbase as a provider. Browserbase is the best-known hosted Chromium service for agents. It offers session creation via API, CDP endpoints, live session viewing, and a tiered pricing model with concurrency limits per plan.
• "Anchoring" a session. In agent engineering, anchoring means pinning a long-running task to a stable browser session — persistent cookies, logged-in state, a fixed proxy, and a CDP endpoint that survives across worker restarts.

Most people searching this term are doing the first two: evaluating providers. The third is the one that actually determines whether your agent works in production.

Anchor vs Browserbase: the comparison that matters

Provider comparisons tend to fixate on headline price per browser-hour. That number matters, but it is rarely the reason an agent fails. The criteria below are the ones that show up in postmortems.

Anchor and Browserbase both clear the basics — hosted Chromium, CDP access, session APIs. The differences concentrate in stealth handling, proxy breadth, and pricing shape. Browserbase's plans are subscription-first with included hours and per-plan concurrency; Anchor positions more around stealth and agent-specific session behavior. Neither is universally better. The right answer depends on whether your workload is bursty or steady, and whether your bottleneck is blocked requests or session startup time.

One caution on stealth claims: "stealth" is an overloaded word. Ask specifically what is configurable — user agent, viewport, timezone, locale, proxy — versus what is claimed as automatic fingerprint variation. The former is verifiable in a session; the latter is hard to audit and varies by site. Prefer providers that document the settings you can actually set.

Why the provider is a configuration detail, not an architecture

If your agent connects over the Chrome DevTools Protocol, swapping providers is a connection-string change. That is the single most valuable property to design for, because it means:

• You can benchmark two providers against your own workload without rewriting the agent.
• You can fail over if one provider has an outage or a regional issue.
• You are not exposed to SDK churn or a vendor's agent framework decisions.

The CDP path is well documented by the Chrome DevTools Protocol project and by Playwright's CDP documentation. Playwright's connectOverCDP is the most common entry point for agent runtimes because it gives you the full Playwright API — locators, auto-waiting, tracing — against a browser you did not launch.

The trade-off: connectOverCDP is Chromium-only. If your workload needs Firefox or WebKit, CDP is the wrong transport and you should look at Playwright's native remote server model instead. For AI agents, Chromium-only is almost always acceptable, because the sites agents target are tested against Chromium.

Wiring an agent to a hosted session over CDP

The pattern is the same for Anchor, Browserbase, or any CDP-compatible runtime: create a session via the provider's API, read the WebSocket debugger URL from the response, connect, and drive the page. Here is a TypeScript example using Playwright against a generic hosted endpoint.

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

interface SessionResponse {
  id: string;
  cdpUrl: string; // ws:// or wss:// debugger endpoint
}

async function createSession(apiBase: string, token: string): Promise<SessionResponse> {
  const res = await fetch(`${apiBase}/sessions`, {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
      Authorization: `Bearer ${token}`,
    },
    body: JSON.stringify({
      // Provider-specific: region, proxy, profile ID, timeout
      timeoutSeconds: 600,
    }),
  });
  if (!res.ok) throw new Error(`session create failed: ${res.status}`);
  return (await res.json()) as SessionResponse;
}

async function runTask(): Promise<void> {
  const session = await createSession(process.env.BROWSER_API_BASE!, process.env.BROWSER_API_TOKEN!);

  let browser: Browser | undefined;
  try {
    browser = await chromium.connectOverCDP(session.cdpUrl, { timeout: 30_000 });
    const context = browser.contexts()[0] ?? (await browser.newContext());
    const page: Page = context.pages()[0] ?? (await context.newPage());

    await page.goto("https://example.com", { waitUntil: "domcontentloaded" });
    await page.getByRole("link", { name: /more information/i }).click();
    console.log("title:", await page.title());
  } finally {
    // Disconnect the client; the provider session is torn down separately.
    await browser?.close();
  }
}

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

Three details in that snippet matter more than they look:

1. `connectOverCDP` timeout. Hosted sessions can take a few seconds to become ready. A 30-second connect timeout with retry is more robust than a tight one.
2. Reusing the default context. When you connect over CDP, the browser already has a context. Creating a new one is fine, but reusing the existing context preserves any state the provider pre-configured, including proxy and profile settings.
3. `browser.close()` vs session teardown. Closing the Playwright client disconnects you; it does not necessarily terminate the remote session. Call the provider's session-stop endpoint explicitly, or you will pay for idle browser-hours.

That last point is the most common billing surprise in hosted browser work. If you want the full picture of how session time is metered, see Remote Browser for AI agents.

Production criteria beyond the provider choice

Once the CDP wiring is in place, the failure modes shift from "does it connect" to "does it stay reliable at concurrency." These are the things to instrument:

• Session lifecycle. Every session needs an owner, a max lifetime, and a hard stop. Orphaned sessions are the top cause of unexpected spend.
• Profile strategy. Persistent profiles are useful for logged-in workflows and dangerous for isolation. Decide per workload whether a session should share a profile or start clean.
• Proxy assignment. Pin proxies per session, not per request, unless you have a reason to rotate. Mid-session IP changes break auth flows.
• Observability. Capture console logs, network failures, and screenshots on error. A live viewer is useful for debugging in the moment; recordings are useful for postmortems.
• Concurrency headroom. Know your provider's per-plan concurrency cap before you scale a queue. Bursting past it produces 429s that look like agent bugs.

If you are still deciding between a hosted runtime and running Chromium yourself, Remote Browser online covers the operational trade-offs, and remote web browser explains what "remote" actually means at the protocol level.

Where Remote Browser fits

Remote Browser is a hosted Chromium runtime for AI agents and browser-use workflows. It provides CDP endpoints that work with Playwright, Puppeteer, and Selenium, persistent profiles, configurable proxy and browser settings, session isolation, a live viewer for debugging, and usage controls. It does not try to own your agent loop — you bring the agent, the runtime provides the browser.

That positioning is deliberate. The agent frameworks in this space move fast, and the ones that survive tend to be the ones that treat the browser as infrastructure. If your agent speaks CDP, Remote Browser is a drop-in endpoint. If you are evaluating it against Anchor or Browserbase, the comparison table above is the checklist to run — ideally against your own workload, not a synthetic benchmark.

For current plan details and per-browser-hour rates, see pricing. For the API surface, session endpoints, and connection examples, the documentation covers session creation, CDP connection, profiles, and teardown.

A practical evaluation plan

If you are choosing between Anchor, Browserbase, and a runtime like Remote Browser, skip the feature grids and run this instead:

1. Pick three real tasks from your production queue — one login flow, one form submission, one data extraction.
2. Run each 50 times against each provider at your expected concurrency.
3. Measure session start latency (p50/p95), task success rate, and cost per successful task — not cost per hour.
4. Check the failure modes. When a task fails, can you see why? Is there a recording, a live viewer, console logs?
5. Test teardown. Confirm that stopping a session actually stops billing.

Cost per successful task is the only metric that reconciles price and reliability. A provider at half the hourly rate that fails 20% more often is more expensive.

Bottom line

"Anchor Browserbase" is a comparison query, and the honest answer is that both are viable hosted Chromium providers with different pricing shapes and stealth postures. The decision that outlasts either vendor is whether your agent connects over raw CDP. If it does, you can evaluate providers on your own workload, switch when the economics change, and keep your agent code stable. If it doesn't, fix that first — everything else is a detail.