Use Price to Compare Browser Automation Runtimes

If you are evaluating a runtime for AI web agents, the fastest way to use price is as a filter, not a verdict. A headline rate quoted per browser-hour tells you almost nothing until you know what a browser-hour includes, how sessions are metered, and what you pay for outside the meter. This guide shows you how to use price to compare browser automation tools on equal footing, which line items actually drive your bill, and where cheap rates hide expensive failure modes.

Remote Browser runs hosted Chromium sessions that you drive over CDP with Playwright, Puppeteer, or Selenium, with a live viewer, persistent profiles, and configurable browser settings. Current rates and limits live on the pricing page. What follows is how to read any provider's price, including ours, without getting fooled by the number at the top.

Why price alone misleads in browser automation

Browser automation pricing is metered by time, but the unit of time is not standardized. One provider's "browser-hour" may start when the session is created and end when it is explicitly stopped. Another may bill wall-clock time including idle periods while your agent waits on an LLM call. A third may charge per concurrent browser slot regardless of utilization.

That means two providers quoting the same per-hour rate can produce wildly different monthly bills for the same workload. The rate is the visible variable; session lifecycle, concurrency model, and included features are the hidden ones. Use price to narrow the field, then compare the mechanics behind the number.

What a browser-hour should include

Before comparing rates, list what you need from a session. A useful browser-hour covers:

• A real Chromium instance with CDP access, not a screenshot API or a headless-only wrapper that limits what you can automate.
• Session isolation so one agent's cookies, storage, and network state do not leak into another's.
• Persistent profiles when your workflow needs to stay logged in across sessions.
• Proxy and stealth-related browser settings you can configure per session, rather than a fixed global configuration.
• A live viewer so you can debug a stuck agent without replaying logs.
• Usage controls so you can cap spend and concurrency before a runaway loop burns through your budget.

If a provider's rate excludes several of these, the effective price is higher than advertised. You will pay for them in engineering time, in failed tasks, or in a second vendor.

The line items that actually drive your bill

Most hosted browser bills decompose into four variables. Model each one for your workload before you compare rates.

A task that takes 90 seconds of real work but holds a session open for 6 minutes while the LLM reasons is billed for 6 minutes on most providers. That gap, not the per-hour rate, is often the largest cost lever you control. Shortening idle time, closing sessions aggressively, and reusing persistent profiles instead of re-authenticating all reduce billable time without changing providers.

Comparison table: rate versus effective cost

The table below shows how the same workload looks under different billing models. The numbers are illustrative, not quotes from any provider. Substitute your own task volume and durations.

The lesson: a provider at a higher per-hour rate with better session lifecycle controls can be cheaper than a low-rate provider that bills idle time generously. Compare effective cost per completed task, not cost per hour.

How to use price to shortlist providers

Run this sequence before you sign anything.

1. Define a representative task. Pick one workflow your agents actually run, with its real duration distribution, not a best-case demo.
2. Get the billing unit in writing. Ask when the meter starts, when it stops, whether idle time counts, and whether failed sessions are billed.
3. Check concurrency pricing. Some providers charge for reserved slots whether or not you use them. Others bill only active sessions. The right model depends on whether your traffic is spiky or steady.
4. Price the features you need separately. Proxies, persistent profiles, recordings, and stealth settings may be included, metered, or absent. Add them to the effective rate.
5. Run a pilot at realistic volume. A week of production-shaped traffic exposes idle-time and retry costs that a demo never will.

Only after steps 1–5 should you compare headline rates. At that point the comparison is meaningful.

Where cheap rates hide expensive failure modes

A low per-hour rate is not a problem by itself. It becomes one when the runtime forces you to spend elsewhere.

• Session instability. If sessions drop mid-task, every drop is a retry you pay for twice: once for the failed session and once for the replacement. Stability is a cost input.
• Missing CDP fidelity. If the runtime exposes a reduced API, your Playwright or Puppeteer scripts need workarounds. Engineering time is not on the invoice but it is on your budget.
• No persistent profiles. Re-authenticating on every session adds minutes to each task and increases failure surface on login flows.
• Weak isolation. Cross-session leakage forces you to serialize workloads you wanted to parallelize, which raises wall-clock cost even if the meter looks cheap.
• No usage controls. Without caps, a single runaway agent can generate a bill that dwarfs any per-hour savings.

