Browser Use Credits: How Remote Browser Pricing Works

Browser use credits are the billing unit behind hosted browser runtimes. If you are building an AI agent that navigates the web, you have likely hit the limits of local Chrome instances: they are slow to spin up, hard to isolate, and fragile under concurrency. Remote Browser solves that by giving you a hosted Chromium session exposed over CDP, Playwright, or Puppeteer. But before you wire it into production, you need to understand how browser use credits are consumed, how they compare to alternatives, and how to keep costs predictable.

This guide explains the metering model behind Remote Browser, what you actually pay for, and how to design your automation so you do not waste browser use credits on idle time or redundant work.

What Are Browser Use Credits?

Browser use credits are a consumption-based measure of how long a remote browser session is active. Unlike API-call-based pricing that charges per request or per token, Remote Browser meters by the hour of active browser time. A session that is running—even if it is waiting on a slow network response—consumes credits. A session that is stopped does not.

This model aligns with how browsers actually behave. A browser is a stateful runtime. It holds DOM state, cookies, network connections, and JavaScript execution contexts. Charging per request would penalize you for long-running pages. Charging per token would make no sense at all. Per-hour metering is the only model that maps cleanly to the resource consumption of a real Chromium instance.

The practical implication: you pay for wall-clock time, not for CPU usage. If your agent spends 10 minutes on a page waiting for a dynamic element to appear, that is 10 minutes of browser use credits. If it finishes in 2 seconds, you pay for a fraction of an hour.

How Remote Browser Meters Usage

Remote Browser tracks usage at the session level. When you create a browser session via the API, the clock starts. When you close it, the clock stops. You are billed for the elapsed time, rounded to the nearest billing increment.

Here is what counts toward browser use credits:

• Active session time: The period between session creation and session termination.
• CDP connection time: If you connect via the Chrome DevTools Protocol, the session remains billable even if your client disconnects but the browser stays alive.
• Persistent profile time: If you use a persistent profile, the session is billable while it is running, not while it is stored.
• Proxy and stealth settings: These are configuration options, not separate line items. They do not add a surcharge per session, but they are part of the session's resource footprint.

What does not count:

• Idle stored sessions: A saved profile that is not running consumes no credits.
• API calls: Creating a session, listing sessions, or fetching logs does not consume browser use credits.
• Data transfer: There is no per-gigabyte charge for the traffic flowing through the browser.

The exact per-hour rate is listed on the pricing page. It is designed to be transparent: you know the rate upfront, and you can estimate your monthly cost by multiplying your average concurrent session count by your average session duration.

Browser Use Credits vs. Token-Based Pricing

Many AI agent platforms charge per token. That model works for LLM inference, where the cost is proportional to the number of tokens processed. It does not work for browser automation, where the cost is dominated by the runtime itself.

Consider a typical web automation task: navigate to a page, wait for a chart to render, extract the data, and move on. The token count for the LLM that plans this task might be 2,000. The token count for the page's JavaScript execution is irrelevant—the browser does not bill you in tokens. The cost is the 30 seconds the browser spent loading the page, executing scripts, and rendering the canvas.

Token-based browser pricing forces you to estimate how many tokens a page will consume. That is unpredictable. A heavy React app might generate 50,000 tokens of DOM serialization. A static HTML page might generate 500. You cannot control that from your agent code.

Per-hour pricing removes that variance. A 30-second page load costs the same regardless of whether the page is a static brochure or a single-page application with 200 KB of JavaScript. This makes cost forecasting significantly easier.

Comparison: Browser Use Credits Across Platforms

The table above shows the core tradeoff. Self-hosting gives you the lowest marginal cost per hour, but you pay for the VM even when your browser is idle. Token-based platforms charge you for the LLM's reasoning, not the browser's execution. Remote Browser charges only for the browser runtime, which is the resource you actually need.

How to Reduce Browser Use Credits Consumption

You can control your browser use credits bill by optimizing how you use sessions. Here are concrete strategies.

1. Reuse Sessions for Sequential Tasks

If your agent needs to visit three pages on the same site, do not create three sessions. Keep one session open and navigate it. Session creation has overhead—new browser process, new profile, new network stack. Reusing a session eliminates that overhead and reduces total billable time.

import { chromium } from 'playwright';

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

const page = await browser.newPage();

// Sequential navigation in one session
await page.goto('https://example.com/login');
await page.fill('#username', 'agent-user');
await page.fill('#password', process.env.AGENT_PASSWORD);
await page.click('#submit');

await page.goto('https://example.com/dashboard');
const data = await page.evaluate(() => document.body.innerText);

// Close the session when done
await browser.close();

This pattern keeps the session alive for the duration of the task, not per navigation. You pay for one continuous session, not three separate ones.

2. Set Explicit Timeouts

A common source of wasted browser use credits is a session that hangs. If your agent waits indefinitely for a selector that never appears, you are burning credits. Set explicit timeouts on all navigation and wait operations.

await page.goto('https://example.com/slow-page', { timeout: 15000 });
await page.waitForSelector('#data-table', { timeout: 10000 });

