BrowserCat is becoming the OpenRouter for browsers

When we started BrowserCat, the pitch was simple: write your Playwright script once, point it at wss://api.browsercat.com/connect, and we’ll run the browser in the cloud so you don’t have to. That promise hasn’t changed. But how we keep it is evolving in a big way.

Today we’re sharing where BrowserCat is headed: we’re becoming the OpenRouter for browsers. One API key, one connection, and a smart router that sends each session to the browser backend best suited for the job, no matter who runs it under the hood.

The best part? You don’t have to change a single line of code. The cat does the herding.

Why we changed

For a long time, “managed cloud browsers” meant one of two things for most teams: run your own fleet (and inherit all the ops pain) or marry a single vendor (and inherit all their trade-offs). Neither felt right.

Every provider is good at something and not-so-good at something else. One nails global edge performance. Another specializes in proxies and stealth. Another is racing to make cold-starts disappear. Pick just one and you’ve quietly signed up for its weaknesses too.

We didn’t want our customers boxed in by a decision they made on day one. So we flipped the model. Instead of BrowserCat being a single backend, BrowserCat became the layer that routes across backends based on what your session actually needs.

Same /connect endpoint. Same API key. Smarter plumbing behind it.

What’s live today: Cloudflare

Right now, every /connect session is proxied to Cloudflare Browser Rendering: headless Chromium running on Cloudflare’s global edge.

That gives you a few very nice properties out of the box:

Global reach. Sessions are served from close to your request, so you get low-latency browsers worldwide without managing a thing.
No cold-start surprises. Sessions spin up predictably, every time.
Honest, simple pricing. Cloudflare browser time runs $0.09 per browser-hour, and you only pay for what you use.

If you’re automating Chromium for scraping, screenshots, PDFs, e2e tests, or handing a real browser to an LLM, this is a rock-solid default. For the vast majority of jobs, it’s all you need.

What’s landing next: Steel for proxies

Cloudflare covers a lot of ground, but not everything. The router only matters if it can reach for a different tool when the default can’t do the job.

That’s why Steel is joining as our second backend. The router sends a session to Steel when it needs something Cloudflare can’t do today, and the first capability we’re lighting up is bring-your-own proxy: route a session’s traffic through your own proxy provider for geo-targeting, residential IPs, or bandwidth control.

Down the road, Steel also unlocks heavier anti-bot work like stealth and CAPTCHA handling. We’ll bring those online thoughtfully rather than hand-wave a checkbox that doesn’t quite work yet.

What’s next: our own fleet and ultra-fast cold-starts

The roadmap is where this really gets fun. A few things we’re building toward (no dates, just direction):

Our own fleet for the stuff third parties don’t cover well yet: Firefox and WebKit, headed browsers, and custom launch flags. Some jobs need a specific engine or a specific tweak, and we want a backend we fully control to guarantee it.
Lightpanda for ultra-fast cold-starts, when you want a browser available almost instantly and don’t need a full Chromium for the task.
Browserbase as a premium and failover option, giving the router another high-quality backend to lean on when it’s the right call.

Each of these slots into the same router. As they come online, your existing scripts can take advantage of them without a rewrite, a migration, or a sales call.

What this means for you

Here’s the whole point, in plain terms.

Zero code change. You already connect to wss://api.browsercat.com/connect. That endpoint isn’t going anywhere. Everything we add lives behind it.

One key, one connection. You authenticate once with BrowserCat. We handle authenticating, metering, and routing to whichever backend runs your session.

No vendor lock-in. You’re not betting your codebase on a single provider’s roadmap or pricing page. If the landscape shifts, the router shifts with it, and you don’t notice.

Automatic failover. When a provider has a bad day, the router can route around it. Your job doesn’t have to care which backend is healthy this afternoon, as long as a healthy one exists.

Future-proof by default. New engines, faster cold-starts, new capabilities: as we add backends, you get the upside without lifting a paw.

The same simple `/connect`, more brains behind it

The architecture is straightforward. Your code opens a websocket to wss://api.browsercat.com/connect, exactly like always. BrowserCat authenticates you, meters the session, and routes by capability, cost, region, and health. We open a CDP socket to the chosen backend and pipe frames back and forth. To your script, it’s just a browser.

If you want the full picture, we wrote it up in plain English in our new architecture docs, and you can track exactly which backends are live, landing, or planned on the roadmap.

We’re genuinely excited about this. The web should be your API, and you shouldn’t have to think about whose servers are making that true. You write the script. We’ll route the browser.

Now if you’ll excuse us, there’s a fleet to herd. 🐈