When you evaluate a provider, ask what happens when a session fails, how profiles persist, and what controls exist to stop spend. Those answers matter more than the rate.

Wiring cost control into your agent code

Price decisions are only real if they show up in code. The pattern below connects to a hosted Chromium session over CDP, runs a bounded task, and closes the session explicitly so you are not billed for idle time. It uses Playwright's connectOverCDP, documented in the Playwright CDP guide.

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

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

async function runBoundedTask(
  session: SessionInfo,
  task: (page: Page) => Promise<void>,
  timeoutMs = 120_000
): Promise<void> {
  let browser: Browser | undefined;
  const deadline = setTimeout(() => {
    // Hard stop so a stuck agent cannot hold the meter open.
    browser?.close().catch(() => {});
  }, timeoutMs);

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

    await task(page);
  } finally {
    clearTimeout(deadline);
    // Close the connection; the provider stops billing on session end.
    await browser?.close().catch(() => {});
  }
}

// Usage: wrap every agent task so duration is bounded by construction.
await runBoundedTask(
  { cdpUrl: process.env.CDP_URL!, sessionId: "s-123" },
  async (page) => {
    await page.goto("https://example.com", { waitUntil: "domcontentloaded" });
    await page.getByRole("button", { name: "Sign in" }).click();
  }
);

Two details matter for cost. First, the timeout closes the browser even if the task hangs, which caps the worst-case bill per task. Second, closing the connection at the end of the task, rather than leaving it open for reuse, prevents idle billing. If your workflow benefits from persistent profiles, reuse the profile rather than the live session; see remote browsers for AI agents for how profiles and sessions differ.

Persistent profiles versus fresh sessions: the cost trade-off

Fresh sessions are simple and isolated, but they pay for setup on every task: navigation to the login page, credential entry, and any MFA step your workflow tolerates. Persistent profiles skip that setup, which shortens each session and lowers billable time.

The trade-off is state management. A persistent profile carries cookies and storage forward, which is what you want for logged-in workflows and what you must avoid for tasks that should not share identity. The right answer is usually a mix: persistent profiles for recurring authenticated workflows, fresh sessions for one-off or untrusted tasks. Both are available on Remote Browser, and the documentation covers profile lifecycle and session isolation.

A checklist for price-driven evaluation

Use this list when you compare providers, including Remote Browser.

• [ ] Billing unit defined: start event, stop event, idle treatment, failed-session treatment.
• [ ] Concurrency model understood: reserved slots versus active sessions.
• [ ] CDP access confirmed with your framework (Playwright, Puppeteer, Selenium).
• [ ] Persistent profiles available and priced.
• [ ] Proxy and stealth-related settings configurable per session.
• [ ] Live viewer available for debugging without replaying logs.
• [ ] Usage controls: spend caps, concurrency limits, session timeouts.
• [ ] Pilot run at production-shaped volume for at least one week.
• [ ] Effective cost per completed task calculated, not just cost per hour.

If a provider cannot answer the first two items clearly, the rate is not comparable. Move on.

When to pay more per hour

A higher rate is justified when it removes costs elsewhere. Pay more per hour if the runtime gives you:

• Stable sessions that survive long tasks without dropping.
• Full CDP fidelity so your existing Playwright and Puppeteer code runs unchanged.
• Persistent profiles that cut setup time from every task.
• Configurable browser settings for proxy and stealth-related needs, so you do not run a second vendor for those.
• Usage controls that prevent runaway spend.

Each of these reduces either billable time or engineering time. If the savings exceed the rate premium, the higher rate is the cheaper option. That is the whole point of using price as a decision tool: it forces you to price the whole system, not just the meter.

Start with your workload, then the rate

The practical sequence is: define a representative task, measure its real duration and idle time, price the features you need, then compare rates. Providers that publish clear billing mechanics and expose the controls above make this comparison possible. Providers that quote a rate without those details make it a guess.

Remote Browser publishes current rates and limits on the pricing page, and the documentation covers CDP connection, persistent profiles, and session controls. If you are still choosing a runtime shape, remote browser online and remote web browser walk through the deployment models that affect cost. Use price to shortlist, then verify with a pilot at your real volume.