Help Center

Yes. With Lexmount, page loading and page scripts run in cloud browsers. This reduces that part of the CPU and memory workload on your computer and saves you from deploying your own browser server. Run your first cloud browser task.

Your Agent or application controls the browser through a remote connection. Start by moving one complete task, check that its interactions and results work as expected, then increase the number of tasks running at once.

Your Agent or application still needs somewhere to run. If you want tasks to continue after turning off your computer, the controlling program must also run in an environment that stays online.

Start with browser creation, connection, and cleanup, then validate your existing page interactions. For Chromium, you can connect to Lexmount using Playwright’s CDP connection. View the Node.js quickstart.

1. Create a Lexmount Chromium session and obtain its connection URL.
2. Connect using chromium.connectOverCDP(session.connectUrl), then run your existing interactions in that browser session.
3. Verify the complete workflow and explicitly close the cloud session after success, failure, or cancellation.

Migrate one task before scaling up. CDP differs in capabilities from a native Playwright connection, so check special APIs, extensions, and file operations separately. Files downloaded in the cloud also need to be retrieved through the download API.

You can run multiple cloud browsers at the same time. Current public plans have limits of 3, 25, 100, and 250 concurrent browser sessions. Check the pricing page and your current project for the applicable limit. Compare concurrency plans.

For example, with 500 independent tasks and a project that allows 25 concurrent sessions, your program can start up to 25 sessions at once. As each task finishes and releases its slot, the program can start another. Your program or Agent is responsible for scheduling and continuing the tasks.

Keep the two allowances separate when choosing a plan: concurrency determines how many browsers can run at once; Browser hours is your available browser time. You can process more tasks than your concurrency limit, and that limit is not a guaranteed speed multiplier.

Give each parallel task its own browser session. Your program controls how many run at the same time and releases each slot when its task finishes. Learn how to create and manage sessions.

1. Turn the single-task workflow into a repeatable operation that creates its own Session each time it runs.
2. Limit the number of simultaneous tasks using the project’s concurrency limit and its existing active sessions.
3. Record each result, try to close the task’s session after success or failure, then start the next task.

When login is required, use a separate Context for each account and use the same Context in read-write mode sequentially. If several tasks modify the same record on a website, your program also needs to coordinate their order.

Browser hours and concurrency slots are separate limits. You may have browser time left but be unable to create another browser because your active sessions have reached the concurrency limit. View active sessions.

1. Make sure you are checking the same project, then compare its concurrency limit with its active sessions.
2. Look for sessions whose tasks have finished but which were never closed. End the sessions you no longer need.
3. Try creating a session again once a slot is released. If tasks can run in batches, reduce your program’s parallelism. Choose a higher-concurrency plan if you really need more sessions running at once.

For example, if your project allows 25 concurrent sessions and all 25 are active, you need to release a slot even when Browser hours remain. If active sessions are below the limit but you still receive the same message, keep the error details for further investigation.

When a website needs a QR scan, verification code, or human confirmation, you can complete login yourself and let your Agent continue in the same cloud browser. A persistent Context can save that login state for later tasks, reducing repeated logins and manual intervention. Use the persistent login template.

For example, you may need to read data from an authorized business dashboard every day. On the first run, log in through the live view and let the Agent read the data, then save the browser state when the task ends. The next day, the Agent creates a new session with the same Context, checks whether it is still signed in, and continues the task.

A Session is a running browser instance. A Context stores cookies and browser storage for reuse across sessions. This workflow requires Chromium and persistence permissions in your current project.

1. Create a persistent Context and attach it in readWrite mode when creating a Chromium Session. Keep the Context ID so later tasks can reuse the same Context.
2. Have the Agent open the target website, then pause automation while keeping the session active. Open that session’s Remote View and complete the QR scan, verification code, or other login steps yourself.
3. Confirm that the correct account is signed in, then tell the Agent to continue in that Session. Take turns controlling the page so human and automated clicks or typing do not interfere.
4. After the task, close the cloud Session normally through the SDK or session management so browser state is written back to the Context. Wait until the Context is available before starting the next task.
5. For the next task, create a Chromium Session with the same Context ID and check whether the website is still signed in. Continue if the login is valid. If it has expired or the website requires verification, take over to log in again, then resume automation.

You can handle the steps that need human confirmation while the Agent completes the remaining browser work. You also do not need to keep the same browser session running just to retain a login: browser state is saved, and the next task creates a new Session.

Multiple active sessions cannot read and write the same Context at once, so reuse it sequentially for the same account and use separate Contexts for different accounts. The website still controls login expiry and verification requirements. The current Browser playground does not attach a persistent Context; use the templates or SDK Context workflow to save login state across tasks.

You can log in through a Chromium session that supports live interaction, then let your Agent continue in the same session. Your Agent or script needs to wait while you work so that both do not interact with the page at once. Learn how to connect a Chromium session.

