Sessions & billing

Threads

Your plan gives you a number of threads — concurrent capacity for running browsers. Each session takes one or more threads depending on its type:

The launch response tells you the session's resource_class and weight. If a launch would take you over your threads, it's refused with 429 threads_exceeded until a session closes.

More memory: "memory": 2, 3 or 4 multiplies the session's memory limit and its threads by that number — a headless session with "memory": 2 takes 2 threads and twice your plan's memory, a headful one 4 threads. Use it for memory-heavy pages instead of splitting the work (memory option).

Launch rate: threads ÷ 5 launches per second and threads × 6 per minute, at least 2 and 10; dedicated threads get twice that. Above it a launch returns 429 rate_limited with Retry-After. For many short pages, keep one session and open a fresh context per page instead of launching a browser each time.

Dedicated and shared threads

Shared threads are pooled capacity for bursty and scheduled work. Each purchased thread contributes browser-minutes per day to your shared account pool (60, 120, 240 or 480, by product), and at most 25% of the daily pool can be used in any rolling 60 minutes. Dedicated threads are reserved capacity for continuous use, with no daily or hourly limit. Both let you run as many browsers at once as you have threads. See Plans & pricing.

Minutes are counted per thread, like threads themselves: a headful browser takes 2 threads, so each minute it runs uses a minute from each of them. That is no extra charge, only the minutes of the second thread it occupies.

Shared leases

Shared sessions run on 15-minute leases that renew automatically while shared capacity allows — a lease is not a time limit, and a session is never restarted on purpose. Only when the shared fleet is full and other shared launches are waiting may the longest-running shared sessions not be renewed at their next 15-minute mark. Such a session ends with reason lease_reclaimed: its browser is terminated and its slot released. Browsers are never reused between customers. Dedicated sessions have no leases.

Metering

• Usage is thread-seconds: threads × seconds. A headful session running 3 min 12 s uses 6 min 24 s of thread time. Nothing is rounded up.
• The clock starts when your browser is ready (the launch response) and stops when either side closes the WebSocket.
• A session you never connect to ends after 60 seconds and is metered until then.
• If you try to connect and our server doesn't accept the connection, that session isn't billed at all.
• The shared daily pool resets at midnight UTC, with no carry-over. A session running over midnight is split between the two days.
• The rolling-hour limit looks at the last 60 minutes at any moment, not at clock hours.

When a session ends

• You call browser.close() or your client disconnects — the session ends at once. A wsUrl can't be reused.
• inactivity_timeout passes with no traffic: 120 s by default. Ask for up to 10 minutes on shared threads, 5 on Community and 24 h on dedicated; idle minutes are billed like any others.
• overall_timeout is reached, capped by your plan's maximum session length (24 h) and, for shared threads, your remaining daily minutes.
• You or an admin ends it from the dashboard or the Account API, or your shared daily or rolling-hour pool runs out.
• A shared lease is not renewed because the shared fleet is full (lease_reclaimed, see above).

Your usage and every session's start, end and duration are in the dashboard and the Account API.