Between April 10–15 2026, during Cloudflare’s Agents Week, the company shipped two things that quietly change how teams build web-interaction layers for AI agents: a direct Chrome DevTools Protocol WebSocket endpoint for its managed browser service, and MCP client support that wires Claude Code, Cursor, or OpenCode to that same service with a config block and an API token. No self-hosted Chrome, no Puppeteer server to babysit.
What Changed: Browser Rendering Is Now Browser Run
On April 15 2026, Cloudflare officially renamed its headless browser product from Browser Rendering to Browser Run1. The rename is cosmetic at the API level — the endpoint path still contains /browser-rendering/ and existing Puppeteer and Playwright code continues to work without modification. No migration action is required for current users.
The rename coincided with a meaningful capacity increase: the concurrent browser limit for Workers Paid plan users rose 4x from 30 to 120 per account, the new instance rate increased to 1 per second (up from 30 per minute), and REST API rate limits were raised to 10 requests per second1.
The CDP Endpoint: One-Line Migration From Self-Hosted Chrome
On April 10 2026, Cloudflare added a direct Chrome DevTools Protocol WebSocket endpoint2. The connection URL is:
wss://api.cloudflare.com/client/v4/accounts/<ACCOUNT_ID>/browser-rendering/devtools/browserAuthentication is a Bearer token passed in wsHeaders. The endpoint accepts a keep_alive parameter.
Migrating an existing Puppeteer or CDP script from local Chrome amounts to one configuration change: set browserWSEndpoint to the Cloudflare wss:// URL and add the Authorization: Bearer <TOKEN> header. According to Cloudflare’s blog post, no other code changes are needed3.
Connecting AI Agents via MCP: Claude Code, Cursor, and OpenCode Setup
MCP clients connect to Browser Run using the chrome-devtools-mcp npm package (v0.21.0, 36.3k GitHub stars)4. This package is maintained by the Chrome DevTools team, not Cloudflare — an important distinction if you’re filing issues or tracking the project.
The configuration requires two flags:
{ "mcpServers": { "browser": { "command": "npx", "args": [ "chrome-devtools-mcp@0.21.0", "--wsEndpoint", "wss://api.cloudflare.com/client/v4/accounts/<ACCOUNT_ID>/browser-rendering/devtools/browser", "--wsHeaders", "{\"Authorization\":\"Bearer <TOKEN>\"}" ] } }}Cloudflare’s docs confirm this works with Claude Desktop, Claude Code, Cursor, and OpenCode4. The API token must have the Browser Rendering - Edit permission.
If you’ve read our earlier piece on using chrome-devtools-mcp for local frontend debugging, note the distinction: that use case is dev-time introspection of your own running browser. This is production agent infrastructure — a stateless remote browser that agents can drive to interact with the web.
Pricing Math: When Browser Run Beats Self-Hosted Playwright
The Workers Paid plan includes 10 browser-hours per month, with additional usage billed at $0.09 per hour5. Concurrent browser capacity works differently: 10 concurrent browsers are included, and beyond that you pay $2.00 per additional browser — but this is measured as the monthly average of your daily peak concurrent usage, not a hard cap. A spike to 15 browsers on one day won’t cost you $10; it contributes to your monthly average.
For comparison: Browserbase charges $99/month for 500 hours; Roundproxies Scraping Browser starts at $499/month minimum6. At $0.09/hour, 500 hours of Browser Run time costs $45 above the free tier — roughly half the Browserbase entry price. For low-volume agentic workloads that need real browser execution occasionally (form filling, CAPTCHA-adjacent tasks, JS-heavy scraping), the per-hour model is materially cheaper than flat-rate alternatives.
The free plan allows 10 minutes per day and 3 concurrent browsers5.
| Service | Entry price | Hours included | Additional |
|---|---|---|---|
| Browser Run (Paid) | Workers Paid plan | 10 hrs/month | $0.09/hr |
| Browser Run (Free) | Free | 10 min/day | — |
| Browserbase | $99/month | 500 hrs | — |
| Roundproxies Scraping Browser | $499/month | — | — |
Self-hosted Playwright or Puppeteer remains free in compute cost, but carries operational overhead: provisioning, scaling, crash recovery, and the security surface of running Chrome in your infrastructure. Browser Run trades that ops burden for a per-hour charge.
Observability Features: Live View, Session Recordings, and Human in the Loop
Three observability features shipped alongside the rename on April 15 20263:
Live View lets you watch an active agent session in real time via the Cloudflare dashboard or a session ID — page state, DOM, and network traffic included. Useful for debugging agent behavior without instrumenting your own logging.
Session Recordings capture a structured JSON record of DOM changes and interactions for a session. This produces a deterministic log of what the agent did, which matters when you need to audit or replay a sequence.
Human in the Loop allows a human operator to take over a live browser session — handling a CAPTCHA or an authentication step — and then return control to the agent. This addresses a real gap in agentic browser workflows: most tasks can be automated except the friction points that require human judgment or credentials.
WebMCP: The Emerging Standard Worth Watching (But Not Betting On Yet)
Browser Run also added WebMCP support on April 15 20267. WebMCP is a Chrome team API that lets websites expose structured, typed tools via navigator.modelContextTesting.listTools() and .executeTool(). The idea is that a site opts into agent interaction by publishing a typed tool manifest rather than having agents scrape or click their way through a UI.
The experimental browser pool running Chrome beta is accessible by appending lab=true to the /devtools/browser endpoint. Site-side adoption is near zero as of April 2026. The API name (modelContextTesting) signals its status clearly. This is worth tracking — if the Chrome team ships it as a stable API and sites adopt it, it could substantially improve agent reliability on participating sites — but it’s not something to build production workflows around yet.
Limitations and Caveats
A few things Browser Run explicitly does not do:
Bot protection bypass: Browser Run does not circumvent Cloudflare’s own bot protection mechanisms. If you’re trying to scrape a site protected by Cloudflare’s WAF or Bot Management, Browser Run won’t help — you’re still hitting the same protections3.
Self-hosted alternative: If you need zero egress cost, full control over Chrome flags, or can’t send traffic through Cloudflare’s network, Playwright MCP remains the self-hosted free alternative. Browser Run is a trade-off, not a replacement for every use case.
Vendor dependency: Your agent’s browser access is now tied to Cloudflare’s infrastructure and pricing decisions. The endpoint URL is stable post-rename, but the product is young.
FAQ
Does switching to Browser Run mean rewriting my Playwright tests?
No. The rename had no effect on existing code1. If you’re using the Puppeteer or Playwright library connectors, they continue to function. The CDP WebSocket endpoint is an additional connection method — you adopt it only if you want direct CDP access or MCP integration.
Who maintains chrome-devtools-mcp?
The chrome-devtools-mcp package is maintained by the Chrome DevTools team (the ChromeDevTools GitHub organization), not Cloudflare8. Cloudflare’s docs point to it as the recommended MCP client, but issues and PRs belong upstream at the ChromeDevTools repo.
What happens if my agent needs to log into a site mid-session?
The Human in the Loop feature lets a human operator take over the live session to handle authentication, then hand control back to the agent3. This is the documented approach for handling auth steps that can’t be automated.