At a hosted browser provider, which bounds your parallelism: worker count or the account ceiling?

## The two numbers are not the same kind of thing A suite on a rented browser fleet sits between two limits, and the commonest error on this subject is treating them as one adjustable quantity that happens to be written down twice. - The **runner's worker count** is yours. It lives in your harness configuration or your pipeline definition, it is read by your own process at start-up, and it decides how many test workers exist — and therefore how many remote sessions your side will attempt to hold open at the same moment. - The **account ceiling** is the provider's. It is attached to the account whose credential your session requests carry, it is applied when the service decides whether to admit a new session, and nothing in your runner communicates a desired value for it. Nothing carries the first number across to the second. The provider does not read your configuration file, your pipeline YAML or your command line; it sees a stream of new-session requests arriving authenticated as your account, and answers each one on its own terms. That asymmetry is the whole subject of this question. | | runner's worker count | account ceiling | |---|---|---| | set by | you, in your own repository | the provider, against the account | | scope | this run, on this runner | every run using that account | | changed by | editing configuration | changing the account's arrangement | | raising it produces | more requests offered | more sessions potentially admitted | | what it really is | an offered request rate | an admission rule | ## Which of them binds Effective parallelism — sessions genuinely open and driving a browser at the same moment — is bounded above by both numbers at once, so it is bounded by whichever of them is lower. Neither "prevails" as a general rule; the smaller one is simply the one you can feel. Two consequences follow, and candidates usually get the first and miss the second: 1. When the worker count is the lower number, your suite is leaving entitlement unused. Widening the runner genuinely helps here, and this is the only case in which raising the local knob raises effective parallelism. 2. When the ceiling is the lower number, the surplus workers do not become extra capacity. They become requests that do not turn into sessions, and what the service does with them — hold them or refuse them — is a property of that service, not of your configuration. Effective parallelism can also be *lower* than both numbers for reasons that have nothing to do with either: sessions of unequal length leave workers idle at the tail of a run, a slow application under test means a worker spends its time waiting rather than occupying capacity, and another pipeline on the same account may already be holding part of the ceiling. ## Prepaid width is still a ceiling A common half-truth is that reserved or prepaid parallelism stops being a cap because it has already been paid for. It does not. Paying ahead changes what the width *costs* you to use; it does not change the fact that admission stops at the top of it. A suite sized above a reserved width runs into the same wall as a suite sized above any other ceiling, and it runs into it at exactly the moment everything is busy, which is the moment you notice least and care most. ## Establishing which one binds, rather than guessing Take the nightly regression suite for a grocery-delivery slot picker. You cannot read the provider's internal accounting and should not try to reconstruct it, but instrumenting your own side is enough: - Record, in the harness, the number of sessions your process currently holds open, sampled while the suite runs — not the number requested. - Compare that observed figure against the worker count you configured. - If the observed figure plateaus below the worker count while workers sit without a session, the binding limit is remote. - If the observed figure tracks the worker count exactly, the binding limit is local, and there is headroom you are not using. - Repeat the measurement when another pipeline is running, because the answer changes depending on who else is drawing on the same account. ## Why interviewers ask this It separates a candidate who has only ever turned a knob from one who understands that the knob is on the wrong side of a boundary. The wrong answer — "we raised the worker count and it got faster, so the worker count controls it" — is often *locally* true, because the account had headroom at the time. It stops being true the moment the account is the binding limit, and it stops being true silently. The self-operated implementations make the same shape readable, and the vocabulary is worth borrowing even though the products are not. Aerokube's Ggr, which declares itself unmaintained in its own README, keys its per-account entitlement by the authenticating user, so pipelines presenting the same account read the same entitlement — the account, not the machine, is the unit. You cannot read a hosted provider's console the same way, but the shape is the one to reason from until you have measured otherwise: entitlement attached to the identity, not to the machine that presents it. The practical instruction is short: size the worker count *against an established ceiling*, treat a raised worker count as a symptom rather than a fix, and never state a ceiling from memory.