Hyperbrowser Price: What You Pay and How to Compare

# Hyperbrowser Price: What You Pay and How to Compare

If you are evaluating Hyperbrowser price before committing an agent workload to it, the useful question is not "what is the sticker number" but "what does a finished task cost me." Hosted browser providers bill in browser-hours, and the number on the pricing page is only one input. Session startup time, idle time, retries, concurrency caps, and whether you pay for a subscription you do not fully use all move the real number. This guide breaks down how Hyperbrowser price is structured, what actually drives your bill, and how to compare it against Remote Browser and other hosted Chromium runtimes without guessing. For current Remote Browser rates, check /pricing; for the runtime itself, see the /documentation.

How Hyperbrowser price is structured

Hyperbrowser, like most hosted browser providers, sells access to remote Chromium sessions. The billing model generally has three components:

• A per-browser-hour rate. You pay for wall-clock time a session exists, not CPU cycles or tokens. A session that sits idle still bills.
• A plan or subscription tier. Many providers bundle a monthly fee with an included hour allotment and a concurrency ceiling, then charge an overage rate beyond that.
• Add-ons. Proxy configurations, stealth settings, CAPTCHA handling, and longer session retention are commonly metered or gated by tier.

The exact Hyperbrowser price at any given moment depends on the plan you pick and the add-ons you enable. Because published rates change, treat any specific figure you read — including in this article — as a snapshot and confirm it on the provider's own pricing page before you model a budget. The same discipline applies to Remote Browser: we point you to /pricing rather than hard-coding numbers that will drift.

What matters more than the headline rate is the unit you are actually buying. A "browser-hour" is not a standardized commodity across providers. One vendor may count from session creation to explicit termination; another may include a grace period; another may bill a minimum increment per session. Two providers quoting the same per-hour rate can produce very different monthly invoices for the same workload.

What actually drives your Hyperbrowser bill

The per-hour rate is a multiplier. The hours are the variable you control. Here is where they go.

Session lifetime vs. useful work

An agent session typically has three phases: startup (browser launch, profile load, proxy handshake), task execution (navigation, clicks, extraction), and teardown. Only the middle phase produces value. Startup and teardown are overhead you still pay for. Providers that pre-warm browsers or pool sessions can shrink startup, but that optimization is not universal. If your agent spins up a fresh session per task and each task takes 40 seconds of real work inside a 90-second session, you are paying roughly double the useful rate.

Idle time between steps

LLM-driven agents are not continuously clicking. They reason, call a model, wait for a response, then act. A browser session held open while the model thinks is billing the whole time. Long reasoning chains on complex tasks can leave a browser idle for a large fraction of its life. This is the single biggest hidden cost in agent workloads, and it is why session reuse and persistent profiles matter for cost as much as for reliability.

Retries and failures

A failed task that gets retried doubles its browser-hours. CAPTCHAs, bot detection, flaky selectors, and timeouts all convert directly into billed time. A runtime with better stealth and session stability can be cheaper per completed task even at a higher hourly rate, because it fails less. This is the core trade-off: optimize for cost per successful task, not cost per hour.

Concurrency and plan fit

Subscription tiers bundle concurrency limits. If your peak needs 40 parallel sessions but your plan caps at 25, you either queue (slower, but no extra browser-hours) or upgrade (higher fixed cost). Under-provisioning concurrency does not raise your hourly rate, but it can blow your latency SLOs. Over-provisioning wastes the subscription delta. Model your p95 concurrency, not your average.

Add-ons

Proxy configurations and stealth settings are frequently the difference between a task succeeding and failing on a protected site. They are also frequently billed separately. A cheap base rate plus mandatory proxy add-ons can exceed a higher all-in rate. Price the configuration you will actually run, not the entry tier.

Hyperbrowser vs. Remote Browser: a comparison framework

Rather than assert a winner, here is the framework to compare any two hosted runtimes on the dimensions that move cost and reliability. Fill in the current numbers from each provider's pricing page.

Remote Browser is built around hosted Chromium sessions with CDP access, Playwright/Puppeteer/Selenium compatibility, a live viewer, persistent profiles, configurable browser settings, session isolation, and usage controls. Those features exist to reduce the hours you burn on overhead and retries — which is the lever that actually changes your bill. Current rates live at /pricing.

The cost model most teams get wrong

Teams new to hosted browsers usually estimate cost as tasks × average_task_seconds × hourly_rate. That formula ignores the three multipliers above: startup overhead, idle reasoning time, and retry rate. A more honest model:

effective_hours = tasks × (startup + work + idle + teardown) × (1 + retry_rate) / 3600
monthly_cost    = effective_hours × hourly_rate + fixed_plan_fee + addon_costs

Run this with your real numbers. A workload with a 30% retry rate and 50% idle time can cost three to four times a naive estimate. This is why comparing Hyperbrowser price to another provider on the per-hour line alone is misleading — the retry and idle multipliers differ by runtime.

