Managed Browser-Hour: The Metered Runtime for AI Agents

When you run browser automation in production, the unit that matters is the managed browser-hour. It is the metered cost of keeping a hosted Chromium instance alive while an AI agent or test harness executes. Unlike per-request APIs that hide browser state, a managed browser-hour gives you a real browser session with full DevTools access, persistent profiles, and configurable network settings—billed by the time the session is active.

Remote Browser provides this runtime as a managed service. You get a hosted Chromium session exposed over the Chrome DevTools Protocol (CDP), compatible with Playwright, Puppeteer, and Selenium. You pay for the time the browser is running, not for the number of API calls or tokens. This model is predictable, cost-effective, and aligns directly with how AI agents actually consume browser resources.

Why a Managed Browser-Hour Matters

Most AI web agents are not simple HTTP clients. They navigate, click, fill forms, wait for network responses, and sometimes need to keep state across multiple steps. A managed browser-hour covers all of that. The browser is alive, executing JavaScript, rendering pages, and maintaining session state. You are not paying per action; you are paying for the infrastructure that makes those actions possible.

This is a fundamental difference from serverless functions or pure HTTP APIs. Those models are stateless and often require you to re-authenticate or re-render on every call. A managed browser-hour keeps the browser warm, so the agent can move from page to page without losing context.

For teams building browser-use agents, this metering model is the difference between a prototype and a production system. You can estimate costs based on session duration, not on unpredictable token usage or request spikes.

How Remote Browser Meters Time

Remote Browser meters time at the session level. When you start a browser session, the clock starts. When you close it, the clock stops. The total time across all sessions in a billing period is your total browser-hour usage.

The metering is granular enough for short tasks and long-running agents alike. A quick form-filling task might take 0.02 browser-hours. A 24/7 monitoring agent might consume 720 browser-hours in a month. The pricing page at /pricing shows current rates and any volume discounts.

What you are paying for includes:

• A dedicated Chromium process running in a managed environment.
• Full CDP access for debugging, screenshots, and network inspection.
• Persistent profile storage so cookies and local storage survive across sessions.
• Configurable browser settings for proxies, user agents, and viewport size.
• Session isolation so one agent's activity does not affect another's.

Managed Browser-Hour vs. Per-Request Pricing

The table below compares the managed browser-hour model with typical per-request or per-token pricing models used by other browser automation services.

Feature	Managed Browser-Hour	Per-Request / Per-Token
State persistence	Full browser state, cookies, and local storage	Stateless; re-authentication often required
Cost predictability	Based on session duration; easy to estimate	Based on action count; can spike with complex tasks
Debugging	Live viewer and CDP access for real-time inspection	Limited to API responses and logs
Long-running tasks	Native support; browser stays alive	Timeouts and cold starts are common
Session isolation	Dedicated browser per session	Shared infrastructure; isolation varies
Network control	Configurable proxies and IP settings	Usually fixed or limited

For AI agents that need to interact with dynamic web apps, the managed browser-hour model is almost always more cost-effective. A single complex task might require dozens of API calls in a per-request model, but only a few minutes of browser time in a metered model.

The Technical Foundation: CDP and Playwright

Remote Browser exposes each managed browser-hour session over CDP. This is the same protocol that Chrome DevTools uses, and it is the standard for browser automation. Playwright and Puppeteer both support connecting to a browser over CDP, which means you can use your existing code with minimal changes.

Here is a TypeScript example using Playwright to connect to a Remote Browser session:

import { chromium } from 'playwright';

async function main() {
  // Connect to a Remote Browser session via CDP
  const browser = await chromium.connectOverCDP('wss://remote-browser.dev/cdp/session_abc123');

  // Get the default context and page
  const context = browser.contexts()[0];
  const page = context.pages()[0] || await context.newPage();

  // Navigate and interact with a dynamic site
  await page.goto('https://example.com/login');
  await page.fill('#username', 'agent-user');
  await page.fill('#password', 'secure-password');
  await page.click('button[type="submit"]');

  // Wait for the dashboard to load
  await page.waitForSelector('.dashboard');

  // Extract data or take a screenshot
  const title = await page.title();
  console.log(`Logged in. Page title: ${title}`);

  // Close the session to stop the browser-hour meter
  await browser.close();
}

main().catch(console.error);

The code above connects to a live session, performs a login flow, and closes the browser. The time between connectOverCDP and browser.close() is what counts toward your managed browser-hour usage.

For more details on the CDP connection string and session management, see the documentation.

Persistent Profiles and Session Isolation

