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:
| Session type | Threads | How it's chosen |
|---|---|---|
| Linux headless | 1 | headless set to a headless value for that browser |
| Linux headful | 2 | the default: a full display, harder to detect |
| Mobile WebView | 3 | real Android / iPhone WebView (early access) |
| Mobile Chrome | 4 | real Android Chrome (early access) |
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.
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 weighted like threads: a headful browser uses two browser-minutes per minute.
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. AwsUrlcan't be reused. inactivity_timeoutpasses with no traffic: 60 s by default. Shared sessions can lower it but not raise it; dedicated sessions can ask for up to 24 h.overall_timeoutis 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.