Per Browser-Hour Pricing: What It Means for AI Agents

# Per Browser-Hour Pricing: What It Means for AI Agents

If you are building AI agents that browse the web, you have likely encountered per browser-hour pricing. It is the dominant billing model for hosted browser infrastructure. Unlike per-request or per-token pricing, a browser-hour charges you for the wall-clock time a browser session is alive and connected, regardless of how many actions you execute inside it.

This model is simple, but it has nuances. Understanding what starts a browser-hour, what pauses it, and how it differs from subscription-based managed browser-hour plans will help you control costs. This guide breaks down the mechanics of browser-hour billing and how Remote Browser fits into that picture.

What Is a Browser-Hour?

A browser-hour is one hour of a live, hosted Chromium session. The clock starts when the browser instance is launched and stops when it is terminated. If you keep a session open for 30 minutes, you are billed for 0.5 browser-hours. If you keep it open for 90 minutes, you are billed for 1.5 browser-hours.

This is fundamentally different from API-based pricing where you pay per function call or per token. In a browser-hour model, the cost is tied to resource reservation. You are renting a slice of a Chromium process, its memory, and its network connection.

What Starts a Browser-Hour?

A browser-hour starts when a new session is created. In the Remote Browser API, this happens when you send a request to create a session. The session is a full Chromium instance with a unique ID. It is not a lightweight HTTP request handler.

Common triggers include:

• A POST /v1/sessions call from your code.
• A Playwright or Puppeteer script that connects to a hosted browser endpoint.
• A CDP (Chrome DevTools Protocol) connection initiated by an automation framework.

Once the session is live, the clock runs. It does not pause when your agent is idle, waiting for a human to respond, or processing a large language model (LLM) response. The browser is still allocated and consuming resources.

What Stops the Clock?

The clock stops when the session is explicitly closed. In Remote Browser, you can close a session via the API or let it expire based on your configured timeout. If your agent crashes without closing the session, the session will eventually time out, but you are billed for the time until that timeout occurs.

This is why session lifecycle management is critical. A common mistake is creating a new session for every task without closing it. Over a day, this can result in dozens of orphaned sessions running until their timeout, inflating your bill.

Per Browser-Hour vs. Browser-Hour Subscription

There are two primary ways to buy browser-hours: pay-as-you-go and subscription plans.

The tradeoff is straightforward. Pay-as-you-go offers flexibility but can be more expensive per hour if you have high volume. Subscriptions offer a lower effective rate but require you to estimate your usage accurately.

Remote Browser offers both models. For current rates and subscription tiers, check the pricing page. The key point is that you are always paying for the same underlying resource: a managed browser-hour.

Why Per Browser-Hour Is the Right Unit for AI Agents

AI agents are not like traditional API consumers. They do not send a single request and get a response. They navigate multi-step workflows, fill forms, click buttons, and wait for pages to render. This is inherently time-based.

Consider a typical agent task: logging into a portal, extracting a report, and emailing it. The agent might make 20 HTTP requests, but the browser session is alive for 4 minutes. Per-request pricing would be cheap, but it would not reflect the cost of maintaining a live browser with a persistent profile, cookies, and JavaScript state.

Per browser-hour aligns cost with resource consumption. It is the same logic that drives cloud VM pricing. You pay for the time the machine is running, not the number of commands you execute.

The "Starts Browser-Hour" Problem

One of the biggest cost leaks in browser automation is the "starts browser-hour" problem. This happens when your code creates a new session for every small task instead of reusing an existing session.

For example, if you have a loop that processes 100 URLs, and you create a new session for each URL, you are paying for 100 session startups. Each startup might take 2-3 seconds, but the session stays alive for the duration of the task plus any idle timeout. If your timeout is 5 minutes, you could be paying for 500 minutes of browser time for a task that should have taken 20 minutes in a single session.

The fix is to reuse sessions. In Remote Browser, you can keep a session alive and navigate to multiple URLs within it. This is the difference between a "browser-hour" and a "task-hour." A well-designed agent should aim for the latter.

Managed Browser-Hour: What You Get for the Price

When you pay for a managed browser-hour, you are not just paying for a raw Chromium process. You are paying for the infrastructure that makes it usable in production.

Here is what a managed browser-hour typically includes:

• Hosted Chromium: No local installation, no version drift, no dependency conflicts.
• CDP access: Full control over the browser via the Chrome DevTools Protocol.
• Playwright/Puppeteer/Selenium compatibility: Use your existing automation code without rewriting it.
• Persistent profiles: Save cookies, localStorage, and session state between sessions.
• Live viewer: Watch the browser in real time to debug agent behavior.
• Session isolation: Each session is a separate browser instance, so one agent cannot interfere with another.
• Configurable browser settings: Adjust viewport, user agent, and other parameters per session.

This is the difference between a "browser-hour" and a "managed browser-hour." The former is a raw VM. The latter is a purpose-built runtime for automation.

How to Estimate Your Browser-Hour Usage

Estimating your browser-hour usage is essential for budgeting. Here is a practical approach.

Step 1: Measure Average Session Duration

Run your agent on a sample of tasks and measure the average session duration. Include the time from session creation to session close. Do not include the time your code spends waiting for an LLM response if the browser is idle.

Step 2: Calculate Sessions Per Day

Estimate how many sessions you will run per day. This is not the same as tasks. If you reuse a session for multiple tasks, you will have fewer sessions.

Step 3: Multiply and Add Overhead

Multiply average session duration by sessions per day. Then add a buffer for failed sessions, retries, and orphaned sessions that time out. A 10-20% buffer is reasonable for production.

