Session lifecycle and cleanup
Session lifecycle and cleanup.
Creation is asynchronous
SDK creation normally reserves a session and polls until it is active. The default activation timeout is 600 seconds. A timeout can occur after a session ID has been allocated: inspect the exception and console before retrying, otherwise you may create duplicate billable sessions.
Automatic CAPTCHA processing
Automatic CAPTCHA processing is a per-session option and is disabled by default. In the console, select “Enable automatic CAPTCHA solving” when creating a Chromium session. With the SDK, use enableCaptcha: true in Node.js or enable_captcha=True in Python.
Both SDKs and the console send the same enable_captcha field to the session creation API. The service then detects and processes CAPTCHAs for that session automatically; other sessions in the project keep their own preferences. Availability and usage remain subject to the project plan and remaining CAPTCHA allowance.
See Node.js Capabilities and Python Capabilities for examples.
One use is deducted when a CAPTCHA task is successfully filled into the page. Detection, failed tasks, and tasks that are not filled do not deduct a use. Successful fill-in does not guarantee the target website's final acceptance; a page may present additional challenges.
An in-progress task temporarily reserves one use until its result is settled. A timeout or unknown result can therefore leave a use reserved while processing is still pending.
Separate CAPTCHA packs are not currently available, and no automatic overage charge is applied. After the allowance is exhausted, upgrade the plan or wait for the next usage period. The project's current eligibility and available allowance are checked before processing.
Always release both resources
The automation connection and the cloud session are separate resources. Disconnecting Puppeteer or closing the Playwright connection is not a substitute for closing the Lexmount session. Use nested try/finally blocks so a connection-close error cannot skip session cleanup; close the HTTP client last. The complete Playwright example shows this order.
Session close can begin asynchronous shutdown. If a Context is still locked, wait for final session closure and Context availability before reusing or deleting it. The Node SDK's session.close() logs some close failures rather than throwing them; for critical cleanup, verify the final session state through the console or session API. Do not treat a returned promise as proof of remote teardown.
Bound concurrency
Limit simultaneous sessions to your project's entitlement and available quota. A worker should acquire a slot, create a session, do bounded work, close it, and release the slot. Retry transient transport errors with bounded backoff; do not blindly retry create calls, authentication failures, or operations that submit a form/payment. A process kill can bypass finally: reconcile your own recorded session IDs before restarting jobs.
For Context-backed work, see persistent contexts. For retention and billing, see capabilities and pricing.
Manage sessions in the console
Create a session with the available browser and resource options, filter session records, and wait for the active state before connecting. Use Stop to release a session when finished.
Live session board
Open the live board to monitor active sessions together. Preview availability depends on session state and browser support; an unavailable preview alone does not prove the session has stopped.
Inspect a session
Open a record in the session list to inspect its state, connection information, and available recording or debugging actions. Keep authenticated connection URLs private. The link below returns to the list so you can choose the relevant session.