Вкладка Шрёдингера в Claude in Chrome: она работает, только пока вы на неё смотрите

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

Я привык вести несколько дел сразу. Как-то в середине июля, после обеда, я дал Claude in Chrome три задачи одновременно. В первой вкладке он проверял функцию распознавания всплывающих окон в нашем браузере, во второй подбирал музыку к видео, а в третьей писал жалобу в поддержку Origin Energy, потому что они неправильно посчитали один мой счёт за электричество. Когда все три задачи пошли, я оставил браузер в фоне и вернулся в терминал, где через Claude Code руковожу своей командой ИИ-разработчиков. Ради этого мне агенты и нужны: несколько из них работают сами, и мне не надо присматривать за каждым.

Через какое-то время я переключился обратно в браузер, и оказалось, что из трёх задач сдвинулась только одна. Две другие будто задремали и так и остались, хотя я немного подождал и несколько раз пощёлкал по вкладкам.

Большинство первым делом подумало бы, что в тот день тормозила сеть или модель. Но если бы дело было в сети или в модели, замедлились бы все три задачи сразу, а здесь двигалась одна. Я много лет занимаюсь браузерами, и у меня сразу появилось другое объяснение: Chrome притормаживал фоновые вкладки.

Вообще-то это не изъян Chrome, браузер так и должен делать. Странице, на которую вы не смотрите, незачем работать на полной скорости, а у людей открыты десятки вкладок, и если бы каждая из них работала на полную, всё равно, на переднем плане она или нет, батарея ноутбука садилась бы за полдня. Беда в том, что страницы в браузере теперь существуют не только для того, чтобы на них смотрели люди, в них работают и ИИ-агенты. Для человека фоновая вкладка — это то, что ему сейчас не нужно. Для агента та же вкладка может ждать загрузку, добиваться возврата денег или держать чат с поддержкой, который нельзя упустить. На вкладку никто не смотрит, но дело у неё всё равно может быть.

Правила браузера писали для людей, и агентам они плохо подходят.

16 июля я проверил это вручную и убедился, что проблема именно в этом. В тот же день мы решили добавить в Embiody, браузер, который мы делаем для ИИ-агентов, функцию «ИИ-вкладки». Недавно я заново и как следует провёл те тесты, чтобы ответить на три вопроса: насколько сильно Chrome замедляет фоновую вкладку; когда Chrome замораживает страницу целиком; и самый неприятный: может ли агент прочитать что-то неверное со страницы, которая всё ещё открыта. Результаты оказались хуже, чем я ожидал.

1. Прошло восемь минут, а страница думает, что полторы#

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

Я открыл две копии этой страницы, одну открыл Claude in Chrome, а другую для сравнения открыл я сам, и потом на 8 минут убрал обе с глаз. Прятал я их тремя способами: переключался на другую вкладку, целиком закрывал окно другим окном и сворачивал окно. Все три способа дали почти одинаковый результат.

Первую минуту после того, как страница скрылась, ничего не менялось, и отсчёт по-прежнему шёл раз в секунду. Примерно через минуту он упал до одного тика в минуту. Через 8 минут в реальном мире прошло 480 секунд, а страница считала, что прошло около 90, то есть отстала на 390 секунд. Это как выйти на 8 минут позавтракать и, вернувшись, увидеть, что часы сдвинулись на полторы минуты. А когда я вернул окно, отсчёт снова пошёл раз в секунду, но потерянные минуты так и не наверстал.

Важнее другое: страница, которую открыл Claude in Chrome, вела себя точно так же, как та, что я открыл вручную: у Claude отставание 387–391 секунда, у моей 392. Значит, Claude тут ни при чём. То же самое происходит с любой страницей, открытой в Chrome, на которую никто не смотрит, а значит, на это наткнётся любой, кто запускает агента в Chrome.

(Windows 11, Chrome 157.0.8103.39, расширение Claude 1.0.106, 11 ноября 2026 г., один компьютер, 1–2 прогона на каждый случай.)

Отсюда напрашивается вопрос. Вкладки Claude in Chrome почти всё время сидят в фоне. Если фоновая вкладка сдвигается только раз в минуту, как он вообще что-то успевает? А ведь работу он явно доделывает.

2. Не спит только та вкладка, с которой работает агент#

