Starts Browser-Hour: How Remote Browser Meters AI Agent Time

# Starts Browser-Hour: How Remote Browser Meters AI Agent Time

When you run an AI agent that needs to interact with the web, every second of browser activity consumes compute. The concept of a starts browser-hour—the moment a hosted Chromium session begins consuming billable time—is central to understanding how Remote Browser meters usage. Unlike local browser automation where you pay for your own infrastructure regardless of utilization, hosted browser runtimes charge based on active session time. This article explains exactly what starts a browser-hour, how session metering works, and why this model benefits AI agent workloads.

What Starts a Browser-Hour?

A browser-hour starts when a hosted Chromium session is provisioned and becomes ready to accept commands. This isn't the same as when your script first calls browser.newPage() or when you send a CDP command. The clock begins at session creation—when Remote Browser spins up a dedicated Chromium instance in the cloud.

Three actions trigger the start of a browser-hour:

1. API session creation: Calling the Remote Browser API to create a new browser session.
2. Profile-based launch: Starting a session with a persistent profile attached.
3. Reconnection: Resuming an existing session that was previously paused or disconnected.

Once started, the browser-hour continues until you explicitly terminate the session or it times out due to inactivity. This is a critical distinction from per-request pricing models: you're paying for the browser's lifetime, not individual operations.

How Session Metering Works

Remote Browser meters time in granular increments, typically per-second or per-minute, which then rolls up into browser-hours for billing purposes. The metering starts the moment the session is ready and stops when the session is destroyed.

Here's a practical breakdown:

The key takeaway: a browser-hour starts when you create a session, not when you send your first command. This means efficient session management directly impacts your costs.

Why Browser-Hour Metering Suits AI Agents

AI agents differ from traditional test scripts in several ways that make browser-hour metering particularly appropriate:

1. Long-Running Tasks

AI agents often need to maintain browser state across multiple steps. A task like "monitor competitor pricing and update our database" might require a browser session open for hours. With browser-hour pricing, you pay for exactly that duration—no more, no less.

2. Session Persistence

Unlike stateless API calls, browser sessions maintain cookies, localStorage, and DOM state. A browser-hour model encourages keeping sessions alive when you need continuity, rather than forcing you to serialize state between requests.

3. Human-in-the-Loop Workflows

Some AI agent workflows require human approval at certain steps. The browser session stays alive while waiting for input, and you're billed for that waiting time. This is transparent and predictable.

Comparing Browser-Hour Pricing to Alternatives

To understand why browser-hour metering is advantageous, compare it to other pricing models:

Remote Browser's browser-hour model combines the flexibility of usage-based pricing with the predictability of time-based metering. You know exactly what you're paying for: the duration your browser session exists.

Managing Browser-Hour Consumption

Effective browser-hour management means minimizing the time between session creation and termination. Here are concrete strategies:

Reuse Sessions When Possible

Instead of creating a new session for every task, reuse an existing session. Remote Browser supports persistent profiles that maintain state across sessions, reducing the need for fresh starts.

Set Explicit Timeouts

Configure inactivity timeouts so sessions don't linger after your agent finishes its work. A session that stays alive due to a bug in your code is a session you're paying for.

Monitor Session Lifecycle

Use the Remote Browser API to track active sessions and their durations. This visibility helps you identify inefficiencies in your agent's browser usage.

Code Example: Managing Session Lifecycle

Here's a TypeScript example using Playwright with Remote Browser that demonstrates careful session management:

import { chromium } from 'playwright-core';
import { RemoteBrowser } from '@remote-browser/sdk';

async function runAgentTask() {
  // Connect to Remote Browser's CDP endpoint
  const browser = await chromium.connectOverCDP(
    'wss://remote-browser.dev/cdp',
    {
      headers: {
        'Authorization': `Bearer ${process.env.REMOTE_BROWSER_API_KEY}`
      }
    }
  );

  try {
    // Session starts here - browser-hour begins
    const context = await browser.newContext({
      viewport: { width: 1280, height: 720 }
    });
    
    const page = await context.newPage();
    
    // Execute agent task steps
    await page.goto('https://example.com');
    await page.waitForSelector('h1');
    const title = await page.textContent('h1');
    
    console.log(`Page title: ${title}`);
    
    // Explicitly close context to stop metering
    await context.close();
  } finally {
    // Ensure browser disconnects to stop the browser-hour
    await browser.close();
  }
}

// Run with a timeout to prevent orphaned sessions
const timeout = setTimeout(() => {
  console.error('Task timed out - session will be terminated');
  process.exit(1);
}, 300000); // 5 minutes