A managed browser-hour is not just a blank Chromium instance. Remote Browser supports persistent profiles, which means cookies, localStorage, and IndexedDB survive across sessions. This is critical for agents that need to stay logged in or maintain state over multiple runs.

Session isolation is also built in. Each browser session runs in its own isolated environment. One agent's activity cannot affect another's, even if they are running concurrently. This is essential for production workloads where you might have multiple agents working on different tasks simultaneously.

The combination of persistent profiles and session isolation means you can run long-lived agents that maintain state without worrying about cross-contamination.

Configurable Browser Settings

Remote Browser allows you to configure the browser environment to match your use case. This includes:

• Proxy settings: Route traffic through specific IPs or regions.
• User agent: Override the default user agent string.
• Viewport size: Set the viewport to match a specific device.
• Locale and timezone: Simulate users in different regions.
• Geolocation: Override the browser's reported location.

These settings are applied at the session level and are part of what you get with a managed browser-hour. They are particularly useful for AI agents that need to test region-specific content or avoid bot detection.

For a deeper dive into how these settings work, see our post on remote control browser capabilities.

Cost Control and Usage Limits

One of the advantages of the managed browser-hour model is that you can set hard limits on usage. Remote Browser provides usage controls that let you cap the number of concurrent sessions or the total browser-hours per day. This prevents runaway costs from buggy agents or unexpected spikes in workload.

You can also monitor usage in real time through the dashboard. This gives you visibility into which sessions are consuming the most time and whether any agents are stuck in loops.

For teams that need to plan capacity, the browser-hour subscription post explains how to align your subscription with expected usage.

When a Managed Browser-Hour Is the Right Choice

The managed browser-hour model is ideal for:

• AI web agents that need to interact with complex, JavaScript-heavy sites.
• Test harnesses that require a real browser environment with full DevTools access.
• Data collection tasks that need to maintain session state across multiple pages.
• Monitoring agents that run continuously and need a stable, always-on browser.

It is less ideal for simple, stateless HTTP requests. If you only need to fetch a static page or call a REST API, a managed browser-hour is overkill. But for anything that requires a real browser, it is the most practical and cost-effective option.

Comparing to Local Browser Setup

Running a local browser for automation is possible, but it comes with hidden costs. You need to manage the Chromium installation, keep it updated, handle crashes, and ensure the environment is consistent across machines. For a single developer, this is manageable. For a team running multiple agents in production, it becomes a maintenance burden.

A managed browser-hour shifts that burden to the provider. You get a consistent, up-to-date Chromium runtime without any local setup. The AI browser automation at scale post covers this trade-off in more detail.

The Role of CDP in Managed Browsers

CDP is the protocol that makes managed browser-hours so powerful. It gives you low-level access to the browser, including network interception, performance metrics, and JavaScript execution. This is the same protocol that Chrome DevTools uses, so it is battle-tested and well-documented.

For teams building custom automation, CDP access means you are not limited to the high-level APIs of Playwright or Puppeteer. You can drop down to raw CDP commands when you need fine-grained control. The Chrome DevTools Protocol documentation is a good reference for what is possible.

Getting Started with Managed Browser-Hours

To start using managed browser-hours, you need an API key and a way to create sessions. The Remote Browser API is straightforward: you create a session, get a CDP endpoint, and connect with your preferred automation library.

Here is a high-level flow:

1. Create a session via the API or dashboard.
2. Receive a CDP WebSocket URL.
3. Connect using Playwright, Puppeteer, or a raw CDP client.
4. Execute your automation logic.
5. Close the session to stop the meter.

The hosted browser API post walks through this flow in detail.

Pricing Transparency

Remote Browser publishes its pricing on the /pricing page. The rate is per browser-hour, and there are no hidden fees. You pay for the time the browser is running, and you can stop any session at any time.

For teams with predictable usage, the subscription model offers a fixed monthly cost. For teams with variable usage, the pay-as-you-go model is more flexible. The per browser-hour pricing post explains the differences.

Conclusion

A managed browser-hour is the right unit of measure for AI agents and browser automation in production. It gives you a real, stateful browser environment with full CDP access, persistent profiles, and configurable settings—all metered by the time the session is active.

Remote Browser provides this runtime as a managed service, so you can focus on your automation logic instead of browser infrastructure. Whether you are running a single agent or a fleet of them, the managed browser-hour model gives you predictable costs and the flexibility to scale.

For a practical overview of how Remote Browser fits into your stack, see the remote browsers for AI agents post. If you are ready to start, check the pricing page and create your first session today.