Cloudflare Browser Run Raises Concurrency to 200: Budget the Queue, Not the Limit

A higher browser concurrency limit creates capacity, not savings. Cloudflare Browser Run's new defaults can reduce queue delay for large coding-agent fleets, but teams still pay for sessions, downstream APIs, model reasoning, retries, and human review. The budget question is how many verified browser tasks finish per dollar at the concurrency you actually sustain.

Cloudflare's August 20 Browser Run update raises Workers Paid defaults from 120 to 200 concurrent browsers, from one to three new browser instances per second, and from 10 to 30 Quick Actions requests per second. Cloudflare says these are defaults rather than maximums. Those published limits describe admission capacity; they do not establish the cost or reliability of a particular workload.

Separate Three Bottlenecks

Measure concurrency, launch rate, and action rate independently. Two hundred long-lived sessions may be available while a burst still waits behind a three-per-second launch gate. A screenshot-heavy test fleet may hit the Quick Actions rate without approaching the session limit. One utilization percentage hides which resource is delaying work.

Instrument enqueue time, browser start time, first useful action, completion, cancellation, and retry. Join those timestamps with model calls and the repository task. Then report p50 and p95 queue delay rather than a monthly average. Browser-agent traffic is bursty around pull requests, releases, and scheduled tests, so tail latency determines whether developers wait or launch duplicate work.

Model a Real Burst

Suppose a release creates 180 browser checks at once and each session lasts four minutes. The 200-session ceiling can hold the cohort, but at three new instances per second the last session starts about one minute after the first. That delay may be acceptable for background validation and unacceptable for an interactive fix loop. A larger ceiling does not remove launch sequencing.

Add model cost while sessions wait or recover. If an agent repeatedly polls for readiness, narrates delays, or retries a navigation before the browser exists, infrastructure queueing becomes token spend. Use explicit tool states and event-driven wakeups so the model is not paid to watch a queue.

Control Fan-Out

A coding agent can easily multiply one request into browsers across pages, viewports, locales, and accounts. Reserve capacity before fan-out and make the reservation cover the entire task. Set per-repository, per-team, and global limits. Without hierarchy, one large visual regression run can occupy every slot and starve incident response.

Prefer staged expansion. Start with a smoke set, then launch the full matrix only if core states pass. Cancel descendants when an upstream build fails. Store a reusable authenticated state only when policy permits and freshness is validated. These changes often save more than moving the headline concurrency number.

Price Failure Recovery

• Classify navigation, authentication, selector, network, and application failures.
• Retry only transient classes, with jitter and a task-level cost ceiling.
• Retain enough trace and screenshot evidence to diagnose one failure.
• Stop duplicate sessions when a newer commit supersedes their result.

Report canceled and timed-out sessions as paid attempts, not missing data. Track browser minutes, actions, transferred bytes, model tokens, and reviewer corrections. A fleet that completes 95% of jobs cheaply but loops on the final 5% may have an expensive p95 cost per accepted result.

Choose the Right Capacity Target

Buy or request more capacity only after showing that queue delay is the binding constraint. If launch setup, application rate limits, slow tests, or reviewers dominate, a higher session ceiling merely moves the queue. Run a controlled load test with representative pages and stop conditions before projecting production savings.

Use cost per verified browser state and cost per accepted pull request as business units. Keep concurrency, launch delay, action rate, and browser duration as diagnostics. This prevents capacity improvements from being mistaken for delivered value.

Run a Capacity Experiment

Replay the same browser workload at several concurrency caps, such as 40, 80, 120, and 200, while holding pages, checks, agent version, and retry rules constant. Measure throughput, queue delay, browser duration, application throttling, model tokens, failures, and total cost. Stop a stage if downstream error rates rise because a nominal capacity test must not overload the target application.

Choose the smallest cap that satisfies the service objective with headroom for urgent work. Repeat during a realistic release burst and after material application changes. Store the result as a dated capacity assumption, not a permanent truth. This experiment turns a published platform limit into an evidence-based fleet setting.

Bottom Line

Cloudflare's increase makes larger parallel workloads possible and can cut queue delay when browser admission is the bottleneck. Real savings require reservations, staged fan-out, event-driven coordination, bounded retries, and task-level attribution. Operate the 200-session allowance as a shared budget, not a target to fill.