If the timeout fires, your agent can retry or fail fast. Either way, you stop the clock sooner.

3. Use Session Isolation for Parallel Workloads

Remote Browser supports session isolation. If you are running multiple independent tasks, run them in parallel sessions. This does not reduce total billable time—you pay for the sum of all session durations—but it reduces wall-clock time for the overall workload. If you have 10 tasks that each take 1 minute, running them sequentially costs 10 minutes. Running them in parallel costs 1 minute of wall-clock time, but still 10 minutes of aggregate session time.

The benefit is throughput, not cost. If your workload is latency-sensitive, parallel sessions are worth it. If you are optimizing purely for cost, sequential execution on a single session is cheaper because you avoid the overhead of multiple session startups.

4. Close Sessions Explicitly

Do not rely on garbage collection or process exit to close your browser sessions. Always close them explicitly in a finally block or a cleanup handler. A session that is left open continues to consume browser use credits until the server-side timeout kicks in.

let browser;
try {
  browser = await chromium.connectOverCDP('wss://remote-browser.dev/cdp/session_abc123');
  // ... your automation logic
} finally {
  if (browser) {
    await browser.close();
  }
}

5. Use Persistent Profiles for Repeat Visits

If your agent frequently visits the same authenticated sites, use a persistent profile. This avoids the cost of re-authenticating on every session. The profile is stored server-side and does not consume credits while idle. When you attach it to a new session, the browser starts with the saved cookies and localStorage, so your agent can skip the login flow entirely.

This is particularly useful for tasks like checking a dashboard or scraping a paywalled site. The first session pays for the login. Subsequent sessions start already authenticated.

When Browser Use Credits Are Worth It

Browser use credits make sense when you need a real browser runtime without the operational overhead. Here are the scenarios where the per-hour model is clearly the right choice.

AI Agents That Need a Persistent Browser

If you are building an AI web agent that maintains state across multiple turns, you need a persistent browser session. Local Chrome instances are not designed for this. They are tied to a desktop session, they crash under memory pressure, and they are hard to access remotely. Remote Browser gives you a session that lives in the cloud, accessible from any machine via CDP.

This is the core use case for the remote browser for AI agents pattern. The agent connects to a hosted Chromium instance, performs its task, and disconnects. The session can be kept alive or terminated, depending on the workflow.

Stealth and Proxy Requirements

Some automation tasks require specific proxy configurations or browser settings to avoid detection. Remote Browser supports configurable proxy settings and stealth-related options. You can attach a proxy to a session and route all traffic through it. This is harder to do with a local browser, where you would need to manage proxy configuration at the OS level.

The stealth browsers post covers this in more detail. The key point for pricing: proxy configuration does not change the billing model. You still pay per hour of session time, regardless of the proxy in use.

Testing and QA Workloads

If you are running browser-based tests, you need a browser that starts clean, runs deterministically, and can be torn down quickly. Remote Browser's session isolation is ideal for this. Each test gets a fresh browser context, and you pay only for the duration of the test run.

This is the pattern described in the browser automation API post. The API gives you programmatic control over session lifecycle, so you can create a session, run a test, and destroy the session in a few lines of code.

Browser Use Credits vs. Self-Hosting

The alternative to browser use credits is running your own Chromium infrastructure. This is viable if you have a dedicated DevOps team and predictable traffic. But the math rarely works out in your favor.

Self-hosting requires:

• A VM or container orchestration platform (Kubernetes, ECS, etc.)
• A Chromium image that is kept up to date
• A CDP proxy to expose the browser to your agents
• Monitoring and alerting for crashed sessions
• Network configuration for proxies and egress

The cost of this infrastructure is fixed, regardless of utilization. If you run 10 browser instances 24/7, you pay for 7,200 instance-hours per month, even if your agents only use them for 1,000 hours. Browser use credits let you pay for the 1,000 hours and nothing else.

For most teams, the operational overhead of self-hosting exceeds the marginal cost of a hosted runtime. The hosted browser API post explains this tradeoff in detail.

Getting Started with Browser Use Credits

To start using browser use credits, follow these steps:

1. Create an account on Remote Browser.
2. Review the pricing page to understand the current per-hour rate.
3. Create your first session via the API or the dashboard.
4. Connect via CDP using Playwright, Puppeteer, or Selenium.
5. Monitor your usage in the dashboard to track credit consumption.

The browser-use developer guide walks through the integration steps. If you are migrating from a local setup, the browser-use production post covers the common pitfalls.

The Bottom Line on Browser Use Credits

Browser use credits are a simple, predictable way to pay for browser automation. The per-hour model aligns with how browsers actually consume resources, and it avoids the unpredictability of token-based pricing. By reusing sessions, setting timeouts, and closing sessions explicitly, you can keep your costs low while getting the reliability of a hosted Chromium runtime.

For AI agents that need a real browser, Remote Browser's per-hour pricing is the most straightforward option. You pay for what you use, nothing more. Check the pricing page for current rates, and start building your first session today.

For more technical details on the underlying protocol, the Chrome DevTools Protocol documentation is the authoritative reference for CDP-based automation.