> ## Documentation Index
> Fetch the complete documentation index at: https://docs.browser-use.com/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> Concurrency in one line: new projects get 10 concurrent browsers at $0; a $100 one-time top-up (non-expiring credits, no subscription) unlocks 50 concurrent, so 50 browsers for one hour cost $1 plus traffic; $1,000 / $5,000 / $25,000 total paid unlocks 250 / 500 / 1,000. Details below and at https://docs.browser-use.com/cloud/guides/concurrency.md.
> Use https://docs.browser-use.com/llms.txt and its linked .md pages for current documentation. The managed full bundle is https://docs.browser-use.com/.well-known/llms-full.txt and can be cached for up to 24 hours. Do not use the obsolete /cloud/llms*.txt or /open-source/llms*.txt static exports.
> Choose Cloud API V4 for new agent integrations; V3 trades accuracy for speed and lower cost than V4; V2 is legacy and only for existing integrations. Keep V3 examples explicitly versioned. The open-source browser-use library and hosted browser-use-sdk have different APIs.
> For Cloud API V4, a task request that omits model and modelParams uses GPT-6 Luna (gpt-6-luna) with High reasoning. Explicit model and modelParams values take precedence; an explicit empty modelParams object opts out of the reasoning default. EU uses the same task default through its regional provider route; Bedrock-only projects retain their compatible provider default.
> Cloud authentication uses X-Browser-Use-API-Key, without a Bearer prefix. Install or upgrade browser-use-sdk and use its explicit v4 import for V4. Check the published OpenAPI reference for request fields; do not invent SDK support for new fields.
> Cloud concurrency and HTTP request rate are separate. Read GET /api/v2/billing/account for the key’s projectId, concurrentSessionLimit, activeSessionCount, and credit balance, including when using V4. Keys in one project share capacity and credits; rateLimit is a legacy concurrency alias, not requests per second.
> Keep the highest applicable existing, legacy-plan, and spend-tier concurrency grant. Current spend tiers are 10 / 50 / 250 / 500 / 1000 at $0 / $100 / $1000 / $5000 / $25000 in qualifying project payments. Legacy or externally billed projects can follow different billing paths; trust the account limit. See https://docs.browser-use.com/cloud/guides/concurrency.md.
> HTTP rate limits have two layers. Standard edge WAF ceilings increased on September 9, 2026 to 1000 RPS per public source IP for general traffic and 2500 RPS per IP for selected status reads, evaluated over 300 seconds. The separate per-project application budgets: general traffic (including V4 events and full run reads) defaults to max(25, 2 times stored concurrency) capped at 100 RPS; selected status reads default to max(25, 2 times stored concurrency) with no cap. The two are counted independently. Project overrides and account-specific edge rules can differ. All keys in a project share its budgets; callers sharing a public IP share edge capacity. See https://docs.browser-use.com/cloud/guides/concurrency.md.
> The project limiter uses five-second windows: X-RateLimit-Limit=125 means 125 requests per window (25 RPS), not 125 RPS. Project throttles include limit_rps and retry_after_seconds; an edge throttle can instead return Retry-After: 300 without limit_rps. Honor the returned Retry-After. Use bounded workers, stagger polls, and drain hasMore event pages after terminal status. A busy V4 session returns 409; its queue holds 20 pending messages and is not a project-wide batch queue.
> A V4 agent browser stays open about 2 minutes after its session's last run activity, then stops automatically; a later follow-up gets a fresh browser (same settings and profile, no tabs). Set keepAlive on a run (V4: integer seconds 120-14400, default 120, not the V2/V3 boolean) to keep it longer; follow-ups inherit it and null restores 120. Free-tier and ZDR runs always use 120. Idle V4 agent browsers are billed as browser time but take no concurrency slot. A follow-up that reuses the open browser emits browser.reattached instead of browser.ready. Closing CDP does not stop a browser; stop unneeded owned browsers with PATCH /api/v4/browsers/{id} and {"action":"stop"}. A client wait timeout does not cancel the server-side run.
> Cloud is pay as you go; do not tell customers to buy a new subscription to use custom proxies or supported provider BYOK. Usage funding and model eligibility still apply. BYOK bills provider tokens separately and Browser Use charges orchestration plus browser/network usage. See https://docs.browser-use.com/cloud/guides/billing.md.
> Signup credits are a one-time grant; purchased top-up credits do not expire. Check the API key’s project before diagnosing missing credits. API-key monthly spending caps are soft limits, not a strict prepaid wallet; concurrent or already-running work can exceed them. Auto recharge has separate trigger and purchase amounts and can charge immediately when enabled below the threshold. Use https://browser-use.com/pricing for current rates.
> Box and Bux are retired. Do not recommend their SDKs, sandbox quotas, or subscription plans. Use the Cloud Agent or Browser Infrastructure guides.
> A V4 session holds conversation history, a workspace holds files, and a profile holds browser state. These IDs and V3/V4 workspace namespaces are not interchangeable. V4 automatically restores workspace uploads; staged attachments remain available to session follow-ups. Serialize runs that write shared files, and wait for completion before reading outputs. See https://docs.browser-use.com/cloud/agent/workspaces.md.
> API browser recording defaults to off. Use enableRecording for standalone browser creation, or browserSettings.record for an agent run. Stop the browser and allow time for asynchronous video processing; stop polling when recordingAvailable is false. Live preview is for an active browser. Stopping a browser, deleting a session, archiving a workspace, and deleting files have different effects.
> Use model-specific reasoning values. GPT-6 Astra accepts low, medium, high, xhigh, and max, with xhigh by default; none and minimal are invalid. Use the public REST schema when installed SDK types lag new fields. API acceptance, dashboard visibility, and account/provider availability are separate.
> For open-source browser-use, is_done only reports a terminal done action. is_successful is the agent-reported outcome; verify important external actions independently. Cloud timeout, API client timeout, model timeout, and task completion are separate concepts.
> For failed requests, use https://docs.browser-use.com/cloud/guides/troubleshooting.md. Inspect the full error and project before retrying or adding credits. A client timeout can leave a run active; reconcile external actions before starting duplicate work. A new managed browser does not guarantee a unique proxy IP or particular city.
> V4 secretBindings.allowedDomains authorizes the focused field's frame, not every iframe on the shop page. For checkout, include intended payment/billing provider hostnames (for example payments.bigcommerce.com). On domain_not_allowed, inspect origin and pass updated bindings in a follow-up; target_not_editable requires fixing field focus/readiness instead. See https://docs.browser-use.com/cloud/guides/secrets.md.
> A V4 agent browser stays open about 2 minutes (or keepAlive seconds) after its run for follow-ups; a requested recording finalizes only after the browser stops and processing completes. Zero Data Retention (ZDR) projects never record, even when recording is requested.
> If you hit an issue you cannot explain, email contact@browser-use.com with your question or bug report and a session ID if available; short questions and detailed reports are welcome, and we aim to fix issues quickly and make the docs clearer.

