AI browser automation on a runtime that does not wipe itself between runs
The demo run looks great; the batch run does not. Every start hands the agent a blank browser with no session, so long flows break on repeated sign-ins. Several tasks share one instance, cookies overwrite each other and the same prompt produces two different outcomes. Hosted agents share one exit, so pinning a proxy, timezone and language per task is off the table. NexBrowser supplies the missing layer: a dedicated profile and your own proxy per task, sessions that survive restarts, and a free local API that browser-use, Playwright MCP and your own agent all connect to.
Free tier: 1 member and 10 windows, no expiry. The local API is not billed separately.
One runtime for scripts and agents · headed or headless
AI automation that works in a demo but not in a batch
The agent solves "how to operate the page". What eats engineering time is session management and reproducing the runtime.
A blank browser on every start
The agent receives a fresh instance with no session, cookies or local storage. Any flow that needs a login is interrupted by sign-ins, captchas and second factors - and most of the token budget goes on logging in again.
Shared instances overwrite each other
Several agents in one browser trample each other’s cookies and localStorage, and A/B buckets and language settings bleed across. The same input yields different results, failures will not reproduce, and debugging becomes guesswork.
Throwaway instances keep nothing
Every run reloads resources and reconfigures fingerprint and proxy from zero. It is slow, and when something breaks there is no known-good previous state to compare against - only a full rerun.
Hosted agents share one exit
Managed services usually pool exit IPs, so you cannot pin a proxy per task or hold a timezone and language steady. Anything region-sensitive, or any account that should stay on one exit, hits a wall right there.
Five things the runtime has to solve once agents run in batches
The model makes decisions; the runtime makes those decisions land consistently. None of these five come from the model.
- 01
Persistent sessions and login state
Cookies, localStorage and cache have to survive between tasks and across restarts so the agent never opens a flow by logging in. Configuration should sync and export too, so moving to another machine needs no fresh setup.
- 02
Isolation per task
One profile per task or account, with storage, fingerprint and proxy independent and unreadable to each other. Run ten agents in parallel and the seventh failing leaves the other nine untouched - which is also what makes results comparable.
- 03
Proxy, timezone and language you choose
Bind your own exit per task with timezone and language aligned, so region-sensitive sites return the target region’s version. Keeping one account on one exit long term is also steadier than drawing a random exit each run.
- 04
Concurrency and resources under control
How many agents a machine runs comes down to RAM, CPU and window quota. The runtime should switch between headed and headless: visible pages while debugging, no graphics cost in a batch, concurrency set to what the machine can actually hold.
- 05
Observability and reproducibility
Run logs, failed steps and outputs must land on disk so a failure can be traced to a wrong model decision or a changed page. With the environment pinned, the difference between today’s run and next week’s is worth analysing.
NexBrowser does not replace your agent - it turns those five into a stable layer underneath it. For the scripting interface see local API automation, and for orchestration without code see no-code RPA.
Four things NexBrowser provides to AI automation
Persistent sessions, per-task isolation, standard connectivity, scheduling and export - configured once, reused for months.
Persistent sessions and login state
The login state your agent needs lives in the profile and persists across tasks and restarts. Cookies, cache and local storage are not wiped on close, and encrypted cloud sync plus import and export mean another machine picks up signed in.
A dedicated profile per task
One profile per task or account, each with its own 20+ fingerprint parameters, cookies, cache and local storage. Agents run in parallel fully isolated, and one failing task leaves the others’ state and progress intact.
Local API, not billed separately
The built-in local API is free with no call limit and speaks Selenium, Puppeteer, Playwright and WebDriver. Start a profile, take the CDP endpoint, and browser-use, Playwright MCP or your own agent attaches with a standard client - the script barely changes.
Scheduling, retries and result export
Replicate one flow across many profiles and run it on a schedule, headed or headless. Failed steps retry automatically, and run logs and outputs export to CSV or JSON for your existing pipeline.
Four steps to put your agent on a managed runtime
Get one real task working end to end, then copy the pattern to the rest.
- 1
Create the profile
Add one profile per task or account named "task + region", set its proxy, timezone and language, then sign in manually once so the session is stored. From then on the agent starts already signed in.
- 2
Start it and take the endpoint
Launch the profile through the local API and take its CDP or WebDriver endpoint. This replaces your usual launch() call - the difference is that the client owns the browser, with configuration and session already inside it.
- 3
Attach the AI framework
On Playwright: const browser = await chromium.connectOverCDP(wsEndpoint). On Puppeteer: puppeteer.connect({ browserWSEndpoint }). browser-use, Playwright MCP and screenshot-driven computer-use agents each point their own connection setting at the same endpoint.
- 4
Schedule and run
Replicate the flow across profiles, schedule batch runs with automatic retries on failed steps, watch the logs live, export results to CSV or JSON and alert only on genuinely abnormal runs.
For orchestration without writing code see no-code RPA, and for running public data collection on the same runtime see data collection environments.
Three reasons engineering teams pick it
Cheap to integrate, reproducible to run, predictable to bill.
Standard protocols, no architecture change
The local API speaks Selenium, Puppeteer, Playwright and WebDriver, and any CDP or WebDriver client can attach to a running profile. Existing scripts change how they connect, not what they do.
Environments that are real and reproducible
A real Chromium core with 20+ internally consistent fingerprint parameters means the same profile starts as the same device every time. Paired with persistent login state, agent runs finally have a basis for comparison.
Billed by window, not by call
The local API is free with no call limit and no per-request or per-token markup. 1 member and 10 windows are free forever, and extra capacity starts at 0.30 USDT per window per 30 days, so you scale with actual concurrency.
Test the integration cost with one real task
Download the Windows client and run one agent flow inside the 10 free windows.
AI browser automation questions, answered
What kind of browser does browser-use need?
browser-use handles reading the page and deciding the next action; what it needs underneath is a browser it can keep using - login state that survives a restart, its own storage and proxy per task, and a choice between headed debugging and headless batches. Point it at a profile endpoint started by NexBrowser and the page runs on a real Chromium core with the session already there, so the flow no longer contains a sign-in step.
How do I connect Playwright MCP to an existing browser?
Start the target profile through the local API, take its CDP endpoint, and have the Playwright side call chromium.connectOverCDP(wsEndpoint) instead of launching a new instance. The agent then drives the profile you configured: fingerprint fixed, proxy bound, session present. Puppeteer does the same with puppeteer.connect({ browserWSEndpoint }), and WebDriver clients attach over the standard protocol.
My AI agent signs in again on every run - how do I stop that?
The cause is a disposable runtime. Keep that account in a fixed profile, sign in manually once so the session is stored, and every later start opens already authenticated with cookies, localStorage and cache intact. Configuration also syncs encrypted to the cloud, so signing into the same team on another machine continues the work - and your flow no longer needs branches for login and verification codes.
Does the local API cost extra?
No. It ships inside the client, is free with no call limit, and is not priced per request or per token - the free tier includes it. What you pay for is concurrent windows and team seats: 1 member and 10 windows free forever with no feature gating, and extra capacity from 0.30 USDT per window per 30 days, scaled to the concurrency you actually need.
How many agents can one machine run at once?
It comes down to RAM, CPU and window quota. Each profile behaves like a separate browser instance: 8GB handles a dozen windows comfortably, 16GB more, and headless costs less than headed, which suits batches. Set a concurrency ceiling from what the machine actually holds and let the scheduler queue the rest rather than starting everything at once.
How does a hosted agent service differ from a local browser runtime?
Hosted services save you the deployment but usually pool exit IPs, leave little room to pin a proxy, timezone or language per task, and decide session retention for you. A local runtime is about control: the proxy is yours, configuration and login state stay on your machine with optional encrypted sync, and headed mode lets you watch exactly what the page is doing - which makes both debugging and compliance review far more direct.
Have other questions? We're here to help anytimeContact Support →
Related reading
- Local API automationFree, unlimited calls, standard framework support
- No-code RPADrag-and-drop flows and scheduled runs
- Built-in AI agentAI-driven page operation inside the client
- Data collection environmentsOne job, one environment, no cross-contamination
- AI tool accountsIsolating and sharing AI platform accounts
- Pricing10 free windows that never expire, scale by window and seat
Ready to manage every account profile in one place?
Install in 3 minutes. 10 free windows on sign-up, no credit card.
Free Download for WindowsAlready have an account? Sign in to the client to sync all profiles.