Steel Hyperbrowser: Hosted Browser Runtimes Compared

# Steel Hyperbrowser: Hosted Browser Runtimes Compared

"Steel Hyperbrowser" is a search that usually means one of two things: you are comparing Steel and Hyperbrowser as hosted browser providers, or you landed on a page that mashed the two names together. Either way, the underlying question is the same. You need a remote Chromium runtime that an AI agent or automation script can drive over CDP, and you want to know how the options differ before you commit. This guide compares Steel and Hyperbrowser on the criteria that matter in production — connection model, session lifecycle, stealth and proxy handling, and cost structure — and shows where a runtime like Remote Browser fits when you want hosted Chromium without locking your agent code to one vendor.

What Steel and Hyperbrowser actually are

Both are cloud browser services. You call an API, get back a running Chromium instance, and connect to it with Playwright, Puppeteer, Selenium, or a raw CDP client. Neither is a browser engine of its own; both wrap Chromium and add infrastructure around it: session management, proxy routing, anti-bot handling, and a control plane for starting and stopping browsers.

The differences show up in the details:

• Steel positions itself around an open-source core with a hosted layer on top. That matters if you want the option to self-host later or audit the browser layer directly.
• Hyperbrowser positions itself as a managed platform with agent-oriented features layered on the browser — session APIs, scraping endpoints, and integrations aimed at LLM workflows.

Neither positioning is wrong. The question is which one matches how your agent is built and how much of the browser lifecycle you want to own.

The connection model is the first thing to check

Every hosted browser eventually hands you a CDP endpoint. What differs is how you get there and what you can do with the session once it is open.

The standard path is a WebSocket URL you pass to chromium.connectOverCDP(). If a provider gives you a clean CDP endpoint, your Playwright code is portable — you can point it at a different provider by changing one string. If a provider only exposes a proprietary SDK or an HTTP action API, your agent code becomes coupled to that vendor.

Here is the portable pattern, using a CDP endpoint from any hosted runtime:

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

type SessionResponse = {
  cdpUrl: string;
  sessionId: string;
};

async function runTask(): Promise<void> {
  // Your runtime's session-create endpoint returns a CDP WebSocket URL.
  const res = await fetch(`${process.env.BROWSER_API_URL}/sessions`, {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
      Authorization: `Bearer ${process.env.BROWSER_API_KEY}`,
    },
    body: JSON.stringify({
      // Configurable browser settings: region, proxy, profile, viewport.
      profile: "checkout-agent",
      proxy: { country: "us" },
    }),
  });

  const session: SessionResponse = await res.json();

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

  try {
    await page.goto("https://example.com/account", {
      waitUntil: "domcontentloaded",
    });
    await page.getByRole("button", { name: "Continue" }).click();
    await page.waitForLoadState("networkidle");
  } finally {
    await browser.close();
  }
}

runTask().catch((err) => {
  console.error("agent task failed", err);
  process.exit(1);
});

The important part is not the specific endpoint — it is that the session is reachable over CDP and that browser.close() cleanly ends the billable session. If a provider's SDK hides the CDP URL, ask whether it exposes one anyway. Playwright's connectOverCDP documentation confirms the contract: a WebSocket endpoint, Chromium only.

Comparison: Steel, Hyperbrowser, and a CDP-first runtime

Treat this table as a starting checklist, not a verdict. Pricing and feature tiers change; verify current numbers on each provider's pricing page before you budget.

Where the trade-offs actually bite

Session lifecycle and cost control

Hosted browsers are billed by time. A session that stays open while your agent waits on an LLM call is a session you are paying for. The practical fix is to scope sessions tightly: open, do the work, close in a finally block, and never leave a browser running behind a crashed worker.

If your agent needs to stay logged in across runs, persistent profiles are the alternative to long-lived sessions. You reuse stored cookies and storage state instead of keeping a browser warm. Remote Browser supports persistent profiles for this reason; check /documentation for the profile API shape before you design around it.

Stealth and proxies

Both Steel and Hyperbrowser advertise anti-bot handling. Be careful with the word "stealth" — it is a marketing term, not a spec. What you can actually verify is whether the provider lets you configure proxy geography, user agent, and browser flags, and whether it publishes any independent measurement of success rates. If a provider quotes a pass rate, ask what benchmark, what date, and what task set. Numbers without methodology are decoration.

For most agent workloads, residential or regional proxies matter more than fingerprint tricks, because the failure mode is usually IP reputation, not canvas hashing.

Debugging a live session

When an agent fails at step seven of a twelve-step flow, you need to see the page. A live viewer that lets you attach to the running session is worth more than a verbose log. Confirm that the provider exposes a viewer URL per session and that it works while the agent is still connected — not just as a post-mortem recording.

How this fits an agent stack

If you are building with browser-use, Stagehand, or a custom Playwright agent, the runtime is the layer beneath your agent loop. Your agent decides what to click; the runtime decides where the browser lives and how it is isolated.

Two production criteria matter more than feature lists:

1. Session isolation. One agent's cookies and storage must not leak into another's. Confirm that each session gets a fresh context unless you explicitly opt into a shared profile.
2. Concurrency and quota behavior. Know what happens when you hit your concurrency ceiling — does the request queue, fail fast, or silently degrade? Read the docs, then test it.

For a deeper look at how this layer is structured, see Remote Browser for AI agents and the guide to running remote browsers online.

When to pick which

• Pick Steel if open-source auditability or a self-host escape hatch is a hard requirement for your team.
• Pick Hyperbrowser if you want a managed platform with agent-shaped endpoints and are comfortable with its SDK surface.
• Pick a CDP-first runtime like Remote Browser if you want your Playwright or Puppeteer code to stay portable and your only coupling to be a WebSocket URL.

The last option is the least exciting and usually the most durable. CDP is a browser protocol, not a vendor API. Code written against it survives provider changes.

A migration checklist

If you are moving off Steel or Hyperbrowser — or evaluating all three — run this before you commit:

• Confirm the provider returns a raw CDP WebSocket URL you can pass to connectOverCDP.
• Verify browser.close() terminates the billable session, not just the client connection.
• Test persistent profiles: log in once, restart the session, confirm the login survives.
• Check proxy configuration granularity (country, session stickiness).
• Measure cold-start time for a new session under your expected concurrency.
• Confirm the live viewer works mid-session.
• Read the pricing page for overage and concurrency rules, not just the headline rate.

Run each check against your actual agent task, not a hello-world page load. The differences between providers show up on real flows with logins, redirects, and third-party scripts.

Bottom line

Steel and Hyperbrowser are both reasonable hosted browser runtimes, and the "Steel Hyperbrowser" comparison mostly comes down to how much control you want over the browser layer versus how much managed tooling you want on top. Whichever you choose, insist on a CDP endpoint, tight session lifecycle, and verifiable isolation. If you want hosted Chromium that keeps your agent code portable, start with the documentation and check /pricing for current rates before you scale.