Kernel.sh Review 2026: Speed, Concurrent Sessions, and Real Pricing

Kernel.sh is cloud browser infrastructure for AI agents that launches isolated Chromium sessions and exposes control through API, CDP, or WebDriver BiDi. Teams use it for Playwright automation, computer use, and work with authorized web applications. Before production rollout, test real latency from your region, the GB-second billing model, and the behavior of your target sites.

Kernel is not a ready-made AI agent. It is a browser layer that connects to your code, an MCP client, or a computer-use model. Websites can still inspect browser environment signals such as fonts, User-Agent, WebGL, and the network route. A separate guide on how browsers detect installed fonts explains one of these signals.

Public tests show that fast startup does not make a session invisible to anti-fraud systems. Some checkers found no automation in a standard session, while others flagged the proxy or a timezone mismatch. Even Canvas graphics can become part of a fingerprint when a site analyzes rendering instead of relying only on navigator.webdriver.

The practical conclusion is simple: evaluate Kernel as infrastructure, not as a promise to bypass every protection system. For accounts with long-lived sessions, IP is only one factor. Hardware fingerprinting, cookies, local storage, and consistent behavioral signals matter as well.

What Is Kernel.sh and Which Tasks Does It Suit

Kernel.sh provides an isolated Chromium instance in a dedicated virtual machine for every session. The client receives a cdp_ws_url, then controls the browser through Playwright or Puppeteer, executes code inside the VM, or sends coordinate-based commands to a computer-use agent.

The service officially supports headful and headless modes, live view, MP4 replays, telemetry, profiles, and Managed Auth. A session can remain active for up to 72 hours. A GPU-enabled headful browser is available for rendering-heavy tasks, although it belongs to a more expensive configuration and does not use standby.

Kernel works well when an agent must open a real website, perform a sequence of actions, and return structured output. Typical tasks include:

• testing a web interface with Playwright
• collecting data from pages that require JavaScript
• working with an authorized account the team is permitted to access
• human-in-the-loop workflows with real-time session viewing
• parallel QA testing of several page versions
• running a computer-use agent inside an isolated VM

Cloud Chromium is often unnecessary for a simple HTTP API, RSS feed, or static page. First confirm that the task actually requires a full browser. This saves both time and budget.

How Kernel.sh Works from Session Creation to Deletion

The Kernel lifecycle consists of creating a session, connecting a client, performing actions, and explicitly deleting the browser. Every active instance consumes resources according to its mode, so cleanup must be part of the code rather than a manual step after a failure.

For automation without a graphical interface, headless browsing is appropriate. Headful mode is useful when real-time live view, video replay, complex rendering, or manual takeover matters.

A basic TypeScript setup takes several steps:

1. create an API key in the Kernel dashboard
2. install @onkernel/sdk and playwright-core
3. store the key in the KERNEL_API_KEY environment variable
4. create a browser through the SDK
5. connect Playwright to cdp_ws_url
6. perform a test action on a controlled page
7. close the CDP connection
8. delete the session through the API inside a finally block

A minimal test script can look like this:

import Kernel from "@onkernel/sdk";
import { chromium, type Browser } from "playwright-core";

const kernel = new Kernel({ apiKey: process.env.KERNEL_API_KEY });
const session = await kernel.browsers.create({ headless: true });
let browser: Browser | undefined;

try {
  browser = await chromium.connectOverCDP(session.cdp_ws_url);
  const context = browser.contexts()[0];
  const page = context.pages()[0] ?? await context.newPage();
  await page.goto(process.env.TARGET_URL ?? "about:blank", {
    waitUntil: "domcontentloaded",
    timeout: 30_000,
  });
  console.log(await page.title());
} finally {
  try {
    await browser?.close();
  } finally {
    await kernel.browsers.deleteByID(session.session_id);
  }
}

The script checks the complete chain without tying the test to a complex website. Measure session creation, CDP connection, and page loading separately first; otherwise, one timer will not reveal where the delay occurs.

After the test, inspect the active session list in the dashboard. Abandoned browsers continue to occupy a concurrent-session slot even after a standard session enters standby and active usage charges stop.