Чтобы это выяснить, я сделал тестовую страницу, больше похожую на реальную задачу, с двумя видами ожидания, которые чаще всего встречаются на сайтах. Первый — загрузка: страница пишет «Загрузка начнётся через 90 секунд», и кнопку загрузки можно нажать, только когда отсчёт дойдёт до 0. Второй — экспорт: страница пишет «Идёт экспорт», каждые 2 секунды спрашивает сервер, готово ли, и сервер отвечает «да» через 90 секунд.

Потом я дал Claude in Chrome две такие задачи одновременно, одну во вкладке A, другую во вкладке B. Сначала он работал с A, а B лежала в фоне нетронутой. Вот что получилось:

Вот B из второго прогона в тот момент, когда я вернул окно. Посмотрите, сколько, по словам страницы, она уже ждёт:

Страница прождала 378 секунд реального времени, и ей оставалось ещё 6. Ожидание в 90 секунд растянулось на шесть-семь минут, и ровно это случилось со мной в тот июльский день. Агент всё это время работал, но всегда в A, а B ползла в фоне по тику в минуту. Когда он наконец заглянул в B, отсчёт, который давно должен был закончиться, всё ещё шёл. И это ещё повезло. Если бы агент так и не вернулся к B, то при одном тике в минуту этот 90-секундный отсчёт занял бы около получаса.

Странно то, что экспорт почти не пострадал. Сервер ответил, что всё готово, на 90-й секунде, а агент заметил это всего через 3 секунды.

Оба ожидания шли в фоновой вкладке, так почему Chrome замедлил отсчёт загрузки и не тронул экспорт?

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

Выходит, фоновое замедление не тормозит всю страницу равномерно, замедлится ли она, решает то, как она написана. Но и это ещё не самое плохое.

3. Через 20 секунд страница останавливается совсем#

Описанное выше замедление хотя бы рано или поздно доходит до конца. А вот следующее меня по-настоящему напугало. Claude in Chrome по умолчанию открывает новые вкладки в фоне, за той вкладкой, на которую вы смотрите. Я попросил его открыть тестовую вкладку и оставил её в покое, и всего через 20 секунд страница остановилась совсем. Отсчёт не шёл раз в минуту, он не шёл вообще, пока агент не вернулся и не сделал в ней что-нибудь. Я видел это четыре раза, всегда примерно на 20-й секунде, и всё это время окно браузера было прямо на экране, не закрытое другими окнами и не свёрнутое.

Окно на виду, так почему страница в нём вдруг замирает намертво?

Для сравнения я открыл ту же страницу в фоновой вкладке обычным способом. Через 3 минуты она всё ещё работала, просто замедлилась до тика в минуту, значит, эти 20 секунд как-то связаны с Claude in Chrome. Я какое-то время следил за полосой вкладок и наконец увидел: примерно через 20 секунд после последней команды агента группа вкладок Claude сама сворачивается, а когда группа вкладок свёрнута, Chrome замораживает те вкладки в ней, которые ни разу не показывались. Следите за полосой вкладок в этом ролике:

По отдельности и то и другое разумно. Claude in Chrome не хочет, чтобы куча его вкладок захватила вашу полосу вкладок, поэтому, когда ему нечего делать, прячет группу. Chrome считает свёрнутую группу вещами, убранными в ящик, которые вам пока не понадобятся, поэтому отключает им питание, чтобы сэкономить память. Но сложите эти два разумных правила, и каждая вкладка, которую агент открыл в фоне, засыпает, стоит агенту взять паузу.

Ну уж вкладка, в которой агент сейчас работает, наверняка в порядке? Я поручил агенту следить за двумя вкладками, A и B, и первые 3 минуты читать A каждые 30 секунд. A всё это время работала нормально, а B, которую никто не трогал, со второй минуты практически остановилась. Потом я велел ему переключиться на B. B тут же проснулась, но примерно через 30 секунд замёрзла уже A, которую только что оставили в покое.

Значит, когда агент трогает вкладку, она не спит всего двадцать-тридцать секунд. Стоит агенту переключиться на другое или просто задуматься подольше, группа сворачивается, и вкладка засыпает вместе с ней. Для человека это всего лишь браузер, который экономит немного памяти. Для агента всё гораздо хуже, потому что он понятия не имеет, что страница, которую он только что оставил, перестала работать.

