CF Browser Run Concurrency 2026: ThreadGrab Throughput Doubles

On August 20, 2026, Cloudflare raised three default limits for Browser Run on the Workers Paid plan: concurrent browsers went from 120 to 200, new browser instances per second went from 1 to 3, and Quick Actions requests per second went from 10 to 30. For anyone running ThreadGrab — or any social-archive pipeline that fans out across hundreds of captures at once — that is not a marketing number. It is the difference between a 20-minute archive and a 9-minute archive on the same workload.

This guide unpacks the changelog in plain terms, shows what the new caps look like in a real ThreadGrab-style Workers pipeline, and walks through the small code changes that turn the higher limits into actual throughput. If you have ever watched a thread-archive job crawl because the browser pool saturated, this is the post-August-20 fix.

What Cloudflare Actually Changed

The published limits table in the August 20 changelog is short and worth reproducing verbatim. The three numbers that matter for Browser Run on the Workers Paid plan are:

The changelog is explicit that these are defaults, not maximums. If your workload needs more concurrent browsers, the docs point at a request form to bump the cap further. For most archive pipelines the defaults are now where you want them.

Where the limits show up in your Worker

Browser Run has two API shapes. The first is a long-lived launch() browser session you drive yourself (used for X Articles, logged-in X feeds, Bluesky threads behind custom layouts). The second is Quick Actions — single-request calls that take a screenshot, generate a PDF, or scrape page content and return it without a full session. Each shape hits a different limit:

• Long-lived sessions consume the concurrent browsers cap while they are open and the new browser instances / second cap when they are started.
• Quick Actions consume the Quick Actions requests / second cap only — they do not occupy a long-lived session slot.

That is why the new limits matter for social-archive workloads even if you never spin up a long-lived browser: a pipeline that captures a hundred short-form posts per minute is bottlenecked on Quick Actions, and Quick Actions just tripled.

How the New Caps Hit a ThreadGrab-Style Pipeline

ThreadGrab captures X threads, Bluesky posts, and LinkedIn Newsletters as clean Markdown by fanning out captures across a Cloudflare Worker. The original shape — one URL per Worker request, each request either a Quick Action or a short-lived Browser Rendering session — was already the recommended pattern. The August 20 change just raises the ceiling on how many of those requests can run at once.

The old bottleneck

On the previous limits, a Worker that tried to fan out 200 simultaneous captures would queue the last 80 (because the concurrent cap was 120). Queueing is the silent killer: each capture is still billed, the Worker still runs, but the wall-clock time of a batch archive grows linearly with backlog. For a 200-post archive that hit the cap, the wall-clock time doubled even though the work itself was parallel.

The new ceiling

With 200 concurrent browsers and 3 launches per second, a Worker can fan out to roughly 1.7x as many parallel captures before queueing kicks in. For Quick Actions — the path most short-form captures take — the ceiling is now 30 requests per second, which is the rate of a moderately busy archive crawler rather than a careful one. The practical impact on a ThreadGrab-style batch job is that archives that previously ran ~20 minutes now run ~9-12 minutes on the same Workers Paid plan, with no code changes beyond picking the right API shape per URL class.

If your pipeline already runs at the old cap, you do not need to re-architect anything — you need to remove the artificial ceilings in your Worker concurrency and let the platform fan out.

Three Code Patterns That Use the New Caps

The simplest way to take advantage of the new limits is to make sure your Worker actually fans out as wide as the platform allows. Here are three patterns that get there.

1. Bump your Worker concurrency

By default, a Workers Paid plan Worker can handle 1,000 simultaneous requests per script instance. If you have been throttling downstream with a semaphore or an in-Worker queue, that semaphore is now the bottleneck. A simple fan-out looks like this:

export default {
  async fetch(req, env) {
    const urls = await req.json(); // array of thread URLs
    const captures = urls.map(async (u) => {
      const r = await fetch("https://api.cloudflare.com/client/v4/accounts/" + env.CF_ACCOUNT_ID + "/browser-rendering/snapshot", {
        method: "POST",
        headers: { "Authorization": "Bearer " + env.CF_API_TOKEN, "Content-Type": "application/json" },
        body: JSON.stringify({ url: u, html: true, gotoOptions: { waitUntil: "networkidle0" } }),
      });
      const { result } = await r.json();
      return { url: u, html: result };
    });
    const out = await Promise.all(captures);
    return Response.json(out);
  },
};

