How You Drive the Browser

Two decisions to make before you write any automation: which control surface, and where your loop runs

Before you write a line of automation you’re making two choices. They’re independent, but the first constrains the second, and neither is obvious from the API surface.

1. How you drive the browser — the control surface your code (or your model) uses to act on the page.
2. Where the loop runs — the machine your decision-making code runs on, relative to the browser.

1. How you drive the browser

Kernel browsers accept four control surfaces. Pick by what’s driving the page, not by what you know best.

Surface	Use it when	Trade-off
Playwright execution	Default. You know what to do on the page — navigate, fill, extract, upload.	Needs a selector or a DOM path that exists.
Computer controls	Recommended fallback. A model is looking at pixels, or the page can’t be driven programmatically.	Slower per step, and the model has to see the state to act.
CDP	You have an existing Playwright, Puppeteer, or CDP codebase to point at Kernel.	Adds a protocol fingerprint and a network hop — see below.
WebDriver BiDi	You need the W3C standard protocol.	Smaller client ecosystem.

The recommended pattern for agents is Playwright execution with a computer-use fallback: script the deterministic steps, hand the page to a computer-use model when a step doesn’t respond to a selector.

Why the choice matters on hardened sites

CDP is what Playwright and Puppeteer speak, and anti-bot vendors actively scan for its signatures — an attached debugger is one of the cheapest automation signals a page can read. Computer controls carry no CDP connection at all, so there’s no protocol fingerprint to leak. That’s why they’re the stronger option on sites with aggressive detection, and it’s why Kernel’s own managed auth drives logins with coordinate-based input rather than CDP.

How much this matters is site-specific, and worth testing before you commit to an approach — see why the same site behaves differently.

2. Where the loop runs

Your loop is whatever decides the next action: a script, an agent, a model. It can run in three places.

Your own infrastructure

Connect to cdp_ws_url (or webdriver_ws_url) from wherever your code already runs. Any CDP client works, and there’s no lock-in.

Costs: a network round trip per action, disconnects to handle, screenshot and DOM bandwidth, and the CDP fingerprint above. Fine for low-frequency or deterministic work; it’s the shape that hurts most in a vision loop.

CDP connection notes if you take this path:

• CDP connections are meant to be long-lived but may eventually close. WebSocket connections typically stay active for up to an hour, after which they may close automatically. The browser session is unaffected — reconnect to the same cdp_ws_url to continue.
• Browsers persist independently of CDP. Depending on your timeout configuration, a browser keeps running even after its CDP connection closes.
• Implement reconnect logic. Network interruptions and lifecycle events can close a CDP session; detect the disconnect and re-establish the connection.

Kernel's Playwright execution API

Send code, not commands. Each call runs co-located in the browser’s VM against the live session, so state carries across calls and an agent can drive the page turn by turn — one tool call per step, structured data back.

Costs: the code you send has to be self-contained per call. Nothing to install, no connection to manage, and Patchright is on by default.

const { result } = await kernel.browsers.playwright.execute(browser.session_id, {
  code: `
    await page.goto('https://news.ycombinator.com');
    return await page.$$eval('.titleline > a', (as) => as.map((a) => a.textContent));
  `,
});

Kernel App Platform

Deploy the whole agent next to the browser with the App Platform. Your code and the browser are in the same region, invoked on demand or on a schedule, with no infrastructure of your own.

Costs: your agent has to be deployable as a Kernel app. Worth it once the automation is long-running, stateful, or triggered by events rather than by a person.

Where computer use fits

A computer-use agent answers the first question, not the second — it still has to run its loop somewhere. And because every turn ships a screenshot instead of a small script, running that loop off-platform is far more expensive than for a Playwright-driven agent: you pay image bandwidth and a round trip on every step of the loop.

So computer use is the strongest case for co-locating your loop with the browser. Model inference sits with the model vendor either way; what you’re deciding is where the screenshot-and-act loop lives.

Putting it together

Your automation	Control surface	Where the loop runs
Scheduled scrape of a known page	Playwright execution	Anywhere — one call, one result
Agent doing multi-step work on a normal site	Playwright execution, computer-use fallback	Playwright execution API, or App Platform once it’s long-running
Agent on a site with aggressive detection	Computer controls	App Platform
Existing Playwright suite you’re migrating	CDP	Your own CI, then move hot paths to Playwright execution

Control reference

Working examples of all four control surfaces.