Browser-Hour Subscription: How Remote Browser Pricing Works

# Browser-Hour Subscription: How Remote Browser Pricing Works

A browser-hour subscription is the most predictable way to pay for hosted browser automation. If you're building AI agents that need to interact with the web, you've likely hit the same wall: local browser automation is fragile, slow, and hard to scale. The solution is a hosted browser runtime, and the pricing model that makes it predictable is the browser-hour subscription. This article explains what a browser-hour actually means, how Remote Browser structures its managed browser-hour offering, and how to estimate your usage before you commit.

What Is a Browser-Hour?

A browser-hour is a unit of compute time for a hosted Chromium session. One browser-hour equals one active browser session running for 60 minutes. If you run two sessions for 30 minutes each, that's one browser-hour. If you run one session for 90 minutes, that's 1.5 browser-hours.

This metering model is common in cloud infrastructure because it aligns cost with actual resource consumption. You're not paying for idle VMs or local hardware; you're paying for the exact time your browser session is alive and processing requests.

Remote Browser uses this model for its managed browser-hour plans. Instead of guessing how many concurrent sessions you'll need, you pay for what you use. This is particularly useful for AI agents that run intermittently—a web scraping task might need 10 minutes of browser time, while a complex multi-step workflow might need several hours.

Why a Browser-Hour Subscription Beats Per-Request Pricing

Many browser automation APIs charge per request or per action. That sounds simple, but it creates a mismatch: a single "request" can involve dozens of page loads, network calls, and DOM manipulations. The cost is unpredictable, and you're penalized for complex workflows.

A browser-hour subscription flattens that variability. Whether your agent performs 10 actions or 1,000 actions in an hour, the cost is the same. This makes budgeting straightforward and encourages efficient use of the browser session.

Here's a quick comparison:

Remote Browser's browser-hour subscription falls into the third category. It's designed for workloads where the browser is the primary compute resource, not a side effect of an API call.

Inside a Managed Browser-Hour

When you purchase a browser-hour subscription from Remote Browser, you're not just getting a timer. Each hour includes access to a full hosted Chromium runtime with the following capabilities:

• CDP (Chrome DevTools Protocol) access: Full control over the browser, including navigation, DOM manipulation, network interception, and performance profiling.
• Playwright, Puppeteer, and Selenium compatibility: Use your existing automation scripts without rewriting them. The hosted browser speaks the same protocols as local Chromium.
• Persistent profiles: Save cookies, localStorage, and session state between browser-hours. This is critical for workflows that require login or maintain user context.
• Live viewer: Watch the browser session in real time from your dashboard. Useful for debugging and for human-in-the-loop approval steps.
• Configurable browser settings: Adjust viewport, user agent, and other parameters to match your target environment. This includes proxy settings for IP rotation, which we'll discuss below.
• Session isolation: Each browser-hour runs in a sandboxed environment. No cross-contamination between tasks, even if they run concurrently.

These features are bundled into the browser-hour price. You don't pay extra for CDP access or for using Playwright instead of Puppeteer. The subscription covers the runtime, not the integration layer.

Estimating Your Browser-Hour Usage

The hardest part of any subscription model is predicting usage. Here's a practical framework for estimating your browser-hour consumption.

Step 1: Profile Your Workload

Start by categorizing your automation tasks:

• Short tasks (1-5 minutes): Form submissions, single-page scrapes, quick API checks.
• Medium tasks (5-30 minutes): Multi-page workflows, data extraction from several sources, login flows.
• Long tasks (30+ minutes): Complex agent loops, monitoring tasks, batch processing with retries.

Step 2: Calculate Average Session Duration

Run a few representative tasks locally and time them. Don't include setup or teardown time—just the active browser time. Average these durations to get your baseline.

Step 3: Factor in Concurrency

If you run tasks sequentially, your browser-hour usage equals the sum of all task durations. If you run tasks in parallel, you need to multiply by the number of concurrent sessions.

For example:

• 100 short tasks × 3 minutes each = 300 minutes = 5 browser-hours.
• 20 medium tasks × 15 minutes each = 300 minutes = 5 browser-hours.
• 10 long tasks × 60 minutes each = 600 minutes = 10 browser-hours.

Step 4: Add a Buffer

AI agents are not deterministic. Network timeouts, retries, and unexpected page structures can extend session time. Add a 20-30% buffer to your estimate.

The Role of Proxies in Browser-Hour Consumption

One factor that can inflate your browser-hour usage is IP blocking. If your target site detects and blocks your requests, your agent will retry, consume more time, and potentially fail entirely.

Remote Browser offers configurable browser settings, including proxy integration. By routing your browser session through a residential or datacenter proxy, you reduce the likelihood of detection. This is not about "stealth" in the sense of evading security—it's about ensuring your legitimate automation tasks complete without interruption.

The key insight: a proxy that works reduces your browser-hour consumption because tasks complete on the first attempt. A proxy that fails increases consumption because of retries. Choose your proxy provider carefully, and test it against your target sites before committing to a large browser-hour plan.

For more on this, see our post on remote browsers for AI agents, which covers IP quality and session management in depth.

Browser-Hour Subscription vs. Pay-As-You-Go

Remote Browser offers both subscription and pay-as-you-go options. Here's how to decide which fits your needs:

If you're running a production AI agent that operates daily, a browser-hour subscription will almost certainly be cheaper. If you're prototyping or running occasional tests, pay-as-you-go avoids the overhead of managing a subscription.

