Update limits (concurrency 30→120, per-sec wording), add Agents Week changelog entries, Browser Run rename on limits page (#29759)

Author: kathayl

src/content/docs/browser-rendering/limits.mdx

@@ -8,9 +8,9 @@ sidebar:
 
 import { Render, Plan, Tabs, TabItem, DashButton } from "~/components";
 
-Browser Rendering limits are based on your [Cloudflare Workers plan](/workers/platform/pricing/).
+Browser Run limits are based on your [Cloudflare Workers plan](/workers/platform/pricing/).
 
-For pricing information, refer to [Browser Rendering pricing](/browser-rendering/pricing/).
+For pricing information, refer to [Browser Run pricing](/browser-rendering/pricing/).
 
 ## Workers Free
 
@@ -23,9 +23,9 @@ If you are on a Workers Free plan and you want to increase your limits, upgrade
 | -------------------------------------------------------- | --------------- |
 | Browser hours                                            | 10 minutes per day |
 | Concurrent browsers per account (Browser Sessions only) [^1]  | 3 per account   |
-| New browser instances (Browser Sessions only) | 3 per minute    |
+| New browser instances (Browser Sessions only) | 1 every 20 seconds    |
 | Browser timeout                                          | 60 seconds [^2]  |
-| Total requests (Quick Actions only) [^3]                 | 6 per minute (1 every 10 seconds)   |
+| Total requests (Quick Actions only) [^3]                 | 1 every 10 seconds   |
 
 ### `/crawl` endpoint limits
 
@@ -45,16 +45,16 @@ If you are on a Workers Paid plan and you want to increase your limits beyond th
 | Feature                                                  | Limit           |
 | -------------------------------------------------------- | --------------- |
 | Browser hours                                            | No limit  ([See pricing](/browser-rendering/pricing/))      |
-| Concurrent browsers per account (Browser Sessions only) [^1] | 30 per account ([See pricing](/browser-rendering/pricing/)) |
-| New browser instances per minute (Browser Sessions only) | 30 per minute   |
+| Concurrent browsers per account (Browser Sessions only) [^1] | 120 per account ([See pricing](/browser-rendering/pricing/)) |
+| New browser instances per second (Browser Sessions only) | 1 per second    |
 | Browser timeout                                          | 60 seconds [^2] |
-| Total requests per min (Quick Actions only) [^3]         | 600 per minute (10 per second)  |
+| Total requests per second (Quick Actions only) [^3]      | 10 per second   |
 
 [^1]: Browsers close upon task completion or sixty seconds of inactivity (if you do not [extend your browser timeout](#can-i-increase-the-browser-timeout)). Therefore, in practice, many workflows do not require a high number of concurrent browsers.
 
 [^2]: By default, a browser will time out after 60 seconds of inactivity. You can extend this to up to 10 minutes using the [`keep_alive` option](/browser-rendering/puppeteer/#keep-alive). Call `browser.close()` to release the browser instance immediately.
 
-[^3]: Enforced with a fixed per-second fill rate, not as a burst allowance. This means you cannot send all your requests at once. The API expects them to be spread evenly over the minute. If you exceed the limit, refer to [troubleshooting the `429 Too many requests` error](#error-429-too-many-requests).
+[^3]: If you exceed the per-second rate limit, you will receive a `429` response. Refer to [troubleshooting the `429 Too many requests` error](#error-429-too-many-requests).
 
 ## FAQ
 
@@ -66,9 +66,9 @@ By default, a browser instance will time out after 60 seconds of inactivity. If
 
 ### Is there a maximum session duration?
 
-There is no fixed maximum lifetime for a browser session as long as it remains active. By default, Browser Rendering closes sessions after one minute of inactivity to prevent unintended usage. You can [increase this inactivity timeout](/browser-rendering/puppeteer/#keep-alive) to up to 10 minutes.
+There is no fixed maximum lifetime for a browser session as long as it remains active. By default, Browser Run closes sessions after one minute of inactivity to prevent unintended usage. You can [increase this inactivity timeout](/browser-rendering/puppeteer/#keep-alive) to up to 10 minutes.
 
-If you need sessions to remain open longer, keep them active by sending a command at least once within your configured inactivity window (for example, every 10 minutes). Sessions also close when Browser Rendering rolls out a new release.
+If you need sessions to remain open longer, keep them active by sending a command at least once within your configured inactivity window (for example, every 10 minutes). Sessions also close when Browser Run rolls out a new release.
 
 ### I upgraded from the Workers Free plan, but I'm still hitting the 10-minute per day limit. What should I do?
 
@@ -84,7 +84,7 @@ To minimize usage:
 - Wrap your browser code in a `try/finally` block to ensure `browser.close()` is called even if an error occurs.
 - Use [`puppeteer.history()`](/browser-rendering/puppeteer/#list-recent-sessions) or [`playwright.history()`](/browser-rendering/playwright/#list-recent-sessions) to review recent sessions and identify any that closed due to `BrowserIdle` instead of `NormalClosure`. Sessions that close due to idle timeout indicate the browser was not closed explicitly.
 
-You can monitor your usage and view session close reasons in the Cloudflare dashboard on the **Browser Rendering** page:
+You can monitor your usage and view session close reasons in the Cloudflare dashboard on the **Browser Run** page:
 
 <DashButton url="/?to=/:account/workers/browser-rendering" />
 
@@ -94,7 +94,7 @@ Refer to [Browser close reasons](/browser-rendering/reference/browser-close-reas
 
 ### Error: `429 Too many requests`
 
-When you make too many requests in a short period of time, Browser Rendering will respond with HTTP status code `429 Too many requests`. You can view your account's rate limits in the [Workers Free](#workers-free) and [Workers Paid](#workers-paid) sections above.
+When you make too many requests in a short period of time, Browser Run will respond with HTTP status code `429 Too many requests`. You can view your account's rate limits in the [Workers Free](#workers-free) and [Workers Paid](#workers-paid) sections above.
 
 The example below demonstrates how to handle rate limiting gracefully by reading the `Retry-After` value and retrying the request after that delay.
 
@@ -152,7 +152,7 @@ try {
 
 ### Error: `429 Browser time limit exceeded for today`
 
-This `Error processing the request: Unable to create new browser: code: 429: message: Browser time limit exceeded for today` error indicates you have hit the daily browser limit on the Workers Free plan. [Workers Free plan accounts are limited](#workers-free) to 10 minutes of Browser Rendering usage per day. If you exceed that limit, you will receive a `429` error until the next UTC day.
+This `Error processing the request: Unable to create new browser: code: 429: message: Browser time limit exceeded for today` error indicates you have hit the daily browser limit on the Workers Free plan. [Workers Free plan accounts are limited](#workers-free) to 10 minutes of Browser Run usage per day. If you exceed that limit, you will receive a `429` error until the next UTC day.
 
 You can [increase your limits](#workers-paid) by upgrading to a Workers Paid plan on the **Workers plans** page of the Cloudflare dashboard:
 

src/content/release-notes/browser-rendering.yaml

@@ -3,6 +3,28 @@ link: "/browser-rendering/changelog/"
 productName: Browser Rendering
 productLink: "/browser-rendering/"
 entries:
+  - publish_date: "2026-04-15"
+    title: "Higher concurrency limits"
+    description: |-
+      * Increased the default [concurrent browser limit](/browser-rendering/limits/#workers-paid) for Workers Paid plans from 30 to **120 per account**.
+      * Increased new browser instance rate for Workers Paid plans from 30 per minute to **1 per second**.
+      * Rate limits across the [limits page](/browser-rendering/limits/) are now expressed in per-second terms, matching how they are enforced.
+  - publish_date: "2026-04-15"
+    title: "Live View"
+    description: |-
+      * [Live View](/browser-rendering/features/live-view/) lets you see and interact with a remote browser session in real time. Use it to debug automation scripts, monitor what a browser is doing, or manually step in when a task requires human intervention. Access Live View from the Cloudflare dashboard, via the hosted UI at `live.browser.run`, or using native Chrome DevTools.
+  - publish_date: "2026-04-15"
+    title: "Human in the Loop"
+    description: |-
+      * [Human in the Loop](/browser-rendering/features/human-in-the-loop/) lets a human step into a live browser session to handle what automation cannot, such as login pages, CAPTCHAs, or sensitive data entry, then hand control back to the script. Access any active session through [Live View](/browser-rendering/features/live-view/).
+  - publish_date: "2026-04-15"
+    title: "Session Recordings"
+    description: |-
+      * [Session Recordings](/browser-rendering/features/session-recordings/) captures DOM changes, mouse and keyboard events, and page navigation as structured data so you can replay any browser session after it ends. Enable recordings by passing `recording: true` when launching a browser. After the session closes, access recordings from the **Runs** tab in the Cloudflare dashboard or retrieve them via API.
+  - publish_date: "2026-04-15"
+    title: "WebMCP support"
+    description: |-
+      * Browser Run now supports [WebMCP](/browser-rendering/features/webmcp/) (Web Model Context Protocol), which allows websites to declare structured tools that AI agents can discover and execute. WebMCP-enabled browsers are available through the experimental lab browser pool.
   - publish_date: "2026-04-14"
     title: "Wrangler CLI commands for Browser Rendering"
     description: |-