4. Поддержка так и не дождалась YES#

Если замёрз отсчёт, что-то просто закончится позже. Если замёрз чат с поддержкой, дело сорвано. Чаты с поддержкой, онлайн-банк, страницы экзаменов и очереди за билетами ждут, что вы никуда не уйдёте, и каждые несколько секунд тихо сообщают серверу «я ещё здесь». Встаньте на минуту на место того, кто сидит в поддержке. Если собеседник 45 секунд не подаёт признаков жизни, что вы подумаете? Что он ушёл, и закроете сеанс. Моя июльская жалоба в Origin Energy шла как раз через такой чат.

Я сделал такую страницу поддержки. Она отмечается на сервере каждые 10 секунд, а сервер завершает чат, если 45 секунд ничего не слышит. Через минуту после начала чата поддержка пишет: "Reply YES and I will refund it today." (Ответьте YES, и я сегодня же оформлю возврат.)

Я снова дал Claude две вкладки. Сначала он доделал другую задачу в A, на это ушло полторы минуты. Потом, как это бывает, когда он уходит выполнять команды в терминале, полторы минуты не трогал браузер. Наконец он вернулся на страницу поддержки в B, чтобы ответить YES. Окно всё время оставалось на экране, впереди была моя собственная вкладка, а группа вкладок Claude за ней. Так он обычно и работает, ничего особенного.

Через двадцать секунд после того, как агент остановился, группа вкладок Claude свернулась, страница поддержки в B замёрзла, и отметки прекратились. Когда примерно через минуту агент вернулся к B, он увидел вот что:

Chat ended: no check-in from this page for 83 s. Please sign in again to start a new chat. (Чат завершён: эта страница не отмечалась 83 с. Войдите снова, чтобы начать новый чат.)

Заметьте, сервер смотрит на то, сколько страница молчит, а не на то, сколько длится чат. Пока страница отмечается, она может висеть сколько угодно. B отвалилась потому, что после заморозки молчала 83 секунды.

Поле ввода и кнопка отправки уже посерели. YES отправить было уже нельзя, поддержка ушла, и возврат повис в воздухе. Войти заново за вас агент тоже не может, так что всё ждёт, пока вы вернётесь и встанете в очередь с самого начала. Я прогнал ту же задачу в Embiody, и агент так же отсутствовал полторы минуты. Там страница поддержки продолжала отмечаться каждые 10 секунд и всё время показывала Connected, YES ушёл, и поддержка ответила "Done, the refund is on its way." (Готово, возврат уже в пути.) Вот оба варианта рядом, слева Chrome, справа Embiody:

Вы можете возразить: выше я говорил, что ожиданию ответа от сервера замедление не страшно, а отметки поддержки устроены именно так, почему же связь оборвалась? Верно: будь там только замедление, страница поддержки всё равно отмечалась бы каждые 10 секунд. Сломала её заморозка. Замедление лишь заставляет будильники, которые страница заводит сама себе, звенеть раз в минуту. Заморозка отключает питание всей странице. Всё в ней останавливается, и будильники, и ожидание ответного звонка, так что отметки, конечно, тоже прекращаются.

Тогда почему бы просто не сделать, чтобы расширение не сворачивало группу? На самом деле оно сворачивает её только в одном случае: когда на переднем плане окна показана ваша вкладка. Я попробовал перенести группу вкладок Claude в отдельное окно, чтобы впереди была одна из вкладок Claude. Тогда расширение группу не сворачивало, страница поддержки только замедлялась и оставалась на связи 11 минут подряд. Но кто станет открывать для него отдельное окно? Его группа вкладок живёт в том окне, которым пользуетесь вы.

Если посмотреть со стороны Claude in Chrome, ему деваться некуда. Он делит с вами один браузер и одно окно. Если не сворачивать группу, его вкладки так и будут разложены по вашей полосе вкладок и мешать вам. Если сворачивать, Chrome по своим правилам их заморозит. Сворачивание — продуктовое решение самого расширения, а заморозка — правило Chrome, и расширение может изменить только первое. И даже если бы оно никогда не сворачивало группу, его вкладки всё равно стояли бы за вашими, всё равно были бы не видны и всё равно замедлялись бы.

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

