Огляд 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
• робота з дозволеним авторизованим кабінетом
• сценарій за участю людини з переглядом сесії в реальному часі (live view)
• паралельне QA-тестування кількох версій сторінки
• запуск computer-use агента в ізольованій VM

Для простого HTTP API, RSS або статичної сторінки хмарний Chromium часто зайвий. Спочатку перевірте, чи задача взагалі потребує повного браузера. Це економить і час, і бюджет.

Як працює Kernel.sh від створення сесії до видалення

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

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

Базове налаштування через 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 зафіксував невідповідність часового поясу IP.

Ці вимірювання не є універсальним сертифікатом. Публічний чекер бачить лише частину сигналів, тоді як антифрод-система в робочому середовищі враховує репутацію IP-адреси, історію акаунта, TLS, HTTP-заголовки й поведінку. Тест також не був незалежно відтворений командою Afina, тому його цифри слід читати як знімок конкретної конфігурації.

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

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

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

Якою є швидкість Kernel.sh і чому регіон змінює результат

У своєму порівняльному матеріалі Kernel заявляє про холодний запуск (cold start) менш як за 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-тестування, автоматизацію вебзастосунків, контроль через перегляд сесії в реальному часі і задачі з паузами, де 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, перевищення часу очікування і зміну вихідної IP-адреси
6. порахуйте активні GB-секунди та пікову кількість паралельних сесій
7. порівняйте результат із локальним Playwright або чинним браузерним стеком

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

Як допомагає Afina

Якщо команда працює з довготривалими дозволеними акаунтами, проблема часто полягає не у швидкості холодного запуску, а в ізоляції файлів cookie, проксі та відбитка. Afina розв’язує саме цей клас задач через окремі браузерні профілі й кероване середовище для автоматизації. Це не робить Kernel слабшим: продукти оптимізовані під різні робочі моделі. Матеріал надано виключно в ознайомчих та освітніх цілях.

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