Browser Use Account: What It Is and How to Manage It

# Browser Use Account: What It Is and How to Manage It

A browser use account is the access layer between your AI agent or automation script and a hosted Chromium runtime. Instead of running a local browser, installing dependencies, and managing profiles, you authenticate to a remote service that provisions browser sessions on demand. This is the core model behind Remote Browser, and it changes how you think about browser infrastructure.

If you are building with browser-use, Playwright, or Puppeteer, the account is not a billing detail. It is the control plane for your sessions, usage limits, and browser settings. This guide explains what a browser use account includes, how browser-hour metering works, and how to structure your workloads to avoid surprises.

Why a Browser Use Account Matters

Local browser automation works until it does not. You hit resource limits, struggle with persistent profiles, and deal with flaky network conditions. A hosted runtime solves those problems, but it introduces a new requirement: an account that tracks what you consume.

A browser use account gives you:

• API credentials for authenticating requests to the runtime.
• Session management for creating, listing, and terminating browser sessions.
• Usage visibility into how many browser-hours you have consumed.
• Configuration controls for proxies, profiles, and other browser settings.

Without an account, you cannot provision a remote browser. With one, you get a consistent, repeatable way to run browser automation at scale.

What You Get with a Browser Use Account

Remote Browser provides a browser API that is compatible with the tools you already use. The account ties together several components:

The account is the glue. It maps your API key to the sessions you create and the resources those sessions consume.

Browser-Hour Metering Explained

The unit of consumption for a browser use account is the browser-hour. One browser-hour equals one hour of a running browser session, regardless of how much CPU or memory the session uses.

This model is simple but has implications:

• Idle time counts. If you keep a session open while your agent thinks, you pay for that time.
• Concurrency multiplies. Five parallel sessions for one hour consume five browser-hours.
• Short tasks are efficient. A 10-second task consumes a fraction of a browser-hour.

The metering is granular enough that small tasks are cheap, but you should still design for efficiency. Close sessions when you are done. Do not leave them running overnight.

For current pricing and rate details, check the pricing page. The exact numbers change, but the metering model is stable.

Managed Browser-Hour vs. Self-Managed

You have two ways to consume browser-hours: managed or self-managed.

Managed browser-hours mean Remote Browser handles the infrastructure. You get a session, run your code, and the runtime handles scaling, isolation, and cleanup. This is the default and the easiest way to start.

Self-managed browser-hours would mean you run your own browser fleet and only use the account for orchestration. Remote Browser does not offer this model. The value is in the managed runtime.

The distinction matters for cost planning. With managed browser-hours, you pay for the convenience of not running infrastructure. You do not pay for idle VMs or maintenance windows.

How to Create a Browser Use Account

Creating an account is straightforward. You sign up, generate an API key, and start provisioning sessions. The workflow looks like this:

1. Sign up at remote-browser.dev.
2. Generate an API key from the dashboard.
3. Provision a session using the API or the web interface.
4. Connect your automation tool to the session endpoint.

The API is RESTful for session management and WebSocket-based for CDP communication. This means you can use it from any language that supports HTTP and WebSockets.

Connecting Playwright to Your Account

Here is a practical example using TypeScript and Playwright. This connects to a remote browser session using the CDP endpoint from your account.

import { chromium } from 'playwright';

async function main() {
  // The CDP URL comes from your browser use account dashboard
  // or from the API response when you create a session
  const cdpUrl = 'wss://remote-browser.dev/cdp/session/abc123';
  
  // Connect Playwright to the remote browser
  const browser = await chromium.connectOverCDP(cdpUrl);
  
  // Get the default context or create a new one
  const context = browser.contexts()[0] || await browser.newContext();
  
  // Use the session like a local browser
  const page = await context.newPage();
  await page.goto('https://example.com');
  
  // Take a screenshot to verify the session works
  await page.screenshot({ path: 'remote-session.png' });
  
  // Close the page and disconnect
  await page.close();
  await browser.close();
}

main().catch(console.error);

This code connects to a remote Chromium instance using the CDP protocol. The session is isolated, so you can run multiple agents without interference.

Managing Sessions and Profiles

A browser use account gives you control over session lifecycle. You can:

• Create a new session with specific browser settings.
• List active sessions to see what is running.
• Terminate a session when you are done.
• Reuse a persistent profile to maintain login state.

Persistent profiles are critical for workflows that require authentication. Instead of logging in every time, you save the profile once and reuse it across sessions. This is covered in more depth in our guide to browser profiles.

Usage Controls and Budgeting

One of the most useful features of a browser use account is usage controls. You can set limits on how many browser-hours your team consumes in a day, week, or month.

This is not just a billing feature. It is an operational safeguard. If an agent goes rogue and starts spawning sessions, the usage cap stops the bleeding.

Consider these practices:

• Set a daily cap for development environments.
• Monitor session duration for long-running agents.
• Use session isolation to prevent cross-contamination.
• Terminate idle sessions programmatically.

The documentation covers the API endpoints for usage controls in detail.

Browser Use Account vs. Local Browser

The comparison is not about capability. A hosted browser runs the same Chromium engine you would run locally. The difference is in management and scale.

For a deeper comparison, see our post on hosted Chromium vs. local setup.

Security Considerations

A browser use account is a credential. Treat it like one.

• Rotate API keys regularly.
• Use separate keys for development and production.
• Restrict access to the dashboard.
• Monitor usage for anomalies.

The runtime also supports configurable browser settings for proxy and network configuration. This is useful when you need to route traffic through specific endpoints. For more on this, read about remote control browser capabilities.

When to Use a Browser Use Account

You need a browser use account when:

• You run AI agents that interact with the web.
• You automate workflows that require a real browser.
• You need persistent sessions across multiple runs.
• You want to scale without managing infrastructure.

You do not need one if you are running a single script locally and never plan to scale. But even then, the hosted runtime removes a lot of friction.

Common Pitfalls to Avoid

Here are the mistakes we see most often:

1. Leaving sessions open. Close them when done. Browser-hours add up.
2. Ignoring usage controls. Set caps before you need them.
3. Reusing API keys across environments. Use separate keys.
4. Assuming local behavior matches remote. Test against the hosted runtime.
5. Not using persistent profiles. You will re-authenticate every session.

Avoid these and your experience will be smooth.

Getting Started

A browser use account is the entry point to a hosted browser runtime. It gives you API access, session management, and usage visibility. The metering model is simple: browser-hours consumed equals time multiplied by concurrency.

Start with a small workload. Create a session, connect Playwright, run a task, and terminate the session. Measure the browser-hours you consumed. Then scale up with confidence.

For current pricing and plan details, visit the pricing page. For API reference and examples, see the documentation.

If you want to understand the broader architecture, read our overview of remote browsers for AI agents. It explains why the runtime layer matters and how it fits into your stack.

The Chrome DevTools Protocol is the foundation of this approach. You can read the official CDP documentation to understand what is possible at the protocol level.

Your browser use account is the key to reliable, scalable browser automation. Use it well.