(12 ноября 2026 г., Chrome 157.0.8103.51, расширение 1.0.106, по одному прогону.)

5. Страница думает, что на неё смотрят, но её никто не рисует#

Если бы на этом всё и кончалось, проблема и так была бы большой. Но я нашёл ещё одну, менее заметную. На этот раз страница не была заморожена, таймеры шли точно, и страница даже считала себя видимой, а картинка на ней почти не двигалась.

Я сделал страницу с двумя полосками прогресса. Зелёная движется со временем, на шаг в секунду. Красная движется вместе с кадрами, которые браузер действительно отрисовал, понемногу на каждый кадр. Я поручил Claude две минуты работать с этой страницей в фоновой вкладке: один раз нажать, чтобы включить музыку, а потом каждые 10 секунд прокручивать список и читать страницу. В конце я вывел вкладку на передний план.

В тот момент, когда она оказалась впереди, зелёная полоска была заполнена, а красная едва тронулась с места. Таймер показывал, что прошло 184 секунды, но отрисовано было всего около 620 кадров, а при обычных 60 кадрах в секунду должно было быть около 11 000. За первые 100 секунд страница отрисовала всего 387 кадров, в среднем меньше 4 в секунду, а человеку такое кажется слайд-шоу. Страница считала, что на неё смотрят, но рендерер на самом деле её не рисовал.

Итак, картинка рисуется медленно. Ну и что? А то, что многие сайты любят показывать цифры с анимацией. Вспомните «Нам доверяют 98 765 компаний» на главной странице какой-нибудь фирмы: при открытии страницы число бежит вверх от 0 и через две-три секунды замирает на итоговом значении. Если агент откроет такую страницу в фоне, где ничего не рисуется, число может застрять на полпути.

Я сделал страницу, которая за 3 секунды досчитывает от 0 до 98 765, попросил Claude открыть её в новой фоновой вкладке, заняться чем-то другим и через 10 секунд вернуться и прочитать число. Результаты:

Этот ролик показывает, что делали две фоновые вкладки, пока агент был занят другим:

Chrome за три прогона дал три разных числа, потому что страница сидела скрытой в фоне, не отрисовав ни одного кадра, и число стояло на 0. В момент, когда агент пришёл его прочитать, расширение сделало страницу «видимой», число только тогда и начало расти, а агент не стал ждать конца и прочитал то, до чего успело досчитать. Это как фотографировать бегуна на дистанции: когда бы вы ни нажали на спуск, вы застанете его где-то посреди дорожки.

Хуже всего то, что агент не скажет вам, что число может быть неверным. Ошибки нет, и у него нет никакого способа узнать, что он видел незаконченную анимацию. С его точки зрения страница открылась, число прочитано, всё в порядке. Если он прочитает один раз, то выдаст вам неверное число как факт. И это всего лишь моя собственная тестовая страница. Представьте агента, который в фоновой вкладке пытается урвать для вас билеты на концерт или товар на распродаже.

(12 ноября 2026 г., Chrome 157.0.8103.51, расширение 1.0.106.)

6. Вкладка Шрёдингера#

Всё это напомнило мне кота Шрёдингера. В том знаменитом мысленном эксперименте, пока коробку не открыли, никто не может сказать, жив кот или мёртв. С вкладкой агента в Chrome примерно так же. Пока вы на неё смотрите, она работает как надо. Когда не смотрите, она может сдвигаться раз в минуту, а может уже быть заморожена. Когда агент что-то делает во вкладке, это всё равно что открыть коробку и заглянуть, и вкладка на время просыпается. Когда агент уходит, коробка снова закрывается, и на этот раз коробку даже видно: это группа вкладок, которая сама себя сворачивает.

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

Чтобы понять, что за всем этим стоит, я прошёлся по исходному коду Chromium 156 (он ведёт себя так же, как проверенный мной 157) вместе с кодом расширения Claude in Chrome 1.0.106 и нашёл семь правил, наложенных друг на друга.

7. Что на самом деле говорят эти семь правил#

В этом разделе семь правил из истории выше разобраны по одному по исходному коду Chromium. Он для тех, кто хочет докопаться до сути или сам сверить исходники. Если вас интересует только то, что происходит, достаточно знать, что «фоновые вкладки замедляются, замораживаются и не рисуются», и можно сразу перейти к разделу 8 «А нельзя просто отключить ограничения Chrome?», ничего не упустив дальше.