runAgentTask()
  .then(() => clearTimeout(timeout))
  .catch((err) => {
    clearTimeout(timeout);
    console.error('Agent task failed:', err);
  });

This code ensures the browser session is explicitly closed in all paths, preventing accidental browser-hour accumulation.

Session Browser-Hour: What Counts as Active Time

Understanding what constitutes active session time is crucial for cost estimation. A browser-hour starts when the session is created and continues until one of these events:

• Explicit termination: You call browser.close() or the API equivalent.
• Inactivity timeout: No commands received for a configurable period.
• Session limit: The maximum session duration is reached.

Remote Browser's documentation provides exact timeout defaults and configuration options. The key is that idle time still counts toward your browser-hour total.

Managed Browser-Hour: How Remote Browser Simplifies Operations

The term "managed browser-hour" refers to the operational overhead Remote Browser handles for each hour of browser time:

• Infrastructure maintenance: Chromium updates, security patches, and version management.
• Resource allocation: Ensuring each session gets adequate CPU and memory.
• Network management: Handling proxy configurations and IP rotation.
• Monitoring: Tracking session health and providing metrics.

When you pay for a browser-hour, you're not just paying for compute—you're paying for the operational expertise that keeps sessions reliable. This is particularly valuable for AI agents that need consistent browser behavior across thousands of sessions.

Browser-Hour Rate Considerations

The browser-hour rate you pay depends on several factors:

1. Session type: Standard sessions vs. sessions with enhanced stealth settings.
2. Profile persistence: Sessions with persistent profiles may have different rates.
3. Geographic location: Browser sessions in specific regions may incur different costs.
4. Concurrency: Running many simultaneous sessions may qualify for volume pricing.

For current browser-hour rates, check the pricing page. Rates are designed to be transparent—you can calculate expected costs based on your agent's average session duration and frequency.

Browser-Use Posts: Practical Patterns for Hour Management

Based on common browser-use patterns, here are practical approaches to managing browser-hours effectively:

Pattern 1: Batch Processing

Group multiple tasks into a single browser session rather than creating separate sessions per task. This amortizes session startup overhead across multiple operations.

Pattern 2: Session Pooling

Maintain a pool of pre-warmed sessions that your agent can acquire and release. This reduces the latency of session creation and ensures you're not paying for cold starts.

Pattern 3: Scheduled Cleanup

Implement a scheduled job that terminates orphaned sessions. This prevents browser-hour accumulation from failed agent runs.

Browser Use Profiles and Hour Consumption

Persistent browser profiles interact with browser-hour metering in important ways. When you use a profile:

• Session startup may be faster because the profile is pre-loaded.
• State persists across sessions, reducing the need for long-lived sessions.
• Profile storage is separate from session time billing.

This means profiles can actually reduce your total browser-hour consumption by allowing you to start fresh sessions with existing state, rather than keeping one session alive indefinitely.

Browser Use Account Management

Managing your browser use account effectively means monitoring your browser-hour consumption across all your projects and agents. Remote Browser provides:

• Usage dashboards: Real-time visibility into active sessions and historical consumption.
• Alerts: Notifications when usage approaches thresholds you set.
• API access: Programmatic access to usage data for internal cost tracking.

This level of visibility ensures you're never surprised by a browser-hour bill.

The Future of Browser-Hour Metering

As AI agents become more sophisticated, browser-hour metering will evolve. We're likely to see:

• More granular metering: Sub-second billing for high-frequency operations.
• Predictive cost estimation: AI-driven recommendations for session management.
• Hybrid pricing models: Combining browser-hours with per-operation pricing for specific workloads.

Remote Browser is committed to transparent, predictable pricing that scales with your AI agent workloads.

Conclusion

Understanding what starts a browser-hour is essential for anyone running AI agents on hosted browser infrastructure. The model is simple: create a session, use it, terminate it. The discipline comes in managing session lifecycles efficiently.

Remote Browser's browser-hour metering gives you:

• Predictable costs: You pay for time, not operations.
• Flexibility: Sessions can be short or long, depending on your needs.
• Transparency: Full visibility into what you're paying for.

For AI agent workloads that need reliable, stateful browser access, browser-hour metering is the right model. Start optimizing your session management today by reviewing your current browser usage patterns and identifying where you can reduce idle time.

Ready to see how browser-hour pricing works for your AI agents? Check the pricing page for current rates, or read about remote browsers for AI agents to understand the broader runtime architecture. For a deeper dive into session management, explore our remote web browser guide or learn about remote control browser capabilities.

For technical details on CDP integration, refer to the Chrome DevTools Protocol documentation or the Playwright CDP connection guide.