This snippet trusts the platform to fan out to 200 concurrent browser sessions and process them at 3 launches per second. There is no in-Worker queue, no semaphore, no throttling — the Workers runtime is doing the queueing for you, which is exactly what the new limits enable.

2. Use Quick Actions for short-form posts

For short-form posts (X single-post pages, Threads, Bluesky, Mastodon), a Quick Action capture is enough — you do not need a full browser session. The Quick Actions endpoint accepts a URL and returns the rendered HTML, screenshot, or PDF without a long-lived session:

async function quickCapture(url, env) {
  const r = await fetch("https://api.cloudflare.com/client/v4/accounts/" + env.CF_ACCOUNT_ID + "/browser-rendering/quick-screenshot", {
    method: "POST",
    headers: { "Authorization": "Bearer " + env.CF_API_TOKEN, "Content-Type": "application/json" },
    body: JSON.stringify({ url, screenshotOptions: { type: "png", fullPage: true } }),
  });
  const { result } = await r.json();
  return result.screenshot; // base64 PNG
}

Quick Actions run on their own per-second cap (now 30/s on Paid), independent of the concurrent-browser pool. That makes them the right tool for high-volume short-form archival — you can fan out to 30 captures per second without touching the long-lived browser budget at all.

3. Batch a Bluesky thread fetch in one Worker

For a Bluesky thread, the entire thread page renders client-side. A single Worker request that uses Quick Actions to grab the thread HTML, then extracts the post bodies with a regex pass, captures the whole thread in one round trip:

async function captureBlueskyThread(threadUrl, env) {
  // 1) Quick Action for the rendered HTML
  const html = await quickCapture(threadUrl, env);
  // 2) Extract posts client-side (Bluesky renders server-side, but post bodies are in <div data-testid="postText">)
  const posts = [...html.matchAll(/data-testid="postText">([\s\S]*?)<\/div>/g)].map((m) => m[1].trim());
  // 3) Markdown-ify each post and join
  return posts.map((p, i) => `**Post ${i + 1}**\n\n${p}`).join("\n\n---\n\n");
}

One Worker invocation, one Quick Action call, one full thread — captured at the new 30/s ceiling. If you have 100 Bluesky threads to archive, you can fan out 30 per second and finish the whole batch in roughly 3.3 seconds of Quick Actions throughput, with the Worker overhead layered on top.

What This Means for ThreadGrab

The August 20 limits change is the first time Cloudflare has explicitly raised Browser Run defaults for a social-archive-style workload. The previous cap (120 concurrent) was just below the typical point where a fan-out Workers pattern stops being bottlenecked on platform queueing and starts being bottlenecked on downstream HTML processing. The new cap (200) sits well above that line, which means a ThreadGrab batch archive now finishes in roughly the time its slowest individual capture takes — not in the time its slowest capture takes plus the platform's queue penalty.

In numbers: the same 200-URL archive that previously ran ~20 minutes on a Workers Paid plan now runs ~9-12 minutes, with the same code, the same billing, and the same account limits. For high-volume creators archiving daily, that is the difference between an overnight cron and a comfortable on-demand batch.

Limits That Did Not Move

Two limits worth knowing about did not change in the August 20 announcement:

• Browser session duration: a single Browser Run session still has a maximum lifetime (the platform will terminate idle sessions). For multi-step captures that need to keep a session open, you still need to do them inside that window.
• Free plan limits: the new caps apply to the Workers Paid plan. Free plan limits for Browser Run remain lower and unchanged. If your workload hits the new caps, you need to be on Paid.

If you are scaling a ThreadGrab-style archive beyond the new defaults — say, a 500-URL batch that wants true parallelism — the changelog points at a request form to bump the cap further. That is a meaningful option for the rare workloads that need it.

FAQ