Обзор Kernel.sh 2026: скорость, параллельные сессии и реальные цены

Kernel.sh представляет собой облачную браузерную инфраструктуру для AI-агентов, которая запускает изолированные сессии Chromium и предоставляет управление через API, CDP или WebDriver BiDi. Сервис используют для автоматизации Playwright, computer use и работы с авторизованными веб-приложениями. Перед запуском в рабочей среде проверьте фактическую задержку из вашего региона, модель оплаты за GB-секунды и поведение целевых сайтов.

Kernel не является готовым AI-агентом. Это браузерный слой, к которому подключается собственный код, MCP-клиент или модель с computer use. Сайты по-прежнему могут определять параметры браузерной среды, включая шрифты, User-Agent, WebGL и сетевой маршрут. Отдельный материал о том, как браузеры определяют установленные шрифты, объясняет один из таких сигналов.

Публичные тесты показывают, что быстрый запуск не означает невидимость для антифрода. В стандартной сессии часть чекеров не обнаружила автоматизацию, но другие отметили прокси или несоответствие часового пояса. Даже Canvas-графика может стать частью отпечатка, если сайт анализирует рендеринг, а не только navigator.webdriver.

Практический вывод прост: Kernel стоит оценивать как инфраструктуру, а не как обещание обойти любую систему защиты. Для аккаунтов с длительными сессиями важен не только IP, но и аппаратный фингерпринтинг, файлы cookie, локальное хранилище и последовательность поведенческих сигналов.

Что такое Kernel.sh и для каких задач он подходит

Kernel.sh предоставляет изолированный Chromium в выделенной виртуальной машине для каждой сессии. Клиент получает cdp_ws_url, после чего управляет браузером через Playwright или Puppeteer, выполняет код внутри VM или передаёт агенту с функцией computer use команды для действий по координатам.

Официально сервис поддерживает headful и headless режимы, live view, MP4-повторы, телеметрию, профили и Managed Auth. Сессию можно сохранять до 72 часов. Для задач с рендерингом доступен headful-браузер с GPU, но эта опция относится к более дорогой конфигурации и не использует standby.

Kernel хорошо подходит для сценариев, где агент должен открыть реальный сайт, выполнить последовательность действий и вернуть структурированный результат. Типичные задачи выглядят так:

• тестирование веб-интерфейса через Playwright
• сбор данных со страниц, которым нужен JavaScript
• работа с разрешённым авторизованным кабинетом
• сценарий с участием человека и просмотром сессии в реальном времени
• параллельное QA-тестирование нескольких версий страницы
• запуск computer-use агента в изолированной VM

Для простого HTTP API, RSS или статической страницы облачный Chromium часто избыточен. Сначала проверьте, действительно ли задача требует полноценного браузера. Это экономит время и бюджет.

Как работает Kernel.sh от создания сессии до удаления

Рабочий цикл Kernel состоит из создания сессии, подключения клиента, выполнения действий и явного удаления браузера. Каждый активный экземпляр потребляет ресурсы в соответствии с выбранным режимом, поэтому очистка ресурсов должна быть частью кода, а не ручной операцией после сбоя.

Для автоматизации без графического интерфейса подходит headless-браузинг. Headful нужен, когда важны просмотр сессии в реальном времени, видеоповтор, сложный рендеринг или ручной перехват управления.

Базовая настройка через TypeScript занимает несколько шагов:

1. создайте API-ключ в кабинете Kernel
2. установите @onkernel/sdk и playwright-core
3. сохраните ключ в переменной среды KERNEL_API_KEY
4. создайте браузер через SDK
5. подключите Playwright к cdp_ws_url
6. выполните тестовое действие на контрольной странице
7. закройте CDP-соединение
8. удалите сессию через API в блоке finally

Минимальный тестовый скрипт может выглядеть так:

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);
  }
}

Скрипт проверяет всю цепочку без привязки к сложному сайту. Сначала измерьте создание сессии, подключение CDP и загрузку страницы отдельно, иначе единый таймер не покажет, где возникает задержка.

После теста проверьте список активных сессий в кабинете. Брошенные браузеры занимают слот параллельной сессии даже после перехода стандартной сессии в standby, когда плата за активное использование уже не начисляется.

Что сохраняют профили Kernel между запусками

Профиль Kernel сохраняет файлы cookie и браузерное хранилище между отдельными сессиями. Это позволяет следующему браузеру продолжить авторизованное состояние без повторного ввода пароля, если сессия авторизации на сайте ещё действует.

Профиль не следует воспринимать как полный шаблон антидетект-идентичности. Официальная документация описывает его как контейнер состояния, а не как редактор Canvas, WebGL, шрифтов или аппаратных параметров. Если профиль использует save_changes: true, только один процесс должен записывать изменения одновременно, потому что последующее сохранение может перезаписать предыдущее состояние.

Для нескольких разрешённых пользовательских идентичностей нужны разные профили. Общее хранилище cookie означает общий контекст авторизации. Смешивание двух клиентов в одном профиле создаёт риск утечки сессии даже без антифрода.