1. Create a Chromium session and open its live page in Remote View.
2. Pause automated interactions, keep the session active, and complete the website’s login or verification yourself.
3. Once login is complete, let the Agent continue its task in the same session.

To reuse the login in a later task, attach a persistent Context when creating the session and close the session normally when finished. The current Browser playground does not attach a persistent Context, so it cannot directly save this login for your next task. Use the SDK’s Context workflow when you need persistence.

A persistent Context lets later tasks reuse saved login state, reducing repeated logins. This requires Chromium and persistence permissions in your current project. Learn how to save login state.

1. Create a Context and attach it when creating the browser session.
2. Log in and complete the task in that session. Close it normally afterward so its state is written back to the Context.
3. Wait until the Context is available again, then use it to create the next session.

A Context saves cookies, browser storage, and related state. Whether the login remains valid depends on the website. You may need to log in again if it expires or verification is required. The current Browser playground does not automatically save a Context for reuse in later tasks.

Use a separate Context for each account and an independent Session for each parallel task to keep browser state and page interactions separate. Explore Contexts for multiple accounts.

For example, attach account A’s tasks to Context A and account B’s tasks to Context B. Give Contexts clear names or descriptions, check the account mapping before starting a task, and close sessions normally afterward to save their state.

Persistence requires Chromium and the appropriate plan permissions. Multiple active sessions cannot read and write the same Context at once; tasks that reuse it for the same account should run sequentially. You still need to account for the website’s account restrictions and coordinate tasks that modify the same business record.

An active session is usually reading and writing that Context. Check the session using it, wait for it to end normally, and use the Context again once it becomes available. Check the session using the Context.

1. Use the occupancy message to identify the session and check whether it is still working.
2. If it is working, wait for the task to finish. If it is no longer needed, close it normally through session management or your program.
3. Wait until the Context status is available before creating a new session.

If you need an independent copy, you can fork the Context through the SDK while it is offline and available. Do not force-unlock a Context that is still in use. If its session has ended but the lock remains, contact support for further investigation.

Start by checking the current browser page alongside your Agent or script’s output. If the session is still running and live view is available, you can open it from session management. Check your sessions.

1. Check whether the page is waiting at login, verification, loading, or a particular interaction.
2. Compare the execution output, error messages, and last action to narrow down the cause.
3. For Chromium sessions with persistent replay enabled, you can also review a successfully generated replay in the session details after the session ends.

Moli does not provide persistent replay. A Chromium replay may still be processing, may have failed to generate, or may have passed its retention period. Before retrying, check whether the previous action already took effect, especially when submitting forms or creating records.

A cloud browser session may remain active after code finishes or a connection closes, so it needs to be ended explicitly. In the Browser playground, completing a code run does not close the session. Click Stop when you no longer need it and confirm that it has ended. Check active sessions.

In the playground: click Stop when you no longer need to view or interact with the page.

With the SDK: put session.close() in a cleanup path such as finally so closing is attempted after success, failure, or cancellation.

If your program exits unexpectedly: sign in and check the current project in session management. Close sessions you no longer need and confirm they are no longer active.

If closing fails, check the session’s actual status before retrying. Ending sessions promptly releases their concurrency slots.

A useful RAG knowledge base starts with text worth retrieving. Lexmount WebFetch can extract the main text, title, and source URL from public webpages so you can check the content before adding it to your knowledge base, with less work building your own fetching and parsing pipeline. Start with the webpage-to-JSON template.

Suppose you are building a question-answering assistant from product documentation, tutorials, or industry articles. Converting the entire HTML page to text can bring navigation, footers, and repeated recommendations into your knowledge base. A regular HTTP request may also miss text loaded by JavaScript. Start by fetching and extracting the page with WebFetch, then check whether main_text contains the information your users will ask about.

1. Choose a few representative public URLs, such as a long article, a documentation page, and a page that loads content dynamically. Validate extraction on these examples before adding more URLs.
2. Call POST /v1/extract with the webpage address in extract.url. Read result.main_text as the candidate body text and retain source metadata such as result.title and result.final_url. You can also try the same request in the WebFetch playground first.
3. Check the text before ingestion: are key paragraphs complete, is the result empty, and does it contain navigation or repeated content? If something looks wrong, use POST /v1/dom/dump to inspect the fetched page and final URL for unloaded content, redirects, or a login page.
4. Split the checked text into chunks by paragraph or section, then generate embeddings and store them through your RAG pipeline. Keep the source URL and title with each chunk so answers can cite the original page and you can investigate errors or update content later.
5. Try a few real questions, such as “What are the requirements for using this feature?” Compare the retrieved text with the original page to check that the needed information was extracted and ingested before expanding to more pages.