1. Цепочки таймеров на скрытой странице после льготного периода могут просыпаться только раз в минуту. В исходниках Chrome это называется intensive wake-up throttling (интенсивное ограничение пробуждений). Что это значит? Это тот самый будильник, который страница заводит сама себе: таймер срабатывает, и его колбэк заводит следующий таймер. Chrome считает, насколько глубока цепочка, и начиная с 7-го уровня, если страница уже какое-то время скрыта, такие таймеры могут срабатывать только раз в минуту. Отсчёт написан именно так, поэтому и попадается. Таймер, заведённый после ответа сервера, снова начинает счёт с 1-го уровня, поэтому экспорт и отметки поддержки не затронуты. Льготный период после скрытия страницы обычно 60 секунд, и вкладка, которую агент открыл в фоне и которая ни разу не показывалась, тоже получает 60 секунд. Скрытием считается и переключение на другую вкладку, и окно, целиком закрытое другим окном, и свёрнутое окно. Есть ещё два ограничения помягче: ни один таймер не просыпается чаще раза в секунду, а после 10 секунд в скрытом состоянии все колбэки таймеров вместе могут занимать только 1 % процессора, что важно лишь для страниц, которые делают в колбэках тяжёлую работу. (third_party/blink/renderer/platform/scheduler/main_thread/page_scheduler_impl.cc; уровень вложенности в third_party/blink/renderer/core/scheduler/dom_timer.cc)

2. Когда группа вкладок сворачивается, вкладки в ней замораживаются. Как только группа свёрнута, Chrome отдаёт голос «заморозить» за каждую вкладку в ней. Вкладки, которые показывались за последние 5 минут, защищены, а ни разу не показанные замораживаются на месте. Заморозка означает, что весь код страницы до последней строчки останавливается. Страница не замедляется, а вообще не движется, как будто этому ящику отключили питание. (chrome/browser/ui/views/tabs/browser_tab_strip_controller.cc отдаёт голос; components/performance_manager/freezing/freezing_policy.cc решает)

3. Примерно через 20 секунд простоя Claude in Chrome сворачивает собственную группу вкладок. Это происходит, только когда вкладка на переднем плане окна не его, а когда снова появляется работа, расширение сначала разворачивает группу. Правило 3 плюс правило 2 и дают ту «смерть через 20 секунд», которую мы видели выше: расширение сворачивает группу, а Chrome замораживает вкладки в ней.

4. Расширение убеждает вкладку, с которой работает, что «на неё кто-то смотрит». Перед каждым действием расширение через протокол отладки включает переключатель под названием эмуляция фокуса (Emulation.setFocusEmulationEnabled). Что он делает? Сообщает Chrome, что «на эту вкладку смотрят», поэтому visibilityState страницы становится visible, и её таймеры больше не замедляются так, как у скрытых страниц, даже если всё окно свёрнуто. Примерно через 20 секунд после действия расширение снова выключает переключатель.

Правила 3 и 4 вместе объясняют и одну странность: почему вкладка, в которой агент работал последней, иногда не замораживается, когда группа сворачивается. Я думал, что расширение нарочно её бережёт, но код показал, что это чистое совпадение. Когда группа сворачивается, Chrome отправляет команду заморозки каждой вкладке в ней. У вкладки, которой агент касался последней, в этот момент ещё включена эмуляция фокуса, она считает, что на неё смотрят, и отказывается выполнять команду. Но Chrome отказа не замечает, всё равно записывает вкладку как «замороженную» и больше команду не шлёт. Когда эмуляция фокуса выключается и вкладку уже действительно не видно, никто так и не возвращается, чтобы её заморозить.

Скажу проще: вахтёрша в общежитии вечером обходит комнаты перед отбоем, вы кричите из-за двери «тут ещё не спят», она пишет в журнал «свет погашен» и уходит, чтобы больше не вернуться, а когда вы засыпаете, свет так и горит всю ночь. Эта вкладка не спит только потому, что «группа сворачивается» и «эмуляция фокуса выключается» случились именно в таком порядке, и ни расширение, ни Chrome так не задумывали. Раньше, когда агент перешёл с A на B, A попала на обратный порядок: её эмуляция фокуса выключилась первой, поэтому, когда группа свернулась, A уже не было видно, и заморозка подействовала сразу, как пришла.