What Kernel Profiles Preserve Between Runs

A Kernel profile preserves cookies and browser storage between separate sessions. This allows the next browser to continue an authorized state without another password entry, provided the website session remains valid.

Do not treat a profile as a complete antidetect identity template. The official documentation describes it as a state container, not as an editor for Canvas, WebGL, fonts, or hardware parameters. When a profile uses save_changes: true, only one process should write changes at a time because a later save can overwrite an earlier state.

Different permitted user identities require separate profiles. A shared cookie store means a shared authorization context. Mixing two clients in one profile creates a session-leak risk even without any anti-fraud system.

Managed Auth solves another problem: it retrieves credentials without exposing them to the language model, completes the login flow, and can restore authorization when the process does not require manual OTP or push confirmation. Passkeys and hardware security keys are not suitable for automatic reuse. This is an important limitation.

IP is configured at the session or proxy configuration level. The Free plan includes stealth mode with a managed proxy, Hobbyist adds unlimited proxy usage, and custom BYO proxies are listed for Start-Up. Before using an authorized website, verify that the exit IP remains consistent across all of its subdomains.

What Kernel.sh Anti-Bot Tests Showed

In one tested configuration, BrowserScan found no issues in its checks of a standard headful session, while Pixelscan detected a proxy and recorded an IP timezone mismatch during one stealth-mode run.

These measurements are not a universal certificate. A public checker sees only some signals, while a production anti-fraud system also considers IP reputation, account history, TLS, HTTP headers, and behavior. The Afina team did not independently reproduce the test, so its figures should be read as a snapshot of one configuration.

When testing the public pages of Zillow, LinkedIn, Amazon, and Hacker News, standard headful mode loaded every page in all five attempts. G2 returned 403 in all five attempts. In stealth mode, Amazon displayed Robot Check in two of five attempts, while the other three runs opened the page.

The most useful conclusion is to test your own target URLs instead of relying on a score from one fingerprint checker. For each domain, record the HTTP status, page title, presence of a challenge, and a screenshot of the error.

Repeat the series at least five times in every mode. This is still only an initial check: five runs are not enough for a statistically reliable blocking-rate estimate. One successful run does not establish stability, and one 403 may result from a temporary rate limit.

How Fast Is Kernel.sh and Why Region Changes the Result

In its comparison material, Kernel reports a cold start below 30 ms and a complete create, connect, load, release cycle of roughly 794 ms. These are different metrics: the first covers the startup stage measured by the service, not full browser readiness; the second includes session creation, connection, page loading, and cleanup.

In a competitive test, code hosted on Kernel Apps in the us-east region reached the first page in a median 0.36 seconds. The same class of headful session with a client in India took 3.90 seconds, while a persisted profile increased the median to 4.49 seconds. Network distance to the API and CDP caused most of the difference.

A useful benchmark therefore separates the stages:

• browsers.create() shows API latency and environment preparation time
• CDP connection time shows network distance to the browser
• first-page loading depends on the target site and exit IP address
• page actions depend on rendering and DOM complexity
• total task time includes LLM response waits and retries

Under the service model described by Kernel, a standard browser enters standby about five seconds after the last CDP, WebDriver, or live-view client disconnects. This is expected behavior, not a guarantee of an exact transition time; verify actual state and billing through telemetry and usage data.

After a standard browser has actually entered standby, its state is retained and active usage is not billed under the service pricing model. An open connection prevents standby even when the agent is only waiting.

Test timer and heartbeat scenarios separately. The Page Visibility API and paused JavaScript execution can change page behavior after the client disconnects.

How Much Kernel.sh Costs in 2026

As of November 2026, Kernel offers Free, Hobbyist, and Start-Up plans, while Enterprise pricing is custom. The base fee does not cover all usage: actual consumption is added at $0.0000166667 per GB-second.

The effective hourly rate depends on the mode's memory allocation. Under the published model, headless with 1 GB costs about $0.06 per active hour, headful with 8 GB about $0.48, and GPU-enabled headful with 48 GB about $2.88.

The calculation for a standard session is:

