Browser-Hour Managed: The Metered Runtime for AI Web Agents

When you move browser automation from a local laptop to a hosted runtime, the first question is usually about cost. The second is about control. Browser-hour managed pricing addresses both: you pay for the time a Chromium session is actually running, and you get the tooling to cap, monitor, and predict that spend. This model is central to how Remote Browser works, and it's worth understanding before you wire it into a production agent.

This guide explains what a browser-hour is, how managed metering differs from flat subscriptions or per-request pricing, and how to use Remote Browser's usage controls to keep costs predictable. If you're evaluating hosted browser infrastructure, this is the practical breakdown you need.

What Is a Browser-Hour?

A browser-hour is a unit of metered time. One browser-hour equals one hosted Chromium session running for sixty minutes. If you run two sessions for thirty minutes each, that's one browser-hour total. If you run one session for two hours, that's two browser-hours.

The key distinction is that you're paying for wall-clock time, not CPU cycles or API calls. This matters for AI agents because they often hold a browser session open while waiting for model inference, network responses, or human-in-the-loop approval. With browser-hour metering, that idle time is still billable—but it's also predictable and easy to reason about.

Remote Browser meters browser-hours across all session types: interactive live viewers, background automation, and persistent profile sessions. The browser session API exposes session start and end timestamps, so you can correlate cost with activity at a granular level.

Managed vs. Unmanaged Metering

The term "managed" in browser-hour managed means the provider handles the infrastructure, scaling, and session lifecycle. You don't provision VMs, install Chromium, or patch vulnerabilities. You call an API, get a session, and drive it via CDP or a compatible library.

Here's how managed browser-hour pricing compares to common alternatives:

Model	How You're Billed	Best For	Typical Pitfall
Browser-hour managed	Per session wall-clock time	AI agents, long-running tasks, persistent profiles	Idle time accrues cost
Per-request / per-action	Per API call or step	Short, discrete automations	Cost explodes with multi-step agents
Flat subscription	Fixed monthly fee	Predictable, always-on workloads	Paying for unused capacity
Self-hosted	Infrastructure + ops cost	Teams with dedicated DevOps	Hidden maintenance and scaling costs

Remote Browser uses browser-hour managed pricing because it aligns cost with actual resource consumption. A session that's doing heavy DOM manipulation costs the same as one that's idle—both hold a Chromium process in memory. That's honest metering, and it makes budgeting straightforward.

Why Browser-Hour Metering Fits AI Agents

AI agents are not traditional automation scripts. They loop: perceive the page, decide the next action, execute, observe the result. This creates three patterns that make browser-hour metering the right fit.

1. Long-Horizon Tasks

A web agent might spend minutes on a single task—logging in, navigating a multi-step form, extracting data, and verifying the result. Per-request pricing punishes this because each step is a separate billable action. Browser-hour metering charges for the session duration, regardless of how many steps execute.

2. Idle Waiting

Agents frequently wait: for model responses, for page loads, for user confirmation. With browser-hour metering, you know exactly what that waiting costs. A session held open for 10 minutes while an LLM generates a response is 10 minutes of browser-hour. That's predictable and easy to optimize.

3. Persistent State

Many agent workflows need a persistent profile—cookies, localStorage, session tokens. Remote Browser supports persistent profiles that survive across sessions. With browser-hour metering, you only pay when the profile is actively running in a session, not for storage.

Usage Controls: The Managed Advantage

The "managed" part of browser-hour managed isn't just about infrastructure. It's about giving you control over spend. Remote Browser provides several mechanisms to keep browser-hour usage in check.

Session Timeouts

You can set a maximum session duration. If an agent hangs or a workflow stalls, the session auto-terminates, stopping the meter. This is the single most effective guardrail for runaway costs.

Concurrency Limits

You can cap the number of simultaneous sessions. This prevents a misconfigured agent from spawning dozens of browsers at once. The pricing page shows current concurrency tiers and limits.

Usage Monitoring

The dashboard provides real-time visibility into active sessions and cumulative browser-hours. You can see which workflows consume the most time and adjust accordingly.

Programmatic Control

The API allows you to terminate sessions programmatically. If your agent detects an error condition, it can kill the session immediately, stopping the meter.

Code Example: Managing a Browser-Hour Session

Here's a TypeScript example using Playwright's CDP connection to start a session, run a task, and explicitly close it. The close call is critical—it stops the browser-hour meter.

import { chromium } from 'playwright-core';