Managed Auth решает другую задачу: получает учётные данные без передачи языковой модели, выполняет вход и может восстановить авторизацию, если сценарий не требует ручного OTP или push-подтверждения. Passkey и аппаратный security key не подходят для автоматического повторного использования. Это важное ограничение.

IP настраивается на уровне сессии или конфигурации прокси. План Free включает stealth mode с управляемым прокси, Hobbyist добавляет неограниченное использование прокси, а собственные BYO-прокси заявлены для Start-Up. Перед работой с авторизованным сайтом проверьте стабильность выходного IP-адреса на всех его поддоменах.

Что показали антибот-проверки Kernel.sh

В конкретной протестированной конфигурации BrowserScan не обнаружил проблем в своих проверках стандартной headful-сессии, тогда как Pixelscan определил прокси и во время одного запуска в stealth mode зафиксировал несоответствие часового пояса IP.

Эти измерения не являются универсальным сертификатом. Публичный чекер видит лишь часть сигналов, тогда как антифрод-система в рабочей среде учитывает репутацию IP-адреса, историю аккаунта, TLS, HTTP-заголовки и поведение. Команда Afina не воспроизводила тест независимо, поэтому цифры следует рассматривать как снимок конкретной конфигурации.

При тестировании публичных страниц Zillow, LinkedIn, Amazon и Hacker News стандартный headful-режим успешно загрузил каждую страницу во всех пяти попытках. G2 вернул 403 во всех пяти попытках. В stealth mode Amazon дважды из пяти показал Robot Check, а остальные три запуска открыли страницу.

Самый полезный вывод из таблицы: проверяйте собственные целевые URL, а не рейтинг одного сервиса проверки цифрового отпечатка. Для каждого домена зафиксируйте HTTP-статус, заголовок страницы, наличие проверки и скриншот ошибки.

Повторите серию не менее пяти раз в каждом режиме. Это лишь начальная проверка: пяти запусков недостаточно для статистически надёжной оценки частоты блокировок. Один успешный запуск не подтверждает стабильность, а один 403 может быть следствием временного ограничения частоты запросов.

Какова скорость Kernel.sh и почему регион меняет результат

В сравнительном материале Kernel заявляет холодный запуск менее чем за 30 мс и полный цикл create, connect, load, release примерно за 794 мс. Это разные показатели: первый относится к измеряемому сервисом этапу запуска, а не к полной готовности браузера; второй охватывает создание сессии, подключение, загрузку страницы и завершение работы.

В конкурентном тесте код, размещённый на Kernel Apps в регионе us-east, показал медиану 0,36 секунды до первой страницы. Тот же класс headful-сессии с клиентом в Индии занял 3,90 секунды, а сохранённый профиль увеличил медиану до 4,49 секунды. Большую часть разницы создало сетевое расстояние до API и CDP.

Поэтому бенчмарк нужно разделять на этапы:

• browsers.create() показывает задержку API и время подготовки среды
• время подключения через CDP показывает сетевое расстояние до браузера
• загрузка первой страницы зависит от целевого сайта и выходного IP-адреса
• действия на странице зависят от рендеринга и сложности DOM
• общее время задачи учитывает ожидание ответа LLM и повторные попытки

Согласно описанной модели сервиса, стандартный браузер переходит в standby примерно через пять секунд после отключения последнего клиента CDP, WebDriver или live view. Это ожидаемое поведение, а не гарантия точного времени перехода; фактическое состояние и начисления проверяйте по телеметрии и данным использования.

После фактического перехода стандартного браузера в standby его состояние сохраняется, а плата за активное использование не начисляется в соответствии с тарифной моделью сервиса. Открытое соединение не позволяет перейти в standby, даже если агент только ждёт.

Сценарии с таймерами или heartbeat нужно тестировать отдельно. Page Visibility API и приостановка выполнения JavaScript могут изменить поведение страницы после отключения клиента.

Сколько стоит Kernel.sh в 2026 году

По состоянию на ноябрь 2026 года Kernel предлагает планы Free, Hobbyist и Start-Up, а Enterprise рассчитывается индивидуально. Базовая цена не покрывает всё использование: фактическое потребление оплачивается дополнительно по ставке $0,0000166667 за GB-секунду.

Эффективная почасовая ставка зависит от памяти режима. Согласно опубликованной модели, headless с 1 GB стоит около $0,06 за активный час, headful с 8 GB около $0,48, а headful с GPU и 48 GB около $2,88.

Расчёт стандартной сессии выглядит так:

стоимость = активные секунды × память в GB × $0,0000166667

Например, 100 активных headful-часов стоят $48. Hobbyist включает $10 кредитов, поэтому итог составит около $68 вместе с планом: $30 + $48 - $10. Если браузер действительно проводит половину календарного времени в standby, эти часы не входят в активное использование.

