What is a hosted browser provider's session ceiling attached to, and what is it not attached to?

## The ceiling is a property of the identity, not of the run When a hosted browser provider enforces a limit on how many sessions may be open at once, that limit is attached to the **account** — the identity a new-session request authenticates as. It is not attached to the machine the request came from, the repository the test lives in, the pipeline that scheduled it, the branch, the suite, or the person who pressed the button. Every one of those can change without the ceiling noticing, and none of them can be used to carve the ceiling up. That has consequences that surprise teams the first time they meet them: - Every process presenting that account's credential draws on the same ceiling, including runs nobody on your team started. - A developer debugging one test from a laptop occupies exactly the same kind of capacity as a scheduled regression run. - Tools that are not tests at all — a smoke check, a dashboard that opens a session to take a screenshot, a half-finished experiment — count as tenants of the account too. - Adding a machine or a pipeline adds demand on the account; neither raises what the account may hold. - Splitting a suite across more runners redistributes where the requests come from without changing how many may be admitted. ## What you can observe, and what you must establish The honest position is that a tenant sees the outside of the mechanism only. You should be precise about the boundary, because an interviewer will push on it. | you can observe | you must establish, or leave unstated | |---|---| | how many of your own sessions are open at once | how the provider counts internally | | when your requests stop turning into sessions | whether a request in flight is counted | | how that changes when another pipeline runs | how enforcement is implemented | | what your own side asked for, if you log it | what the account's figure is meant to cover | "Establish" here means measure, or ask the provider and record the answer where the next person will find it. It does not mean assume. In particular, do not assume that a per-account figure printed somewhere is a simultaneous-session cap merely because it is a per-account figure: an account-level artefact can equally be a **catalogue of entitlement**, describing which targets the account may reach rather than how many it may hold. The open implementations make that distinction concrete. Aerokube's Ggr, unmaintained by its own README, keys a per-account quota document by the authenticating user; that document lists browsers, versions, regions and hosts the account may reach, its own documentation states that the per-host `count` attribute is a relative host weight for load distribution rather than a cap, and Ggr declares no concurrent-session ceiling of its own at all. A number on an account page is therefore not self-describing, and reading one as a cap without checking is a real and repeated mistake. ## Working the consequence Take a nightly regression suite for a grocery-delivery slot picker, sharing an account with the pull-request runs for the same repository. From the provider's side there is one tenant, not two. The arithmetic a team actually needs is: 1. Establish what the account admits, by observing concurrently-open sessions during a run that is deliberately wide. 2. Enumerate everything that authenticates as that account, including the things that are not pipelines. 3. Treat the sum of those claims as the quantity that must fit, and give each claimant a declared share rather than a default the runner chose for itself. 4. Re-run step two whenever someone adds a pipeline, because that is when the sum silently changes. ## Why this is a must-know Capacity surprises on a rented fleet very often trace back to this property. A suite that was comfortably inside the ceiling in isolation is outside it the moment a second consumer appears, and because the ceiling belongs to the account rather than to either consumer, neither one's configuration shows any sign of the problem. The failure is visible only where the two overlap in time, which is why it so often looks intermittent and gets filed as flakiness. Stating the property correctly is also a guard against a whole family of wrong fixes. Moving the suite to a bigger runner, sharding it further, or running it on a different CI service all change where the requests originate and none of them changes what the account is allowed to hold. Two levers actually move the situation: changing the account's arrangement with the provider, and changing what your own side asks for — its width, its timing, and how promptly it releases what it holds. The first is a commercial conversation; the rest are entirely in your hands.