Two levers shrink those multipliers regardless of provider:

1. Reuse sessions and persistent profiles. Log in once, keep cookies and storage state, and skip re-authentication on every task. Remote Browser's persistent profiles are designed for exactly this; see /blog/remote-browser-for-ai-agents for how agent workloads use them.
2. Close sessions deterministically. An agent that forgets to terminate a session keeps billing until a timeout. Explicit teardown in your orchestration layer is free money.

Wiring an agent to a hosted runtime over CDP

The practical reason to care about CDP compatibility is portability: if your agent speaks CDP, switching providers is a connection-string change, not a rewrite. That keeps pricing pressure on vendors and lets you benchmark cost per task on your own workload. Here is a TypeScript example using Playwright's connectOverCDP against a hosted Chromium endpoint. Replace the endpoint and headers with the values from your provider's session API.

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

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

async function openSession(): Promise<SessionInfo> {
  // Call your provider's session-creation API here.
  // Remote Browser exposes session creation via its API; see /documentation.
  const res = await fetch("https://api.example-provider.dev/v1/sessions", {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
      Authorization: `Bearer ${process.env.BROWSER_API_KEY}`,
    },
    body: JSON.stringify({ profile: "checkout-agent", proxy: "residential" }),
  });
  if (!res.ok) throw new Error(`session create failed: ${res.status}`);
  const data = await res.json();
  return { cdpUrl: data.cdpUrl, sessionId: data.id };
}

async function runTask(): Promise<void> {
  const { cdpUrl, sessionId } = await openSession();
  let browser: Browser | undefined;
  try {
    browser = await chromium.connectOverCDP(cdpUrl);
    const context = browser.contexts()[0] ?? (await browser.newContext());
    const page: Page = context.pages()[0] ?? (await context.newPage());

    await page.goto("https://example.com/account", { waitUntil: "domcontentloaded" });
    await page.getByRole("button", { name: "Sign in" }).click();
    // ...agent-driven steps...
  } finally {
    // Always tear down: an open session keeps billing.
    await browser?.close();
    await fetch(`https://api.example-provider.dev/v1/sessions/${sessionId}`, {
      method: "DELETE",
      headers: { Authorization: `Bearer ${process.env.BROWSER_API_KEY}` },
    });
  }
}

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

Two details matter for cost. First, the finally block guarantees teardown even on failure — a thrown error should not leave a session billing. Second, connectOverCDP attaches to an already-running browser, so you are not paying for a local launch. The Playwright documentation on connectOverCDP and the Chrome DevTools Protocol spec are the authoritative references for what the connection exposes.

If you are still deciding between a local browser and a hosted one, /blog/remote-browser-online covers the operational differences, and /blog/remote-web-browser walks through the runtime model.

Production criteria beyond price

When you compare Hyperbrowser price with any alternative, score these before you sign:

• Full CDP access. Partial or wrapped APIs lock you into one SDK. Full CDP means Playwright, Puppeteer, Selenium, and raw protocol clients all work.
• Session isolation. One tenant's cookies and storage must not leak into another's. This is a security requirement, not a feature.
• Persistent profiles. Re-login is the most expensive overhead in agent workloads. Profiles that survive across sessions cut it.
• Live viewer and recordings. Debugging a failed agent run without a viewer means re-running it — and paying twice.
• Configurable browser settings. Proxy, locale, timezone, and viewport settings that you control let you match the sites you target. Be precise about what a provider actually supports rather than assuming fingerprint-level stealth.
• Usage controls. Per-key budgets, concurrency limits, and alerts prevent a runaway agent from producing a runaway invoice.
• Predictable teardown. Sessions must terminate on timeout and on explicit close, and you should be able to see which sessions are live.

Remote Browser provides these as part of the runtime; the specifics are in /documentation. For teams that need to drive sessions interactively during development, /blog/remote-control-browser explains the control model.

How to decide

Hyperbrowser price is one input into a decision that should be driven by cost per successful task. The sequence that works:

1. Instrument your workload. Measure startup, work, idle, and teardown per task, plus your retry rate. You cannot compare providers without these.
2. Price the configuration you will run. Include proxies, stealth, and the concurrency tier that covers your p95.
3. Run a bake-off on real tasks. Same agent, same tasks, two runtimes. Compare completed tasks per dollar, not dollars per hour.
4. Check the exit cost. If the runtime speaks CDP, switching later is cheap. If it does not, the lock-in is part of the price.

The cheapest per-hour rate is rarely the cheapest per task once retries and idle time are counted. Pick the runtime that finishes your tasks with the fewest wasted browser-hours, then negotiate or right-size the plan around that. Start with the current numbers at /pricing and the connection details at /documentation, and benchmark against your own workload before you commit.