5. Странице, которая на самом деле не выводится на экран, урезают кадры до одного в секунду. Эмуляция фокуса может обмануть страницу, чтобы та думала, что на неё смотрят, но не может обмануть ту часть, которая рисует картинку. В Chrome есть сервис композитинга под названием viz, который посылает каждой вкладке сигнал «начинай рисовать следующий кадр» (BeginFrame) в такт с дисплеем. Если 3 кадра подряд от вкладки так и не были выведены на экран ни одним окном, этот сигнал падает до раза в секунду, и комментарий в исходниках говорит об этом прямо: "we throttle BeginFrames to 1 per second" (components/viz/service/frame_sinks/compositor_frame_sink_support.h, kUndrawnFrameLimit = 3). Поэтому вкладки, которые стоят за другими или лежат в свёрнутом окне, могут выполнять requestAnimationFrame (функцию, которой веб-страницы рисуют анимацию) только раз или два в секунду, даже если таймеры у них идут нормально. Это как камера, направленная на сцену: актёры продолжают играть, но камера замечает, что трансляцию никто не смотрит, и переходит на один снимок в секунду. Из тех меньше чем 4 кадров в секунду, что я намерил, лишние два-три, скорее всего, отрисованы попутно, когда расширение делает скриншоты.

6. Закрытое другим окном или свёрнутое окно тоже считается невидимым. В Windows Chrome сам вычисляет, полностью ли окно закрыто другими окнами, и если да, считает его вкладки скрытыми (ui/aura/native_window_occlusion_tracker_win.cc, включено по умолчанию). Когда окно свёрнуто, вся его область композитинга становится 0×0 (desktop_window_tree_host_win.cc).

7. Фоновые процессы рендерера тоже понижают. Если у процесса рендерера нет ни одной видимой вкладки, Chrome опускает его до самого низкого приоритета и просит у Windows EcoQoS, то есть запускать его на самой энергоэкономной частоте процессора и переносить его работу на энергоэффективные ядра ценой скорости (base/process/process_win.cc, kUseEcoQoSForBackgroundProcess включено по умолчанию). Это правило смотрит, действительно ли окно видно, поэтому эмуляция фокуса его не обманет.

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

8. А нельзя просто отключить ограничения Chrome?#

Можно подумать, что раз виноваты правила Chrome, их можно отключить флагами запуска. Отчасти да. --disable-background-timer-throttling, --intensive-wake-up-throttling-policy=0, --disable-renderer-backgrounding и --disable-backgrounding-occluded-windows отключают замедление таймеров и понижение процессов. Но правило про кадры не отключить. Вкладка, которая не выводится на экран, не получит обратно нормальные кадры оттого, что вы отключили замедление таймеров, так что агент по-прежнему может прочитать недосчитанное число.

9. Те же тесты в Embiody#

Мы делаем Embiody, браузер для Windows, созданный для ИИ-агентов. Агенты работают в нём через BrowserDo, MCP-сервер, сделанный специально для него. Claude Code и Codex подключаются одной командой, а Cursor и Claude Desktop несколькими строками конфигурации. Функция ИИ-вкладок началась с того июльского дня: мне хотелось, чтобы агенты делали несколько дел сразу, а я тем временем занимался своей работой.

Поэтому я прогнал все тесты выше в Embiody в тех же условиях, поменяв только браузер на Embiody, а инструмент на BrowserDo. Результаты:

В Embiody задача B заканчивается вовремя, даже когда она стоит за другими вкладками, никто её не трогает, а окно свёрнуто. Страница, с которой агент работает в фоне, продолжает рисоваться, число на странице статистики читается правильно с первого раза, а чат с поддержкой остаётся на связи. Но это касается только вкладок, которыми пользуется агент. Вкладки, которые вы открываете сами, в фоне по-прежнему замедляются по обычным правилам энергосбережения, так что из-за агента в браузере ваши собственные вкладки не станут тратить больше энергии. Кот в коробке не спит. Справедливости ради, это был один компьютер с Windows и 1–2 прогона на тест для Embiody, совсем не масштабное испытание, но по крайней мере в этих сценариях разница видна ясно.

