Why KERNEL?

KERNEL provides isolated cloud browsers for AI agents. It works underneath the agent framework you already use, with anti-detection, managed authentication, and tools for running browsers at scale. Your framework runs the loop and KERNEL runs the browser, so you can pick the best of each instead of settling for a browser bundled with a framework, or a framework bundled with a browser. See integrations for the frameworks and agents KERNEL works with, and important concepts for how the pieces fit. KERNEL is also built for speed, across the browser lifecycle and inside a running session. A browser is created in about 30ms at P50 and 105ms at P99, and your code can run in the browser’s VM instead of across the network, so each action skips the round trip. On ComputeSDK’s independent throughput benchmark, KERNEL led the providers tested on actions per second inside a running session. See benchmarks for how KERNEL compares.

​

What sets KERNEL apart

• Headful by default. Every browser has a real display and runs the full rendering pipeline. Sites that check for signs of a headless browser don’t find them, computer use models see the page as it actually rendered, WebGL, canvas, and video work, and live view and replays show the real session. Switch to headless per session when a job doesn’t need it, or add GPU acceleration for graphics-heavy sites.
• Each browser is its own VM. Every browser runs isolated at the hypervisor, with its own kernel and filesystem, instead of sharing a host with other tenants. That’s what makes a 30ms start and strong isolation possible at the same time, and it’s why file I/O, shell access, and GPU access are safe to use inside a session.
• Platform primitives, with managed services built on them. Profiles keep browser state between sessions, vaults hold credentials and payment items, and browser pools keep configured browsers ready. Managed services such as managed auth, payments, stealth, and the code execution platform build on them.

To put these to work, the how it works guides walk through each stage of a browser’s life: configure it, control it, scale it, observe it, and manage it across your team.

​

Why not just run Chrome yourself?

You can. Running one Chrome locally is easy, and it’s the right call while you’re prototyping. The work starts when the automation has to run unattended, more than once, at more than one at a time. These are the problems you’d need to solve yourself:

​

When KERNEL isn’t the answer

If the task can be done through an API or an MCP server, use that instead. It’s faster and more reliable than driving a page. An API existing isn’t enough on its own: it has to support the work you need, and many don’t expose everything the site does. Use a browser when the task can only be done through the site itself, whether or not it needs a login: a portal with no API, data the API doesn’t return, or a task where a computer use model has to see the page to take actions.