cost = active seconds × memory in GB × $0.0000166667

For example, 100 active headful hours cost $48. Hobbyist includes $10 in credits, so the total would be about $68 including the plan: $30 + $48 - $10. If the browser genuinely spends half of the calendar time in standby, those hours do not count as active usage.

Do not confuse the concurrent-session limit with browser hours. Ten concurrent headful sessions running for one hour consume roughly ten browser hours, not one. A slot may also remain occupied by a browser in standby even though active billing has stopped.

Kernel does not separately bill network data through its proxies. However, the price of your own BYO proxy provider remains an external cost. Also verify User-Agent and Chromium version because the browser User-Agent affects target-site compatibility and test results.

How Kernel.sh Differs from Local Headless and Antidetect Browsers

Kernel is optimized for programmatically creating short or long cloud sessions for agents. Local headless gives you full infrastructure control, while an antidetect browser focuses on persistent profiles and digital identity management.

Kernel is not an automatic replacement for an antidetect browser. If the task is to launch hundreds of independent browser sessions for agents, its API and concurrency may be more convenient. If the main requirement is a stable separate fingerprint over a long period for every permitted account, evaluate other tools.

Who Should Use Kernel.sh and When to Choose Another Approach

Kernel suits teams that already have agent logic and do not want to maintain their own Chromium cluster. Its strongest scenarios include parallel QA testing, web application automation, live-view control, and workloads with pauses where standby genuinely reduces billed usage.

The most common evaluation mistake is to consider only the price of one browser hour. Three other factors drive real agent-workflow costs: the share of headful runs, the number of concurrent sessions, and the time a CDP connection remains open without work. An agent may perform useful work for two minutes and then wait ten minutes for a model decision. If the client does not disconnect, those ten minutes never become standby.

Consider a team running 40 headful tasks per day for 30 days. Each task performs five active minutes of work but occupies fifteen calendar minutes. With correct CDP disconnection, this equals about 100 active browser hours per month. If the connection stays open for all fifteen minutes, billed usage rises to 300 browser hours. Before plan credits, the difference for headful mode is about $96.

The second risk is the concurrent-session limit. Free allows five browsers, so a sixth simultaneous task must wait or receive a controlled error. Adding more worker processes does not increase the Kernel limit. Add a queue, a slot-acquisition timeout, and a separate active_sessions metric so a load spike does not turn into chaotic retries.

The third risk appears in profiles. Two parallel processes writing changes can save different browser-state versions, and the process that finishes later can overwrite the previous state. Every profile needs a mutex or a write queue shared by all processes and worker nodes that may persist its state.

A lock inside only one process does not prevent conflicts between separate executors. Runs that do not save profile changes can execute in parallel, but their effect on the server-side authorization state still needs separate testing.

Infrastructure limits are easier to measure than target-site behavior. Add telemetry for 429, 403, challenge pages, timeouts, and repeated login to the POC. Count successful page loads separately from completed business actions: an open dashboard does not mean the agent successfully downloaded a report or submitted a form.

Before choosing, run a short proof of concept:

1. select three typical target URLs
2. run five sessions for each in the required mode
3. measure session creation, connection, page loading, and total task time
4. verify authorization after restarting a profile
5. record CAPTCHA, 403, timeout, and exit-IP changes
6. calculate active GB-seconds and peak concurrent sessions
7. compare the result with local Playwright or your current browser stack

After the POC, document the acceptance criteria: acceptable error rate, maximum completion time, and monthly budget. Save the test configuration and review date so you can repeat the measurements after changes to pricing, Chromium, or the target website.

How Afina Helps

For teams using long-lived authorized accounts, the problem is often not cold-start speed but isolation of cookies, proxies, and fingerprints. Afina addresses this class of tasks through separate browser profiles and a managed automation environment. That does not make Kernel weaker; the products are optimized for different operating models. This material is provided for informational and educational purposes only.

For bursty agent workloads, test Kernel first on the Free plan. For long-lived profiles, evaluate Afina against the same target URLs and proxy infrastructure. The comparison is fair only when it measures the same operations, region, and session duration.