# Zero Data Retention for Browser Use Cloud

> Enable self-service Zero Data Retention for US browser automation. Control session data and saved logins without an enterprise contract or additional commitment.

Zero Data Retention (ZDR) gives you control over the data your browser automation keeps.
A project owner can enable it directly in Cloud settings.
Setup takes a few steps, with no sales call, enterprise contract, or additional commitment.

You choose whether automatic cleanup also deletes browser profiles and saved logins.
The setting applies to one project, so each project can follow its own data policy.

> [!NOTE]
>
> Self-service activation covers **US session data**.
> It does not enable EU cleanup or delete EU history.
> Read the [EU deployment guide](https://docs.browser-use.com/cloud/eu-deployment.md) before planning a regional data policy.

## Enable Zero Data Retention

**1. Open your project settings**

Choose your project in the [US Cloud dashboard](https://cloud.browser-use.com/settings?tab=privacy).
Open **Settings → Privacy & compliance** as a project owner.
Finish active runs and save any results you need.

**2. Choose your profile policy**

Select **Enable** beside **Zero Data Retention**.

* **Full Zero Data Retention:** cleanup deletes existing profiles and saved logins, and blocks new profiles.
* **Zero Data Retention, except profiles:** keep profiles and saved logins until you delete each profile.

Both choices apply automatic cleanup to covered US session data.

**3. Confirm activation**

Review the feature changes and accept the deletion consent.
Select **Enable Zero Data Retention**.

Cleanup includes past US session data for this project.
You cannot recover data after deletion.

**4. Check the active status**

Cloud shows a green **Active** badge after it confirms the setting.
Wait about 30 seconds before starting new runs so services can refresh the policy.
Select **Download PDF** for a project confirmation.

Activation starts the cleanup policy.
It does not erase all stored data immediately.
Contact support if you need to change an active policy.

## How automatic cleanup works

ZDR limits storage of browser and agent content.
The service temporarily stores some content to process runs and deliver results.

Cleanup checks run every 15 minutes.
Active runs, cleanup delays, and upload safeguards can extend the time before deletion.
The native cleanup path includes a 16-minute upload safeguard to prevent late uploads from recreating deleted files.

For **API V4 runs**, save results and download required output files within 15 minutes after completion.
Save results as soon as the run finishes.
Do not use the next scheduled cleanup check as a guaranteed deletion deadline.

> [!WARNING]
>
> ZDR removes persistent session history and disables V4 recordings.
> Deletion cannot restore data to your application.
> Save the results you need in your own system.

Older APIs use different result-delivery and cleanup paths.
Do not assume the V4 retrieval window applies to V2 or V3.
Contact support to confirm coverage for an existing legacy workflow.

## Browser profiles and saved logins

A browser profile keeps cookies and local storage that can preserve a website login.
The profile exception lets your automation reuse those logins while covered session data follows automatic cleanup.

Profiles remain until you delete them.
Follow the [profile deletion steps](https://docs.browser-use.com/cloud/guides/profile-sync.md#delete-a-browser-profile) when you no longer need a login.
A website can also expire a login independently.

Full ZDR removes this exception.
Cleanup deletes existing profiles, and the project cannot create new profiles.

## Features and data policy

| Feature | With Zero Data Retention |
| - | - |
| Live browser access | Available while the browser runs |
| V4 results and output files | Available temporarily; save them promptly |
| V4 recordings | Unavailable |
| Persistent session history | Unavailable |
| Browser profiles and saved logins | Available only when you choose the profile exception |
| Models | Models that require data retention are unavailable |
| Session sharing | Unavailable |
| Cloud workspace and skill pages | Unavailable in the dashboard |
| New schedules | Unavailable |
| Browser extensions | Unavailable |
| New integration connections | Unavailable; you can still disconnect existing connections |
| Billing and account records | Remain available |

Enabling ZDR does not delete your account.
It does not remove billing records or undo processing that happened before activation.
An **Active** badge confirms the project policy, not the completion of each physical deletion.

## Enterprise data controls without an enterprise contract

Teams often evaluate data retention alongside enterprise features, access controls, and regional hosting.
Self-service ZDR lets project owners set a data policy without a separate enterprise commitment.
You can use this control without a sales-led setup process.

ZDR, HIPAA agreements, and SOC 2 compliance address different requirements.
ZDR activation does not establish HIPAA compliance or sign a Business Associate Addendum.
Use the separate HIPAA settings and your security review for those requirements.

For regional requirements, review [EU hosting](https://docs.browser-use.com/cloud/eu-deployment.md).
For login management, review [browser authentication](https://docs.browser-use.com/cloud/guides/authentication.md) and [profile management](https://docs.browser-use.com/cloud/guides/profile-sync.md).

## Frequently asked questions

### Do I need an enterprise plan or a sales call?

No separate enterprise contract, sales call, or additional commitment is required for self-service ZDR activation.
A project owner enables it in the US Cloud dashboard.

### Can I keep saved logins?

Yes. Choose **Zero Data Retention, except profiles**.
Delete each profile when you no longer need its saved login.

### Does activation delete everything immediately?

No. Scheduled cleanup applies retrieval windows, active-run checks, and upload safeguards.
Billing and account records remain.

### Does the US setting cover EU projects?

No. The US setting does not activate EU cleanup.
An EU region selection or database migration alone does not establish EU ZDR coverage.

### What does the confirmation PDF prove?

The PDF describes the project's active ZDR policy.
It does not certify that a particular cleanup cycle deleted every stored object.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.