TL;DR
- Scope and isolation. This comparison focuses on account-lifecycle governance, not parallel-session setup. For each authorized account, check how the platform keeps browser state separate and maps sessions to the right customer.
- Authentication and credential boundaries. Check who connects each account, handles MFA and expired logins, and can access credentials. Anchor pairs its managed browser fleet with OmniConnect for customer-controlled account connection.
- Product layer and handoffs. Browser infrastructure hosts sessions, while task-running agents execute tasks in them. Traditional RPA can coordinate work across applications. Check how each option supports human intervention and audit records.
- Scale and recovery. Compare batch creation, active concurrency, and launch throughput separately. Before you compare costs or reliability, test verified task completion and retries on the same workload.
What "multi-account" browser automation actually requires
Multi-account browser automation runs authorized workflows across separate customer or business accounts. Each account needs isolated browser state, its own authentication lifecycle, and an audit trail that connects actions to the right account. Launching many browsers for one workload addresses concurrency, but it does not establish those account boundaries.
Start by checking how a provider isolates sessions and links them to accounts. You need a reliable mapping between each customer, their authorized identity, and the browser session that uses it. Anchor’s OmniConnect flow, for example, returns an identity ID that your application maps to a customer. Your application must still authenticate the customer and validate the callback context.
Authentication and credential handling need separate scrutiny. Compare how providers handle MFA, expired logins, and handoffs to a person, then ask who holds credentials and what an agent can see when it enters them. Anchor’s managed authentication documentation distinguishes profiles that retain browser state from managed identities that handle login and reauthentication.
For ongoing operations, look for records that let you trace each task to its account and determine whether a write succeeded before you retry it. Assess security and stealth options against the sites you are permitted to access, without assuming those options guarantee access. When sizing capacity, keep batch creation, simultaneous active sessions, and launch throughput separate.
Browser infrastructure supplies hosted sessions and browser controls. Task-running agents use browsers to complete tasks, while traditional RPA can coordinate browser work with other applications. You can combine these layers, so compare each provider on the account-lifecycle responsibilities it actually covers.
Comparison table: account isolation, auth, and governance across providers
Browser infrastructure, task-running agents, and traditional RPA can work together, so the comparison identifies each provider’s product layer rather than treating those categories as substitutes. “Not documented” means the reviewed first-party sources did not establish the capability, not that the provider lacks it.
Batch size counts sessions created in one request, active concurrency counts browsers running at once, and launch throughput counts sessions started over time. None establishes the others. Vendors also bill in different units, so headline usage prices cannot establish cost per verified completed workflow.
Anchor: managed browser fleet with customer-controlled authentication
Anchor’s managed browser fleet fits workflows where your application must keep customer accounts separate while handling login and re-authentication. In OmniConnect, your backend creates a one-time token valid for 15 minutes. The customer signs in through an Anchor-hosted interface, and Anchor sends an HTTPS callback containing an identity_id. Your application then maps that identity to the authorized customer before launching a browser session with it attached. Your application still needs to authenticate the customer and validate the callback context and popup origin.
Applications + Identities manage validated session state, login, MFA, and re-authentication for those connected accounts. A plain browser profile persists state but leaves you to handle re-login when a session expires. For workflows that need another credential, Secret Values can restrict a secret to a domain and supply it when the browser types, without exposing its value to the model. Anchor can also pause a task and send an intervention.requested event with a live-view URL when a person needs to step in.
Anchor also supports high-volume browser work beyond account linking. Its Anchor Chromium browser uses humanized behavior and fingerprinting, while proxy and network options give you control over how sessions connect. Web Unlocker serves high-volume page retrieval, while interactive browser sessions suit account workflows that require clicks, forms, and persistent state. These capabilities can help with site access, but they do not guarantee access through a target site’s protections.
For capacity planning, Anchor’s batch API supports creation of up to 5,000 sessions. Anchor states that its Enterprise program supports launch throughput of 100,000 or more sessions per minute. Batch size and launch throughput describe different operations, and neither specifies how many browsers your plan can run concurrently. For write operations, check the target account before retrying an uncertain result. Anchor’s task documentation says a repeated request starts a new run even if you supply the same Idempotency-Key. Configured retries also start fresh sessions, while runs attached to an existing session get one attempt.
Browserbase: context-per-account isolation with live-view handoff
Browserbase suits developers who want to assign a persistent browser Context to each account and maintain their own account-to-context mapping. Its Contexts documentation recommends one context per site per login and warns against simultaneous logins using the same context. Contexts preserve cookies and authentication data across sessions, and Browserbase encrypts them at rest.
A persistent context does not guarantee a persistent login. The target website can expire its session, so your workflow needs to detect when an account has logged out before attempting an action. Browserbase’s authentication guide documents a first login through session live view and a handoff to the end user for two-factor codes.
For later verification or approval steps, Agents can pause a run with pauseWhen while keeping the session open. On resume, Browserbase substitutes supplied variable values when the agent types, rather than placing those values in the raw transcript. Pauses have timeouts, so your workflow must handle an unanswered request. Browserbase also provides Agents, Functions, and Secrets alongside browser infrastructure.
Kernel: profile-scoped accounts with managed reauth and audit logs
Kernel is a strong fit when each connected account needs separate browser state and a managed authentication lifecycle. Its profile guidance recommends one profile per account when cookies, proxies, permissions, or login lifecycles differ. Kernel also recommends one writer per writable profile, which helps prevent concurrent jobs from changing the same account state. An active browser does not automatically receive refreshed profile cookies, so you need to account for stale sessions after a login update.
Managed Auth connects a domain-specific login to a browser profile. A user can sign in through Kernel’s hosted interface or an embedded flow, while a credential vault supports subsequent authentication. Kernel says it encrypts credential values and does not return them to the model or API. Health checks can trigger reauthentication for eligible flows, but automatic recovery is not guaranteed. Email or SMS codes and approval requests require the end user to return and complete the step.
Kernel provides separate tools for inspecting browser activity and governing API access. Session replays and browser telemetry help you investigate what happened during a run. Audit logs record API activity, while scoped API keys let you limit access. A replay can show an account-level failure, but it does not replace an API audit trail showing which credential made a request.
Steel: open-source profiles with beta credential injection
Steel suits you if you want browser infrastructure that you can run in Steel Cloud or self-host. Its Profiles preserve cookies and login state across sessions. Steel recommends one profile and a stable IP per account, so you can keep each account’s browser state separate. Each profile has a 300 MB size limit, and Steel automatically deletes profiles after 30 days without use.
Steel’s Credentials API is in beta. It stores credentials encrypted per organization, scopes them by website origin and namespace, and can inject them without returning their values to the agent. It also supports TOTP seeds. For logins or approvals that need a person, Steel offers an interactive session URL. You remain responsible for deciding who may receive that URL.
Agent Traces provide an action timeline, synchronized video, and console and network inspection for investigating a failed run. The reviewed Steel documentation does not describe a hosted end-user account-linking lifecycle like OmniConnect. You would need to plan how your application invites users to connect accounts, tracks those connections, and handles later reauthentication.
Browser Use: hosted agent tasks with per-user profiles
Browser Use fits workflows that need hosted agent tasks alongside browser infrastructure. Its product lineup includes Cloud Agent, Cloud browser infrastructure, and an open-source Python agent you can run yourself.
For account separation, Cloud Profiles preserve browser state between runs, and Browser Use recommends one profile per end user. A conversation session tracks an agent task. A later run may open a fresh browser using the saved profile, so the profile is the account-level record to manage.
Browser Use supports human handoff when 2FA requires a person. A person can take over the live browser and return the same session to the agent, provided the handoff happens within the keepAlive window. You should treat the live browser URL as a secret.
Secrets V4 provides per-run aliases and domain restrictions for supplied credentials. Browser Use cautions that aliases do not guarantee the agent cannot see a credential after entering it, because page content and browser access may expose the value. If your client times out, check whether the server-side run is still active before retrying an account action.
Hyperbrowser: profile-backed sessions with optional agent execution
Hyperbrowser suits workflows that need a separate browser profile for each account, with agent execution available when needed. Its profiles retain cookies and authentication state across sessions. Profiles are read-only by default. To save changes such as a refreshed login, you must enable persistChanges and close the session. Hyperbrowser supplies browser infrastructure, while HyperAgent provides an optional task-running layer.
Hyperbrowser’s credential fill feature is in public preview and requires access on request. It can fill stored credentials and TOTP codes, but it does not submit forms. Hyperbrowser warns that page scripts, extensions, and CDP clients can read values after the browser fills them. You should assess that exposure against your credential-handling requirements before using the feature.
For human handoffs, Live View lets a person inspect or control a session through a tokenized URL. You must restrict access to that URL. The reviewed documentation does not describe a managed reauthentication lifecycle for expired account logins, so treat that capability as undocumented rather than absent.
Matching the platform to your account-governance requirements
Choose Anchor when customers need to connect their own accounts through a hosted sign-in flow. OmniConnect returns an identity for your application to map to the authorized customer, while Applications and Identities manage login, MFA, and reauthentication. Your application still needs to verify the customer’s permissions before using that identity.
Shortlist Anchor for high-volume workloads that need stealth and network options as well as account authentication. Anchor documents Anchor Chromium, Web Unlocker, and network controls, but those measures do not guarantee access to a target site. Its batch API supports creating up to 5,000 sessions per request, while its Enterprise program supports launch throughput of 100,000 or more sessions per minute. Neither figure specifies active concurrency.
For developer-managed account state, compare Browserbase and Kernel against your requirements for session persistence, reauthentication, and audit records. If you need self-hosting, assess Steel’s deployment options. If task-running agents matter most, assess Browser Use and Hyperbrowser for human handoffs and credential boundaries. Check each provider’s current documentation and test the account lifecycle you intend to run before selecting one.
Compare costs and reliability with the same authorized workflows, account volume, and retry profile. Vendors can bill for different units, so headline prices cannot establish cost per verified completed workflow.
Operational safeguards every multi-account deployment needs
After selecting a platform, give each customer connection only the permissions its approved workflow needs. Your application should authenticate the customer before account linking, verify the callback context and popup origin, and confirm that the connected identity belongs to the customer who requested it. Anchor’s OmniConnect flow returns an identity ID for application-side mapping. The callback does not grant access on its own.
Keep an explicit record connecting each customer account to its browser identity and authorized jobs. Before every run, your application should check that mapping rather than reuse a saved session merely because its login still works. Revoke access when customer permission ends.
Log who approved each run, which account and session it used, and what the job changed. Record human interventions so you can reconstruct a disputed action. Keep credential values out of logs, and restrict access to recordings or live views that may expose account data.
Before retrying an uncertain write, inspect the target account for the intended change. Anchor’s task documentation says a repeated request starts a new run even if it carries the same Idempotency-Key. A timed-out invoice submission could create a duplicate if you retry without checking. Check each target site’s automation rules, and keep the workflow within the customer’s authorization and the site’s policies.
FAQs
How does browser infrastructure differ from an agent framework or RPA? Browser infrastructure supplies hosted sessions and browser controls. An agent framework decides which actions to take, while RPA coordinates steps across applications. You can use these layers together, but each answers a different buying question.
Is it safe to automate accounts protected by MFA? MFA handling depends on the account owner’s authorization and the target site’s policies. For customer-linked accounts, Anchor’s OmniConnect flow lets the customer sign in and returns an identity for your application to map to that customer. Your application must still verify the callback and enforce account permissions. No provider’s MFA feature alone establishes compliance.
How should I compare batch size, concurrency, and launch throughput? Batch size counts sessions requested together, active concurrency counts sessions running at once, and launch throughput counts sessions started per minute. Anchor’s API documents batches of up to 5,000 sessions, while its Enterprise program supports launch throughput of 100,000 or more sessions per minute. Neither figure states how many sessions your plan can run simultaneously.
Can I retry a failed account action safely? Check the target account before repeating any action that may have changed data. Anchor’s task documentation says a repeated request starts a new run even when you supply an Idempotency-Key. If a timeout follows a form submission, verify whether the site saved the change before submitting again.