// 1. Create a session via the Remote Browser API
const session = await fetch('https://api.remote-browser.dev/v1/sessions', {
  method: 'POST',
  headers: {
    'Authorization': `Bearer ${process.env.REMOTE_BROWSER_API_KEY}`,
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({
    // Optional: set a hard timeout to cap browser-hours
    maxDurationMinutes: 30,
    // Optional: use a persistent profile
    profileId: 'my-agent-profile',
  }),
});

const { sessionId, cdpUrl } = await session.json();

// 2. Connect Playwright to the hosted Chromium via CDP
const browser = await chromium.connectOverCDP(cdpUrl);
const context = browser.contexts()[0];
const page = context.pages()[0] || await context.newPage();

try {
  // 3. Run your agent task
  await page.goto('https://example.com');
  await page.click('button[data-testid="start"]');
  const result = await page.textContent('.result');
  console.log('Task result:', result);
} finally {
  // 4. Always close the browser to stop the browser-hour meter
  await browser.close();

  // 5. Optionally terminate the session server-side
  await fetch(`https://api.remote-browser.dev/v1/sessions/${sessionId}`, {
    method: 'DELETE',
    headers: {
      'Authorization': `Bearer ${process.env.REMOTE_BROWSER_API_KEY}`,
    },
  });
}

The finally block ensures the session is closed even if the task throws. In production, you'd wrap this in a retry loop and log session IDs for cost attribution.

Comparing Browser-Hour Managed to Local Setup

Many teams start with local Chromium and Playwright. It's free and familiar. But when you scale to multiple agents, local setup breaks down:

• Resource contention: Each Chromium instance consumes 300-500MB RAM. Ten agents on one machine will thrash.
• Environment drift: Chrome updates, OS patches, and dependency changes cause flaky tests.
• Network egress: Local browsers use your IP, which can trigger bot detection on target sites.
• No isolation: A crash in one session can take down the whole process.

Remote Browser's hosted Chromium solves these problems. Sessions are isolated, run on managed infrastructure, and can be configured with proxy settings to control IP quality. The browser-hour cost replaces the hidden cost of maintaining your own browser farm.

When Browser-Hour Managed Is Not the Right Fit

Browser-hour metering isn't universal. Here are cases where it might not be ideal:

• Ultra-short, high-frequency tasks: If your workflow is 100,000 one-second actions per day, per-request pricing might be cheaper. However, the overhead of session setup usually makes this pattern inefficient anyway.
• Always-on 24/7 browsers: If you need a browser running constantly, a flat subscription or dedicated instance might be more cost-effective. Check the browser-hour subscription post for details.
• Zero-budget prototypes: For a quick local test, local Chromium is fine. Browser-hour managed shines when you need reliability and scale.

How to Estimate Your Browser-Hour Usage

Here's a practical method for estimating monthly browser-hours:

1. Measure average session duration: Run your agent locally and log session start/end times. Average over 20+ runs.
2. Count sessions per day: How many times does your agent run daily?
3. Multiply: Average duration × sessions per day × 30 days.

Example: An agent that runs 50 times per day, averaging 8 minutes per session, consumes:

50 sessions × 8 minutes = 400 minutes/day
400 / 60 = 6.67 browser-hours/day
6.67 × 30 = 200 browser-hours/month

Then check the pricing page for the current browser-hour rate. This estimate gives you a baseline before you write any code.

Operational Best Practices

To keep browser-hour usage efficient:

• Set session timeouts at the API level. Never rely on the agent to close the browser.
• Reuse sessions for sequential tasks. If your agent needs to check three pages in a row, do it in one session.
• Use persistent profiles to avoid re-authentication overhead. Logging in fresh for every session wastes browser-hours.
• Monitor the dashboard weekly. Look for sessions that ran far longer than expected.
• Terminate idle sessions programmatically. If your agent hasn't acted in 60 seconds, it's probably stuck.

The Bottom Line

Browser-hour managed pricing is the most transparent model for AI web agents. You pay for what you use, you have tools to control usage, and you avoid the infrastructure tax of running your own browser fleet. Remote Browser implements this model with session isolation, CDP compatibility, and persistent profiles—everything you need to run production-grade automation.

The key to cost efficiency is discipline: set timeouts, monitor usage, and close sessions. Do that, and browser-hour managed becomes the most predictable line item in your infrastructure budget.

For a deeper dive into the runtime architecture, read about remote browsers for AI agents. If you're comparing against other tools, the browser-use alternatives post covers the landscape. And for technical details on the CDP connection, the Chrome DevTools Protocol documentation is the authoritative reference.