---
title: "browser-use alternative: 1 identity per profile"
description: "browser-use compared with a fixed identity per profile: what Browser Use Cloud randomises per session, what a profile keeps, and 5 USD per GB of proxy traffic."
canonical: "https://scalebrowser.net/blog/browser-use-alternative"
last_modified: "2026-10-07"
published: "2026-10-07"
author: "davide"
category: "infrastructure"
---
> ## Documentation Index
> Fetch the complete documentation index at: https://scalebrowser.net/llms.txt
> Use this file to discover all available pages before exploring further.
# browser-use alternative: 1 identity per profile
> browser-use compared with a fixed identity per profile: what Browser Use Cloud randomises per session, what a profile keeps, and 5 USD per GB of proxy traffic.
browser-use is where many agent projects start, and for a one-off task its cloud browser is quick to rent. The search for an alternative usually begins later, when the same agent signs in to the same account every day and the account starts asking questions. We read Browser Use's documentation, pricing and issue tracker on 27 September 2026 to see what stays the same from one session to the next, and what does not.
## What does browser-use offer?
browser-use offers two things under one name: an open-source agent loop and a hosted browser service. The loop is a Python library under the MIT licence that turns a task in plain words into clicks and keystrokes in a Chromium it drives over CDP; it had 116,468 GitHub stars on the day we read it. Browser Use Cloud rents the browser around it, with stealth, residential proxies and captcha solving switched on by default, and a profile feature that carries a login from one session to the next.
| Browser Use, as documented | Value |
| --- | --- |
| Open-source library | MIT licence, 116,468 stars, release 0.13.10 of 4 September 2026 |
| Browser time | 0.02 USD per hour, rounded up to whole minutes, 1 minute minimum |
| Residential proxies | 5 USD per GB, on by default, 195+ countries |
| Direct traffic or your own proxy | 0.20 USD per GB |
| Concurrent sessions | 10 at 0 USD lifetime spend, up to 1,000 at 25,000 USD |
| Fingerprint | canvas, WebGL, fonts and navigator randomised per session |
| What a profile keeps | cookies, local storage and login state |
The last two rows are the subject of this comparison. The open-source loop is not: it runs against any Chromium that exposes a CDP address, including one on your own machine.
## Why is a per-session fingerprint a problem?
A per-session fingerprint is a problem for every account an agent uses more than once, because the site sees the same login arrive from a different device each time. Browser Use's [stealth documentation](https://docs.browser-use.com/cloud/browser/stealth) states it plainly: "Canvas, WebGL, fonts, navigator, and other browser fingerprints are randomized per session to appear as a real user." For a one-off visit that is sound. For an account that signs in every day, it means a new device at every login.
A user measured it on 1 July 2026 and filed [issue 5119](https://github.com/browser-use/browser-use/issues/5119) on the browser-use repository. Two sessions started back to back on the same profile id returned two different, internally coherent devices:
| Axis | Session A | Session B |
| --- | --- | --- |
| Operating system | Windows | macOS |
| Graphics | Intel UHD | Apple M4 |
| Canvas, screen, core count, user agent | different from B | different from A |
The reporter's reasoning: "risk engines that score device continuity treat 'same login, brand-new device each visit' as a strong anomaly." The reporter called it the only thing keeping their company from moving its business to Browser Use, and could not send a fix, because "your [Chromium fork](/blog/chromium-fork) is not accessible".
On 2 August 2026 a collaborator of the repository answered in the thread: "That's already possible in our cloud. Profiles will maintain the fingerprint." On 27 September 2026 the issue was still open, the stealth page still said "randomized per session", and the [authentication guide](https://docs.browser-use.com/cloud/guides/authentication.md) listed what a profile persists as "cookies, local storage, and login state".
We have not measured Browser Use Cloud ourselves. Two sessions on one profile, compared on the [check page](/check), answer the question for your own account in a few minutes.
## How does a fixed identity per profile work?
A fixed identity per profile draws every value a page cannot verify from one seed stored with the profile, and reads every value a page can verify off the machine the browser runs on, at creation and again at every start. The split follows what a page can check, as the [profile documentation](/docs/profiles) sets out:
| Kind of value | Examples | Where it comes from |
| --- | --- | --- |
| Verifiable by the page | graphics card, screen size, pixel ratio | the machine itself, re-read at every start |
| Not verifiable by the page | timezone, locale, fonts, browser version, device memory | drawn from the profile's seed, the same at every start |
| Tied to the network | timezone and language | rewritten to the country the traffic leaves from |
Same seed, same values: the profile that signed in on Monday is the same device on Friday, and a profile moved to another machine of the same operating system adopts that machine's graphics card and screen at its first start there. The cost of that honesty is stated in the documentation too. Every profile on one machine shares that machine's graphics card and screen, because a claimed card that does not draw like that card is a contradiction a page finds with one comparison. The [local browser for AI agents](/blog/ai-agent-browser) guide walks through the layers a site reads, and why hardware claims are the ones it can test.
Moving does not mean giving up browser-use's loop. Its `Browser` object takes a `cdp_url`, and a started profile hands one out; the [browser-use migration guide](/docs/migrate/browser-use) shows the change, verified against release 0.13.10. The price model moves at the same time. Browser Use bills 0.20 USD per GB even for traffic through your own proxy, on its [pricing page](https://browser-use.com/pricing), while a browser on your own machine sends its traffic straight to your provider and is billed by how many browsers run at once, not by the hour or the gigabyte.
### Can Browserbase users move the same way?
Browserbase users can move the same way, because Browserbase code already drives a remote Chromium over a CDP connect address and a profile hands out the same kind of address. The session's connect URL becomes the profile's, the context becomes the profile, and the proxy moves onto the profile; the [Browserbase migration guide](/docs/migrate/browserbase) shows the three changes, and the [Browserbase alternative](/blog/browserbase-alternative) comparison sets out the six limits a hosted session carries for an agent.
## So which should you pick?
| Situation | Pick | Why |
| --- | --- | --- |
| A one-off visit, no account kept | Browser Use Cloud | nothing to operate, and a new fingerprint per session suits a single visit |
| You want the agent loop, not the hosting | the browser-use library | MIT licence, drives any Chromium with a CDP address |
| An account the agent signs in to every day | a fixed identity per profile | the same device at every login, on hardware that answers for it |
| Proxy traffic in gigabytes | your own provider, paid directly | 5 USD per GB for Browser Use's residential proxies, 0.20 USD per GB through your own |
| Hundreds of sessions and no machine to run them | Browser Use Cloud | up to 1,000 concurrent sessions, depending on lifetime spend |
Our verdict: for a single visit Browser Use Cloud is the quicker path, and for an account that has to look like the same device every day, a fixed identity per profile keeps the device constant. Until Browser Use's documentation says otherwise, measure two sessions on one profile before you trust either reading.