И ещё одно надо сказать прямо: эти проблемы не только у Claude in Chrome. Каким бы расширением или инструментом автоматизации вы ни пользовались, агенту, который работает в Chrome, приходится жить по правилам Chrome. В тесте с отсчётом в самом начале вкладка, которую я открыл вручную, за 8 минут отстала больше чем на 390 секунд, точно так же, как вкладка Claude. Есть ещё два правила, на которые я в этот раз не наткнулся. Когда компьютеру не хватает памяти, Chrome выгружает фоновую вкладку, на которую дольше всего не смотрели, и, когда вы к ней возвращаетесь, она загружается заново. А когда ноутбук отключён от розетки и заряд ниже 20 %, фоновые вкладки, которые заметно нагружают процессор, замораживаются. Человек, который отошёл и попал под одно из этих правил, вернётся и просто обновит страницу. Агент, который с обеда до вечера присматривает сразу за несколькими страницами, рано или поздно попадёт под них.

10. ИИ нужен свой браузер#

За несколько лет работы с ИИ я всё больше уверен в одном: ИИ нужен собственный браузер, а обходиться Chrome — это временная мера.

Я не говорю, что Chrome плохо делает своё дело. Эти правила годами оттачивали, чтобы человеку перед экраном было удобнее: вкладки, которых вы не видите, должны тратить меньше, анимацию, которую никто не видит, незачем рисовать, а страницы, которыми долго не пользуются, нужно замораживать и даже выгружать. Расширение может только добавить ещё один слой поверх этих правил, например эмуляцией фокуса заставить страницу думать, что на неё смотрят, или сворачивать свою группу вкладок, чтобы вкладки агента вам не мешали. Но правила принадлежат Chrome, а архитектура Chrome создавалась для людей. Не меняя её в основе, расширение может только латать дыры.

Та вкладка из рассказа выше, где вахтёрша записала «свет погашен», и есть результат латания. Она не спит только потому, что две вещи случайно произошли в определённом порядке. Любая новая версия Chrome может этот порядок изменить, а такие совпадения нельзя ни обойти, ни предсказать, потому что Chrome никогда не проектировали для агентов.

Чтобы не полагаться на совпадения, сами правила браузера должны учитывать агентов. Для человека то, видна ли вкладка, решает, должна ли она и дальше тратить ресурсы. Для агента вкладка, на которую никто не смотрит, может быть занята для вас делом, которое нельзя поставить на паузу, и она должна продолжать работать, сидит кто-то перед экраном или нет. Решить это можно только в самом движке браузера, и именно на этом принципе построены ИИ-вкладки Embiody.

(Embiody: 1–2 прогона на тест, 11–12 ноября 2026 г., тот же компьютер.)

Что я не проверял#

• Один компьютер с Windows и одна версия Chrome. Когда я проверял вручную в июле, мне запомнилось, что замедление становилось заметным только через 5 минут; в этот раз (Chrome 157) примерно через 1 минуту. Не знаю, изменился ли Chrome или я неправильно запомнил.
• Ни Mac, ни Linux, и ничего с включённым режимом экономии памяти (Memory Saver).
• Выгрузка вкладок при нехватке памяти и заморозка вкладок при низком заряде известны мне только из исходников, я их не измерял.

Попробуйте сами за две минуты#

Откройте https://embiody.com/lab/background-tab/. Там запустится обратный отсчёт на 15 минут. Переключитесь на другую вкладку (можно также закрыть окно другим окном или свернуть его), вернитесь через две минуты и посмотрите на «Behind by» (отставание): это столько секунд, сколько отсчёт потерял, пока вас не было. 0 s означало бы, что страница всё время шла точно. Тестовая страница на английском.

Напоследок#

Не знаю, поменяет ли Chrome когда-нибудь эти правила ради агентов. Доводы у него веские: экономить энергию и память и сохранять плавность на переднем плане — ровно то, чем браузер и должен заниматься. Просто браузер исходил из того, что перед экраном сидит человек и смотрит на одну вкладку за раз, а теперь перед экраном может вообще никого не быть, а за вкладками сидит агент, который присматривает сразу за несколькими страницами.

Пока на неё не смотришь, она не работает. А ведь агент работает как раз тогда, когда вы не смотрите.