For current pricing details, check the Remote Browser pricing page. We don't publish fixed numbers here because rates can change based on infrastructure costs and market conditions.

Code Example: Connecting to a Browser-Hour Session

Once you have a browser-hour subscription, connecting to a session is straightforward. Here's a TypeScript example using Playwright with CDP:

import { chromium } from 'playwright';

async function connectToRemoteBrowser() {
  // The CDP endpoint is provided in your Remote Browser dashboard
  const browser = await chromium.connectOverCDP('wss://remote-browser.dev/cdp/session-abc123');
  
  const context = browser.contexts()[0];
  const page = context.pages()[0] || await context.newPage();
  
  // Navigate to a target site
  await page.goto('https://example.com', { waitUntil: 'networkidle' });
  
  // Extract data
  const title = await page.title();
  console.log(`Page title: ${title}`);
  
  // Take a screenshot for verification
  await page.screenshot({ path: 'session-check.png' });
  
  // The session stays alive until you close it or the browser-hour expires
  await browser.close();
}

connectToRemoteBrowser().catch(console.error);

This code connects to an existing browser session via CDP, performs a navigation, and extracts data. The session is billed against your browser-hour subscription from the moment you connect until you close it or the hour expires.

Session Browser-Hour: Managing Long-Running Tasks

Some AI agent workloads run for hours. Think of a monitoring agent that checks a dashboard every 5 minutes, or a data pipeline that processes thousands of pages overnight.

For these cases, Remote Browser supports session browser-hour billing. You start a session, and it stays alive until you explicitly terminate it or until your subscription limit is reached. This is different from per-request APIs, where each action is billed separately.

The practical implication: you can write agent loops that don't worry about reconnecting. The browser stays warm, cookies stay valid, and your code stays simple.

Here's a pattern for a long-running task:

// This runs for the duration of the browser-hour
async function monitorDashboard(page: any, intervalMs: number) {
  while (true) {
    await page.goto('https://dashboard.example.com');
    const status = await page.textContent('.status-indicator');
    console.log(`Status: ${status}`);
    
    // Check if we should stop
    if (status === 'ERROR') {
      await page.screenshot({ path: 'error-state.png' });
      break;
    }
    
    await new Promise(resolve => setTimeout(resolve, intervalMs));
  }
}

This loop runs within a single browser session, consuming one browser-hour for each hour of wall-clock time. No reconnection logic, no session management overhead.

Browserbench Suite: Measuring Your Actual Usage

Before you commit to a browser-hour subscription, it's wise to benchmark your workload. Remote Browser's browserbench suite helps you measure:

• Time to first byte: How quickly the browser loads a target page.
• Navigation throughput: How many page loads you can complete in an hour.
• Session stability: How long a session stays alive without crashes or memory leaks.
• Resource consumption: CPU and memory usage per session, which affects cost.

Running a benchmark suite before scaling your agent gives you data to right-size your subscription. You might find that your workload is more efficient than expected, allowing a smaller plan. Or you might discover that retries are eating 40% of your browser-hours, indicating a proxy or configuration issue.

For a deeper dive, see our browserbench task guide, which walks through setting up and interpreting these benchmarks.

Browser Use Profiles: Matching the Runtime to the Task

Not all browser-hours are equal. A session configured for a simple GET request uses fewer resources than one rendering a complex JavaScript-heavy SPA. Remote Browser supports browser use profiles, which let you match the runtime configuration to the task.

Common profiles include:

• Lightweight: Disables images, JavaScript, and other heavy features. Best for API-like interactions and simple scrapes.
• Standard: Full Chromium with default settings. Best for general web automation.
• Heavy: Enables all features, including WebGL, audio, and video. Best for testing complex web applications.

Choosing the right profile reduces your browser-hour consumption because you're not paying for resources you don't need. A lightweight profile might complete a task in 30% less time than a heavy profile, directly reducing your subscription usage.

Internal Links and Further Reading

To get the most out of your browser-hour subscription, we recommend reading:

• Remote Browser Online: Run Real Chromium Without Managing Chrome — Covers the basics of hosted Chromium and why it's the right choice for production workloads.
• Remote Web Browser: The Practical Runtime for Browser Automation — A guide to choosing between local and remote browser runtimes.
• Remote Control Browser: When Code and Agents Need to Drive the Web — Focuses on the control plane and API surface.

For technical documentation, visit the Remote Browser documentation for API references, SDKs, and integration guides.

External Reference: CDP and Playwright

If you're new to CDP, the Chrome DevTools Protocol documentation is the authoritative source. Playwright's CDP support documentation explains how to connect to existing browser sessions, which is the foundation of Remote Browser's session model.

Final Thoughts on Browser-Hour Subscriptions

A browser-hour subscription is the right pricing model for AI agents that treat the browser as a compute resource. It's predictable, scalable, and aligns cost with actual usage. Remote Browser's managed browser-hour offering adds the infrastructure you need—CDP access, persistent profiles, live debugging, and proxy support—without the operational overhead of running your own browser farm.

The key to making it work is measurement. Profile your workload, benchmark your sessions, and choose the right browser use profile. With those data points, you can select a subscription that fits your budget and scales with your agent's success.

For the latest pricing and plan details, visit the Remote Browser pricing page. Your browser-hour subscription is the foundation for reliable, production-grade browser automation—make sure it's sized correctly.