Hyperbrowser Anchor: Hosted Browser Runtimes Compared

# Hyperbrowser Anchor: Hosted Browser Runtimes Compared

"Hyperbrowser Anchor" is a search that usually means one of two things: you are comparing two hosted browser providers, or you are trying to figure out which one to run your AI agent on. Hyperbrowser and Anchor both sell managed Chromium sessions for automation and agents, and both sit in the same category as Browserbase, Browserless, Steel, Kernel, and Remote Browser. This guide explains what each one is, where they diverge, and the criteria that actually matter when you move an agent from a local script to a hosted runtime.

If you just want the short version: both are hosted browser APIs that give you a Chromium session over CDP. The decision comes down to session startup behavior, stealth and proxy handling, how you connect your agent framework, and how usage is metered. Remote Browser is a third option in that same category, and we will be explicit about where it fits.

What Hyperbrowser and Anchor actually are

Hyperbrowser is a hosted browser platform aimed at AI agents and scraping workloads. It exposes session creation through an API, returns a CDP endpoint, and supports the usual stack: Playwright, Puppeteer, and agent frameworks that speak CDP. It also ships an MCP server, which is why searches like "hyperbrowser mcp" show up alongside this one.

Anchor is a hosted browser provider in the same lane. It shows up in provider comparisons for stealth success rates and session startup speed, and it targets agent and automation workloads with managed Chromium sessions.

Neither is a browser engine. Both run real Chromium on their infrastructure and hand you a connection string. That matters because it means your agent code should not depend on which provider you pick — if it does, you have coupled your agent to a vendor instead of to CDP.

The practical consequence: treat the provider as infrastructure, not as an SDK. Write your agent against Playwright or Puppeteer over CDP, keep the connection string in configuration, and you can move between Hyperbrowser, Anchor, and Remote Browser without rewriting task logic.

The comparison that matters

Marketing pages for hosted browsers all say roughly the same things. Here is a more useful breakdown of the dimensions that change how your agent behaves in production.

A few notes on each, because the table hides the trade-offs.

Session startup is the most over-indexed metric in this category. A provider that starts sessions in a fraction of a second is nice, but if your agent spends 40 seconds on a page waiting for a selector, startup time is noise. Optimize startup only after you have fixed flaky waits and retries.

CDP compatibility is where providers quietly differ. Some expose a full CDP endpoint; others wrap it in a proprietary session API and only partially proxy the protocol. If you use Playwright's connectOverCDP, you want a real endpoint. The Chrome DevTools Protocol is the contract — anything that claims CDP support should let you run standard CDP commands against the session.

Stealth and proxies are the hardest to compare honestly. Published stealth benchmarks measure specific sites on specific dates and do not transfer to your target sites. What you can compare is configurability: can you set a proxy per session, choose a region, and control browser settings that affect detection? Prefer "configurable browser settings" over any claim of guaranteed evasion.

Persistent profiles decide whether your agent can do anything that requires a login. If a provider wipes storage between sessions, every run starts from a login page, and your agent burns tokens on authentication instead of the task.

Metering is where the category diverges most. Some providers bill per browser-hour, some per session, some per request. A cheap hourly rate with slow sessions can cost more than a higher rate with fast teardown. Read the actual unit before comparing numbers, and check /pricing for current Remote Browser details rather than trusting a blog post from six months ago.

Connecting an agent to a hosted session

The connection pattern is the same across providers, which is the point. Here is a TypeScript example using Playwright over CDP. Swap the endpoint for whichever provider you use.

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

interface SessionConfig {
  cdpEndpoint: string; // e.g. wss://<provider-host>/<session-id>
  timeoutMs?: number;
}

async function connectToHostedSession(
  config: SessionConfig
): Promise<{ browser: Browser; page: Page }> {
  const browser = await chromium.connectOverCDP(config.cdpEndpoint, {
    timeout: config.timeoutMs ?? 30_000,
  });

  // Hosted sessions usually expose one default context.
  const contexts = browser.contexts();
  const context = contexts.length > 0 ? contexts[0] : await browser.newContext();
  const page = context.pages()[0] ?? (await context.newPage());

  return { browser, page };
}

async function runTask(cdpEndpoint: string) {
  const { browser, page } = await connectToHostedSession({ cdpEndpoint });

  try {
    await page.goto("https://example.com", { waitUntil: "domcontentloaded" });
    const title = await page.title();
    console.log("Loaded:", title);
  } finally {
    // Close the connection, not the remote browser, unless you own its lifecycle.
    await browser.close();
  }
}

Two details that trip people up:

1. `browser.close()` on a CDP connection disconnects; it does not always terminate the remote session. If your provider bills per browser-hour, an orphaned session keeps costing money. Call the provider's session-stop endpoint explicitly in your cleanup path.
2. Do not assume a fresh context. Some hosted sessions come with a default context and page already open. Handle both cases, as above, or you will get duplicate pages and confusing selector failures.