For example:

• Average session duration: 5 minutes (0.083 hours)
• Sessions per day: 200
• Raw usage: 16.6 browser-hours per day
• With 20% overhead: ~20 browser-hours per day
• Monthly total: ~600 browser-hours

This gives you a concrete number to compare against subscription tiers or pay-as-you-go rates.

Code Example: Managing Session Lifecycle in TypeScript

The most important practice for controlling browser-hour costs is explicit session management. Here is a TypeScript example using Playwright with a CDP connection to a Remote Browser session.

import { chromium } from 'playwright-core';

async function runTask(sessionUrl: string, task: (page: any) => Promise<void>) {
  // Connect to an existing Remote Browser session via CDP
  const browser = await chromium.connectOverCDP(sessionUrl);
  const context = browser.contexts()[0];
  const page = context.pages()[0] || await context.newPage();

  try {
    await task(page);
  } finally {
    // Do NOT close the browser here if you want to reuse the session.
    // Instead, navigate to a blank page or leave it idle.
    // The session will be closed via the API or timeout.
    await page.goto('about:blank');
  }
}

async function main() {
  // Assume you have a session ID from the Remote Browser API
  const sessionId = 'your-session-id';
  const sessionUrl = `wss://remote-browser.dev/v1/sessions/${sessionId}/cdp`;

  // Reuse the same session for multiple tasks
  await runTask(sessionUrl, async (page) => {
    await page.goto('https://example.com');
    await page.click('button#start');
    // ... task logic
  });

  await runTask(sessionUrl, async (page) => {
    await page.goto('https://example.org');
    // ... another task
  });

  // When done, close the session via the Remote Browser API
  // This stops the browser-hour clock.
  await fetch(`https://remote-browser.dev/v1/sessions/${sessionId}`, {
    method: 'DELETE',
  });
}

main().catch(console.error);

Notice the finally block. It does not close the browser. It navigates to a blank page. This allows the session to be reused for the next task. The session is only closed explicitly at the end of the batch.

This pattern can reduce your browser-hour consumption by 5-10x compared to creating a new session per task.

The Browserbench Suite and Browser-Hour Efficiency

If you are evaluating browser automation performance, you may have seen the browserbench suite. This is a set of benchmarks designed to measure browser rendering and JavaScript performance. While it is useful for comparing browser engines, it is not directly a measure of browser-hour efficiency.

Browser-hour efficiency is about how much work you can complete within a single hour of browser time. It is a function of:

• Session reuse (avoiding the "starts browser-hour" problem).
• Network latency (faster pages mean shorter sessions).
• Agent logic (fewer wasted steps mean less time per task).

The browserbench suite can help you measure raw browser speed, but it will not tell you how well your agent uses that speed. For that, you need to instrument your sessions and track time-to-task-completion.

Browser-Use API v4 Overview and Browser-Hour Billing

If you are using the browser-use library, you may be familiar with its API. The browser-use api-v4-overview describes the interface for connecting agents to browser runtimes. In the context of per browser-hour pricing, the key takeaway is that the API does not change the billing model.

Whether you use browser-use, Playwright, or raw CDP, you are still consuming browser-hours. The API is just the interface. The cost is determined by how long the underlying Chromium session is alive.

This is why Remote Browser is designed to be API-agnostic. You can connect via Playwright, Puppeteer, Selenium, or direct CDP. The billing is always per browser-hour, not per API call.

How Remote Browser Handles Browser-Hour Billing

Remote Browser uses a transparent per browser-hour model. Here is how it works in practice:

• Session creation: A browser-hour starts when you create a session.
• Session reuse: You can keep a session alive and reuse it for multiple tasks.
• Session termination: You can close a session via the API, or it will time out based on your configuration.
• Usage controls: You can set limits on session duration and concurrency to prevent runaway costs.

For specific rates and subscription options, refer to the pricing page. The goal is to give you predictable costs without requiring you to guess your usage months in advance.

Practical Tips for Reducing Browser-Hour Costs

Here are actionable strategies to keep your browser-hour consumption low.

1. Reuse Sessions for Sequential Tasks

If your agent processes a queue of URLs, use one session for the entire queue. Do not create a new session per URL.

2. Set Aggressive Idle Timeouts

If a session is idle for more than 30 seconds, it is likely stuck or waiting for input. Configure a short idle timeout to close it automatically.

3. Close Sessions in finally Blocks

Always close sessions in a finally block in your code. This ensures they are closed even if your agent throws an error.

4. Use Persistent Profiles for Repeat Tasks

If your agent logs into the same site repeatedly, use a persistent profile. This avoids the time and cost of re-authenticating on every session.

5. Monitor Session Count

Use the Remote Browser dashboard to monitor active sessions. If you see a spike, investigate immediately. A single buggy loop can create dozens of orphaned sessions.

The Bottom Line on Per Browser-Hour

Per browser-hour pricing is the fairest and most transparent model for hosted browser automation. It aligns cost with actual resource consumption. The key to controlling costs is not negotiating a lower rate; it is managing your session lifecycle efficiently.

By reusing sessions, setting timeouts, and closing sessions explicitly, you can reduce your browser-hour consumption by an order of magnitude. This is more impactful than any pricing discount.

If you are ready to start, read the documentation to understand session management, or explore how remote browsers for AI agents fit into your architecture. For a deeper dive into the runtime, check out the remote web browser guide.

For more context on how browser automation frameworks interact with hosted runtimes, the Playwright CDP documentation is a useful reference.

The bottom line: per browser-hour is the unit of work in the hosted browser world. Learn to use it well, and your automation costs will stay predictable and low.