For documentation Q&A, a complete workflow could be: public documentation URL → WebFetch extraction → review and chunking → embeddings and storage → retrieval with source citations. The webpage-to-JSON template below provides a starting point for extraction that you can connect to your existing knowledge base.

WebFetch handles webpage fetching and extraction; your RAG system handles chunking, embeddings, storage, and retrieval. Results vary by website, and extraction cannot guarantee removal of every navigation element or advertisement. For content that requires login, clicks, or forms, use Cloud Browser to complete those interactions first.

You do not need to start by writing rules for each website. Give WebFetch the URL of a publicly accessible page to try extracting its main text, title, and other content without building your own fetching and parsing workflow. Try your own webpage.

In the playground, select POST /v1/extract, enter your URL, and check whether main_text contains the content you need. Try a few representative pages before integrating it into batch tasks.

Results depend on page structure and the content that can be fetched. Fields such as author and publication time may be missing. To inspect the page that was actually fetched, switch to POST /v1/dom/dump and review its HTML.

You can try WebFetch’s on-demand rendering for public pages before extracting their content. Some pages load their main text through JavaScript after opening, so it is missing from the initial HTML returned by a regular request. Learn how to fetch dynamic pages.

Run extraction with your URL in the playground. If content is still missing, switch to POST /v1/dom/dump to inspect the HTML that was actually fetched. To choose a rendering engine, use the API settings described in the documentation.

Rendering results still depend on how the page loads. If you must log in, click a button, or fill out a form to see the content, use a cloud browser to complete those interactions.

Fetching HTML can still result in empty extraction if the main content has not loaded, the page redirected, or the content could not be extracted or validated. Work through these checks in order. Troubleshoot extraction results.

1. Switch to POST /v1/dom/dump in the playground. Check whether the HTML contains the main content and whether the final URL is correct.
2. If the content is present, check the extraction response for errors. For more detail, enable trace through the API to inspect processing steps, or use dom_id to extract again from the same page snapshot.
3. Keep the target URL, request_id, and error details. If the issue remains unresolved, share this diagnostic information with support after removing credentials and sensitive page content.

Run a small, representative batch of real tasks and check actual browser usage. Choose a plan based on your expected task volume and the concurrency you need. View plans and pricing.

1. Choose tasks that cover typical pages, logins, and interactions. Record Browser hours used before the trial. Keep other tasks out of the project during the trial where possible so their usage does not affect the comparison.
2. Complete the tasks and close their sessions. Once usage updates, compare the consumption and record any failures and retries.
3. Estimate the browser time needed for your expected workload, then check that the plan’s concurrency limit and feature permissions meet your requirements.

Page loading, login waits, and retries affect task duration, so leave some room in your budget. If you use a model API you configure separately, include its costs too.

Unused Browser hours included in a plan expire at the end of its period. Separately purchased WebFetch balance carries over to later periods. Check your regional page for prices and purchase options.

A WebFetch pack is a one-time purchase of extra requests for the selected project, billed separately from the plan rather than as a fixed monthly fee. Requests use the plan allowance first, then the purchased balance. Purchased requests never expire, do not reset with the plan period, and remain usable after switching to Free. View project usage and WebFetch packs.

Who can buy: projects currently on Pro, Pro+, or Enterprise can purchase packs. Free projects must upgrade to a paid plan before buying a new pack. Confirm the selected project in Plans & Usage before purchasing. The extra requests become available to that project once payment is complete and the allowance is credited.

Pricing: pack prices depend on the selected project’s current plan. Check the latest purchase quote for available pack sizes and amounts. After changing plans, future purchases use the new plan’s pricing; refresh any old quote and confirm it again.

Usage order: each request uses the current period’s included allowance first. Only after that allowance is exhausted do requests consume the purchased balance. When a new period provides an included allowance, that allowance is used before any carried-over pack balance.

Balance validity: unused purchased requests never expire and do not reset monthly or at the end of a plan period, so they carry over to later periods. If the paid plan expires or is downgraded and the project switches to Free, its existing balance remains usable. Free only prevents purchasing new packs.

What a pack adds: WebFetch requests only. It does not increase Browser hours, browser concurrency, or plan feature permissions. Plan charges and pack charges are separate costs.

Example: buy 100,000 requests, exhaust the included plan allowance, then use 24,000 requests from the pack. The remaining 76,000 carry over to later periods and remain usable even if the project switches to Free.

Yes. Use your project’s free allowance to run a real task and check whether it can be completed before deciding how much time, concurrency, and functionality you need. Start with your own task.

The current public Free plan includes 1 Browser hour and up to 3 concurrent browsers; check your project for its actual allowance. Start with one complete workflow and check that the page opens, key actions finish, the result meets your needs, and the session closes properly afterward.

The free allowance is intended for small trials. Features such as persistent Contexts require the appropriate plan permissions. If your task depends on these features, check that the plan includes them.