For a deeper walkthrough of the runtime model — sessions, profiles, proxies, and live debugging — see /blog/remote-browser-for-ai-agents.

Where Remote Browser fits

Remote Browser is a hosted Chromium runtime for AI agents and browser-use workflows. It provides CDP access, Playwright/Puppeteer/Selenium compatibility, a live viewer, persistent profiles, configurable browser and proxy settings, session isolation, and usage controls. It is not a different category from Hyperbrowser or Anchor — it is a third option in the same category, and the honest comparison is on the criteria above, not on feature checklists.

A few things worth knowing before you evaluate any provider, including this one:

• Bring your own agent framework. Remote Browser does not require you to adopt a proprietary agent SDK. If you already run browser-use, Stagehand, or a custom Playwright loop, you connect over CDP and keep your code.
• Sessions are isolated. Each session gets its own browser context, which matters when you run many agents concurrently and do not want cookies or storage bleeding between tasks.
• Profiles persist when you need them. For logged-in flows, persistent profiles let a session resume with existing cookies and storage instead of re-authenticating.
• The live viewer is a debugging tool, not a demo. When an agent fails at step 7 of a 12-step task, watching the session is faster than reading logs.

If you want to see the runtime in action without installing anything, /blog/remote-browser-online covers the zero-setup path, and /blog/remote-web-browser explains the practical runtime model.

Production criteria for any hosted browser

Whether you pick Hyperbrowser, Anchor, or Remote Browser, these are the questions that predict whether the thing survives contact with real workloads.

1. What is the failure mode when a session dies?

Sessions time out, browsers crash, and networks drop. Your agent needs a retry path that creates a new session, reconnects, and resumes from a checkpoint — not from the beginning. Providers that expose session status and events make this easier. Providers that only return a CDP URL leave you guessing.

2. How do you debug a failed run?

Logs from inside the browser are limited. You want either a live viewer or session recordings. If a provider offers neither, you will be debugging blind at 2 a.m. when a customer's task fails.

3. How is concurrency enforced?

Every provider has a concurrency limit tied to your plan. Know what happens when you exceed it: queued, rejected, or silently throttled. Silent throttling is the worst outcome because your agent appears to hang. Check the plan limits before you scale a worker pool.

4. What does the proxy model look like?

Per-session proxies, per-request proxies, and account-level proxies behave very differently. If your agent hits geo-restricted content, you need per-session control. If you are scraping at volume, you need to understand how proxy bandwidth is billed separately from browser-hours.

5. Can you self-host if you need to?

Some teams need data residency, air-gapped environments, or cost control at very high volume. Browserless and Steel are commonly cited self-host options; hosted providers generally are not. If self-hosting is a hard requirement, that narrows the field immediately. If it is a "maybe later" requirement, pick a provider whose API surface you could replicate with your own Chromium fleet.

6. What is the actual unit of cost?

Per browser-hour is the most common unit, but session minimums, proxy bandwidth, and concurrency tiers all change the effective price. Model your workload — average session length, sessions per task, tasks per day — and compute cost per completed task, not cost per hour. A provider that is cheaper per hour but slower per task can lose.

Common integration mistakes

These show up regardless of provider.

• Hardcoding the CDP endpoint. Put it in an environment variable. You will change providers or regions eventually.
• Ignoring `waitUntil` semantics. networkidle is unreliable on modern sites with long-polling. Prefer domcontentloaded plus explicit selector waits.
• Reusing one session for unrelated tasks. Session isolation exists for a reason. Sharing a session across tasks leaks cookies and causes state-dependent failures.
• Not closing sessions. Orphaned sessions are the most common source of surprise bills in this category.
• Treating stealth as a solved problem. No provider guarantees access to every site. Build fallbacks: retry with a different proxy, slow down, or surface a clear failure to the user.

Choosing between Hyperbrowser, Anchor, and Remote Browser

There is no universal winner, and any article that claims one is selling something. The useful framing:

• If you need a specific integration — an MCP server, a particular agent framework, a specific proxy region — check that first. Integration fit beats marginal pricing differences.
• If you are cost-sensitive at volume, model cost per completed task across providers using your real session lengths. See /pricing for Remote Browser's current terms.
• If you need self-hosting, look at Browserless or Steel; hosted providers are not the answer.
• If you want to avoid lock-in, write against CDP and keep the endpoint configurable. Then the choice is reversible.

The category is converging on the same architecture: real Chromium, CDP endpoint, session API, live viewer, persistent profiles. The differences are in operational details — startup behavior, proxy model, metering, and how well the provider handles failure. Evaluate on those, run a small pilot against your actual target sites, and measure task success rate rather than benchmark scores from someone else's workload.

Start with the /documentation to see how Remote Browser exposes sessions and CDP endpoints, then run one real task end to end before you commit to any provider.