Не путайте лимит параллельных сессий с количеством браузерных часов. Десять параллельных headful-сессий в течение одного часа потребляют около десяти браузерных часов, а не один. Слот также может оставаться занятым браузером в standby, хотя активная оплата уже остановилась.

Kernel не тарифицирует сетевые данные своих прокси отдельно. Однако цена собственного провайдера BYO-прокси остаётся внешним расходом. Проверьте также User-Agent и версию Chromium, поскольку браузерный User-Agent влияет на совместимость с целевым сайтом и результаты тестов.

Чем Kernel.sh отличается от локального headless и антидетект-браузера

Kernel оптимизирован для программного создания коротких или длительных облачных сессий для агентов. Локальный headless даёт полный контроль над инфраструктурой, а антидетект-браузер сосредоточен на постоянных профилях и управлении цифровой идентичностью.

Kernel не является автоматической заменой антидетект-браузера. Если задача состоит в запуске сотен независимых браузерных сессий для агентов, его API и параллельность могут быть удобнее. Если главное требование состоит в стабильности отдельного цифрового отпечатка в течение длительного времени для каждого разрешённого аккаунта, оцените другие инструменты.

Кому подходит Kernel.sh и когда выбрать другой подход

Kernel подходит командам, у которых уже есть агентная логика и которые не хотят поддерживать собственный кластер Chromium. Наиболее сильные сценарии включают параллельное QA-тестирование, автоматизацию веб-приложений, контроль через live view и задачи с паузами, где standby действительно сокращает оплачиваемое время.

Самая распространённая ошибка при оценке состоит в учёте только цены одного браузерного часа. Реальные расходы агентного процесса формируют ещё три фактора: доля headful-запусков, количество одновременных сессий и время, когда CDP-соединение остаётся открытым без работы. Агент может выполнять полезное действие две минуты, а затем десять минут ждать решения модели. Если клиент не отключился, эти десять минут не перейдут в standby.

Возьмём команду, которая запускает 40 headful-задач в день в течение 30 дней. Каждая выполняет пять активных минут работы, но занимает пятнадцать календарных минут. При правильном отключении CDP это около 100 активных браузерных часов в месяц. Если соединение остаётся открытым все пятнадцать минут, оплачиваемое использование вырастет до 300 браузерных часов. До учёта кредитов плана разница для headful-режима составит около $96.

Второй риск связан с лимитом параллельных сессий. Free разрешает пять браузеров, поэтому шестая одновременная задача должна ждать или получить контролируемую ошибку. Увеличение количества рабочих процессов не повышает лимит Kernel. Добавьте очередь, ограничение времени ожидания слота и отдельную метрику active_sessions, чтобы всплеск нагрузки не превратился в серию хаотичных повторов.

Третий риск появляется в профилях. Два параллельных процесса, записывающих изменения, могут сохранить разные версии состояния браузера, и процесс, завершившийся позже, перезапишет предыдущее состояние. Для каждого профиля нужен mutex или очередь записи, общая для всех процессов и рабочих узлов, которые могут сохранять его состояние.

Блокировка только внутри одного процесса не предотвращает конфликты между разными исполнителями. Запуски без сохранения изменений профиля можно выполнять параллельно, но их влияние на серверное состояние авторизации следует тестировать отдельно.

Инфраструктурные лимиты измерить проще, чем поведение целевого сайта. Добавьте в POC телеметрию для 429, 403, страниц проверки, timeout и повторного входа. Отдельно считайте успешную загрузку страницы и завершение бизнес-действия: открытая панель управления ещё не означает, что агент смог скачать отчёт или отправить форму.

Перед выбором проведите короткий proof of concept:

1. выберите три типичных целевых URL
2. запустите по пять сессий в нужном режиме
3. измерьте создание сессии, подключение, загрузку страницы и общее время задачи
4. проверьте авторизацию после повторного запуска профиля
5. зафиксируйте CAPTCHA, 403, timeout и изменение выходного IP-адреса
6. рассчитайте активные GB-секунды и пиковое количество параллельных сессий
7. сравните результат с локальным Playwright или текущим браузерным стеком

После POC зафиксируйте критерии принятия решения: допустимую долю ошибок, предельное время выполнения и месячный бюджет. Сохраните конфигурацию теста и дату проверки, чтобы повторить измерения после обновления тарифов, Chromium или целевого сайта.

Как помогает Afina

Для команд с длительными разрешёнными аккаунтами проблема часто заключается не в скорости холодного запуска, а в изоляции cookie, прокси и отпечатков. Afina решает этот класс задач с помощью отдельных браузерных профилей и управляемой среды автоматизации. Это не делает Kernel слабее: продукты оптимизированы для разных рабочих моделей. Материал предоставлен исключительно в ознакомительных и образовательных целях.

Для агентных задач с пиковой нагрузкой сначала протестируйте Kernel на плане Free. Для длительных профилей оцените Afina на тех же целевых URL и с той же прокси-инфраструктурой. Сравнение будет честным только при одинаковых операциях, регионе и длительности сессии.