Der Schrödinger-Tab von Claude in Chrome: Er arbeitet nur, solange du hinsiehst

Warum KI-Agenten in den Hintergrund-Tabs von Chrome langsamer werden, einschlafen und sogar einen Support-Chat abreißen lassen.

Ich arbeite gern an mehreren Dingen gleichzeitig. An einem Nachmittag Mitte Juli gab ich Claude in Chrome drei Aufgaben auf einmal. Im ersten Tab prüfte es die Pop-up-Erkennung unseres Browsers, im zweiten suchte es Hintergrundmusik, die zu einem Video passt, und im dritten setzte es eine Beschwerde an den Kundenservice von Origin Energy auf, weil die mir eine Stromrechnung falsch berechnet hatten. Als alle drei liefen, schob ich den Browser in den Hintergrund und ging zurück ins Terminal, wo ich mit Claude Code mein KI-Entwicklerteam steuere. Genau darum geht es mir bei Agenten ja: Mehrere arbeiten selbstständig, und ich muss nicht jeden einzeln beaufsichtigen.

Als ich eine Weile später zum Browser zurückwechselte, war nur eine der drei Aufgaben vorangekommen. Die anderen beiden sahen aus, als wären sie eingenickt, und daran änderte sich auch nichts, als ich etwas wartete und ein paarmal zwischen den Tabs hin- und herklickte.

Die meisten würden zuerst auf ein langsames Netz tippen oder auf ein Modell, das an dem Tag schwächelt. Wären aber Netz oder Modell schuld gewesen, hätten alle drei Aufgaben gemeinsam langsamer werden müssen, und hier bewegte sich nur eine. Ich arbeite seit vielen Jahren an Browsern, und mir kam sofort eine andere Erklärung in den Sinn: Chrome drosselte die Hintergrund-Tabs.

Ein Fehler von Chrome ist das eigentlich nicht, ein Browser soll genau das tun. Eine Seite, die du gerade nicht ansiehst, hat keinen Grund, mit voller Geschwindigkeit zu laufen, und viele Leute haben Dutzende Tabs offen. Würde jeder davon Vollgas geben, egal ob vorne oder hinten, wäre ein Laptop-Akku nach einem halben Tag leer. Nur sind Seiten im Browser heute nicht mehr bloß dafür da, dass Menschen sie ansehen, auch KI-Agenten arbeiten darin. Für einen Menschen ist ein Hintergrund-Tab etwas, das er gerade nicht braucht. Für einen Agenten wartet derselbe Tab vielleicht auf einen Download, bringt gerade eine Rückerstattung durch oder hält einen Support-Chat, der nicht abreißen darf. Ein Tab, den niemand ansieht, kann trotzdem Arbeit zu erledigen haben.

Die Regeln des Browsers wurden für Menschen geschrieben, und zu Agenten passen sie schlecht.

Am 16. Juli habe ich es von Hand getestet und bestätigt, dass genau das das Problem war. An diesem Tag haben wir auch beschlossen, Embiody, dem Browser, den wir für KI-Agenten bauen, eine Funktion namens „KI-Tabs“ zu geben. Vor Kurzem habe ich die Tests von damals noch einmal sauber wiederholt, um drei Fragen zu beantworten: wie stark Chrome einen Hintergrund-Tab ausbremst; wann Chrome eine Seite komplett einfriert; und die unangenehmste, ob ein Agent aus einer Seite, die noch offen ist, etwas Falsches lesen kann. Die Ergebnisse waren schlimmer, als ich erwartet hatte.

1. Acht Minuten vergehen, die Seite glaubt, es seien anderthalb#

Ich habe mit der gewöhnlichsten Countdown-Seite angefangen, die einmal pro Sekunde tickt, so geschrieben wie die Countdowns auf Checkout- und Bezahlseiten. Bei jedem Tick meldet die Seite ihren Stand an einen kleinen Server auf demselben Rechner, sodass der Server auch dann noch festhält, was wirklich passiert ist, wenn der Browser die Seite einfriert.

Ich habe zwei Exemplare dieser Seite geöffnet, eines hat Claude in Chrome geöffnet und eines ich selbst zum Vergleich, und dann beide 8 Minuten lang außer Sicht gehalten. Dabei habe ich drei Arten ausprobiert, sie zu verstecken: zu einem anderen Tab wechseln, das Fenster komplett mit einem anderen Fenster verdecken und das Fenster minimieren. Alle drei lieferten fast genau dasselbe Ergebnis.

In der ersten Minute, nachdem eine Seite aus dem Blick verschwunden war, änderte sich nichts, und der Countdown lief weiter einmal pro Sekunde. Nach etwa einer Minute fiel er auf einen Tick pro Minute. Nach 8 Minuten waren in der echten Welt 480 Sekunden vergangen, die Seite glaubte aber, es seien erst etwa 90, und lag damit 390 Sekunden zurück. Das ist, als würdest du 8 Minuten frühstücken gehen und bei der Rückkehr feststellen, dass die Uhr gerade mal anderthalb Minuten weitergegangen ist. Und als ich das Fenster zurückholte, lief der Countdown zwar wieder einmal pro Sekunde, aber die verlorenen Minuten wurden nie aufgeholt.

Wichtiger noch: Die Seite, die Claude in Chrome geöffnet hatte, verhielt sich genau wie die, die ich von Hand geöffnet hatte, mit 387 bis 391 Sekunden Rückstand bei Claudes Seite und 392 bei meiner. Mit Claude hat das also nichts zu tun. Jede Seite, die in Chrome offen ist und die niemand ansieht, endet so, und das heißt, jeder, der einen Agenten in Chrome laufen lässt, wird darauf stoßen.

(Windows 11, Chrome 157.0.8103.39, Claude-Erweiterung 1.0.106, 11. November 2026, ein Rechner, 1 bis 2 Durchläufe pro Fall.)

Damit stellt sich eine naheliegende Frage. Die Tabs von Claude in Chrome liegen fast die ganze Zeit im Hintergrund. Wenn sich ein Hintergrund-Tab nur einmal pro Minute bewegt, wie bekommt es dann überhaupt etwas erledigt? Und trotzdem schafft es seine Arbeit ganz offensichtlich.

2. Nur der Tab, an dem der Agent gerade arbeitet, bleibt wach#

Um das herauszufinden, habe ich eine Testseite gebaut, die näher an einer echten Aufgabe ist, mit den zwei Arten von Warten, die man auf Websites am häufigsten sieht. Die erste ist ein Download: Die Seite sagt „Dein Download startet in 90 Sekunden“, und der Download-Button wird erst klickbar, wenn der Countdown bei 0 ankommt. Die zweite ist ein Export: Die Seite zeigt „Export läuft“, fragt alle 2 Sekunden beim Server nach, ob er fertig ist, und der Server sagt nach 90 Sekunden ja.

Dann ließ ich Claude in Chrome zwei solche Aufgaben gleichzeitig erledigen, eine in Tab A und eine in Tab B. Es arbeitete zuerst an A, und B lag unberührt im Hintergrund. Das ist passiert:

Hier ist B aus dem zweiten Durchlauf, in dem Moment, in dem ich das Fenster zurückholte. Achte darauf, wie lange die Seite nach eigener Aussage schon gewartet hat:

Die Seite hatte 378 Sekunden echte Zeit gewartet und noch 6 Sekunden vor sich. Aus 90 Sekunden Warten wurden sechs, sieben Minuten, und genau das war mir an jenem Nachmittag im Juli passiert. Der Agent arbeitete die ganze Zeit, nur eben immer in A, während B im Hintergrund mit einem Tick pro Minute dahinkroch. Als er sich B endlich ansah, lief ein Countdown, der längst hätte fertig sein sollen, immer noch. Und das war noch der glimpfliche Fall. Wäre der Agent nie zu B zurückgekommen, hätte dieser 90-Sekunden-Countdown bei einem Tick pro Minute ungefähr eine halbe Stunde gebraucht.

Seltsam war, dass der Export kaum betroffen war. Der Server meldete nach 90 Sekunden, dass er fertig war, und der Agent bemerkte es nur 3 Sekunden später.

Beides war Warten in einem Hintergrund-Tab, warum hat Chrome dann den Download-Countdown gebremst und den Export in Ruhe gelassen?

Der Unterschied liegt darin, wie die beiden Wartevorgänge geschrieben sind. Der Countdown stellt sich seinen Wecker selbst: Wenn der Wecker dieser Sekunde klingelt, stellt er den nächsten, und wenn der klingelt, den übernächsten, jeder Wecker an den vorigen gekettet. Der Export wartet auf einen Rückruf: Er fragt beim Server nach, und erst wenn der Server geantwortet hat, plant er die nächste Frage, also beginnt jede Runde frisch mit der Antwort von jemand anderem. Chrome hat eine Regel, die genau auf solche verketteten Wecker zielt. Ist eine Seite eine Weile außer Sicht, dürfen diese Wecker nur noch einmal pro Minute klingeln. Deshalb wurde der Countdown langsamer, während der Export, der auf einen Rückruf wartet, gar nicht unter diese Regel fällt.

Die Hintergrund-Drosselung bremst eine Seite also nicht gleichmäßig aus. Wie die Seite geschrieben ist, entscheidet darüber, ob sie langsamer wird. Aber das ist noch nicht das Schlimmste.

3. Nach 20 Sekunden steht die Seite komplett still#

Die Verlangsamung oben kommt wenigstens irgendwann ans Ziel. Die nächste hat mich ehrlich erschreckt. Claude in Chrome öffnet neue Tabs standardmäßig im Hintergrund, hinter dem Tab, den du gerade ansiehst. Ich ließ es einen Test-Tab öffnen und dann in Ruhe, und schon nach 20 Sekunden blieb die Seite komplett stehen. Der Countdown bewegte sich nicht einmal pro Minute, er bewegte sich überhaupt nicht mehr, bis der Agent zurückkam und etwas darin tat. Das habe ich viermal gesehen, immer nach etwa 20 Sekunden, und das Browserfenster war die ganze Zeit auf dem Bildschirm zu sehen, weder verdeckt noch minimiert.

Das Fenster ist gut sichtbar, warum sollte eine Seite darin plötzlich stocksteif stehen bleiben?

Zum Vergleich öffnete ich dieselbe Seite auf normalem Weg in einem Hintergrund-Tab. Nach 3 Minuten lief sie noch, nur eben mit einem Tick pro Minute, also mussten die 20 Sekunden etwas mit Claude in Chrome zu tun haben. Ich beobachtete eine Weile die Tableiste und sah es schließlich: Etwa 20 Sekunden nach dem letzten Befehl des Agenten klappte die Tabgruppe von Claude von selbst zu, und sobald eine Tabgruppe zugeklappt ist, friert Chrome die Tabs darin ein, die noch nie angezeigt wurden. Behalte in diesem Clip die Tableiste im Auge:

Für sich genommen ergibt beides Sinn. Claude in Chrome will nicht, dass sein Stapel Tabs deine Tableiste übernimmt, also räumt es die Gruppe weg, sobald es untätig ist. Chrome behandelt eine zugeklappte Gruppe wie Sachen, die in eine Schublade gelegt wurden und die du eine Weile nicht brauchst, und dreht ihnen deshalb den Strom ab, um Speicher zu sparen. Kommen die beiden vernünftigen Regeln aber zusammen, schläft jeder Tab, den der Agent im Hintergrund geöffnet hat, ein, sobald der Agent eine Pause macht.

Der Tab, an dem der Agent tatsächlich arbeitet, ist doch sicher in Ordnung? Ich ließ den Agenten zwei Tabs betreuen, A und B, und in den ersten 3 Minuten alle 30 Sekunden A lesen. A lief die ganze Zeit normal, während B, den niemand anrührte, ab der zweiten Minute praktisch stillstand. Dann ließ ich ihn stattdessen B lesen. B wachte sofort auf, aber etwa 30 Sekunden später war A, der gerade erst liegen gelassen worden war, ebenfalls eingefroren.

Wenn ein Agent einen Tab anfasst, bleibt dieser Tab also nur zwanzig, dreißig Sekunden wach. Sobald sich der Agent etwas anderem zuwendet oder einfach etwas länger nachdenkt, klappt die Gruppe zu, und der Tab schläft mit ihr ein. Für einen Menschen spart der Browser damit nur etwas Speicher. Für einen Agenten ist es viel schlimmer, denn er hat keine Ahnung, dass die Seite, die er gerade verlassen hat, nicht mehr arbeitet.

4. Der Support hat das YES nie bekommen#

Ein eingefrorener Countdown heißt nur, dass etwas zu spät fertig wird. Ein eingefrorener Support-Chat heißt, dass die Aufgabe scheitert. Live-Support-Chats, Onlinebanking, Prüfungsseiten und Ticket-Warteschlangen erwarten alle, dass du anwesend bleibst, und alle paar Sekunden sagen sie dem Server leise „bin noch da“. Versetz dich einen Moment lang in die Support-Seite des Chats. Wenn vom anderen Ende 45 Sekunden lang kein Lebenszeichen kommt, was nimmst du an? Dass die Person gegangen ist, und du schließt die Sitzung. Meine Beschwerde an Origin Energy im Juli lief über genau so einen Chat.

Ich habe so eine Support-Seite gebaut. Sie meldet sich alle 10 Sekunden beim Server, und der Server beendet den Chat, wenn er 45 Sekunden lang nichts hört. Eine Minute nach Chatbeginn schreibt der Support: „Reply YES and I will refund it today.“ (Antworte mit YES, dann erstatte ich es dir heute.)

Wieder ließ ich Claude zwei Tabs betreuen. Zuerst erledigte es in A eine andere Aufgabe, was anderthalb Minuten dauerte. Dann ließ es den Browser anderthalb Minuten in Ruhe, so wie es das tut, wenn es im Terminal Befehle ausführt. Schließlich ging es zur Support-Seite in B zurück, um mit YES zu antworten. Das Fenster blieb die ganze Zeit auf dem Bildschirm, mein eigener Tab war vorne und die Tabgruppe von Claude dahinter. So läuft es normalerweise, nichts Ungewöhnliches.

Zwanzig Sekunden nachdem der Agent aufgehört hatte, klappte die Tabgruppe von Claude zu, die Support-Seite in B wurde eingefroren, und die Meldungen an den Server hörten auf. Als der Agent etwa eine Minute später zu B zurückkam, fand er das hier vor:

Chat ended: no check-in from this page for 83 s. Please sign in again to start a new chat. (Chat beendet: Diese Seite hat sich seit 83 s nicht gemeldet. Bitte melde dich erneut an, um einen neuen Chat zu starten.)

Wohlgemerkt schaut der Server darauf, wie lange die Seite stumm war, nicht darauf, wie lange der Chat schon offen ist. Solange sich die Seite regelmäßig meldet, kann sie dort beliebig lange liegen. B ist rausgeflogen, weil er nach dem Einfrieren 83 Sekunden lang keinen Ton mehr von sich gegeben hat.

Das Eingabefeld und der Senden-Button waren bereits ausgegraut. Das YES ließ sich nicht mehr senden, der Support hatte aufgelegt, und aus der Rückerstattung wurde nichts. Der Agent kann sich auch nicht in deinem Namen neu anmelden, also bleibt das liegen, bis du zurück bist und dich wieder ganz hinten anstellst. Ich habe dieselbe Aufgabe in Embiody laufen lassen, und der Agent war genauso anderthalb Minuten weg. Dort meldete sich die Support-Seite weiter alle 10 Sekunden und zeigte die ganze Zeit Connected, das YES ging durch, und der Support antwortete „Done, the refund is on its way.“ (Erledigt, die Rückerstattung ist unterwegs.) Hier die beiden nebeneinander, links Chrome, rechts Embiody:

Du könntest einwenden, ich hätte vorhin gesagt, dass das Warten auf die Antwort des Servers gegen die Verlangsamung immun ist, und die Meldung der Support-Seite funktioniert genau so, warum ist sie dann abgerissen? Richtig, mit der Drosselung allein würde sich die Support-Seite weiter alle 10 Sekunden melden. Kaputt gemacht hat es das Einfrieren. Die Drosselung sorgt nur dafür, dass selbst gestellte Wecker einmal pro Minute klingeln. Das Einfrieren dreht der ganzen Seite den Strom ab. Alles darin hält an, selbst gestellte Wecker genauso wie das Warten auf einen Rückruf, also hören natürlich auch die Meldungen auf.

Warum gewöhnt man der Erweiterung dann nicht einfach das Zuklappen ab? Tatsächlich klappt sie nur in einer einzigen Situation zu, nämlich wenn der Tab, der vorne im Fenster angezeigt wird, einer von deinen ist. Ich habe versucht, die Tabgruppe von Claude in ein eigenes Fenster zu verschieben, sodass der vordere Tab einer von Claudes war. Dann klappte die Erweiterung nicht zu, die Support-Seite wurde nur gedrosselt und blieb 11 Minuten am Stück verbunden. Aber wer öffnet dafür schon extra ein eigenes Fenster? Ihre Tabgruppe lebt in dem Fenster, das du gerade benutzt.

Versetzt man sich in Claude in Chrome hinein, sitzt es in der Klemme. Es teilt sich einen Browser und ein Fenster mit dir. Klappt es nicht zu, bleiben seine Tabs über deine Tableiste verteilt und sind dir im Weg. Klappt es zu, friert Chrome sie nach seinen eigenen Regeln ein. Das Zuklappen ist eine Produktentscheidung der Erweiterung, das Einfrieren ist eine Regel von Chrome, und die Erweiterung kann nur das Erste ändern. Selbst wenn sie nie zuklappen würde, lägen ihre Tabs immer noch hinter deinen, wären immer noch außer Sicht und würden immer noch gedrosselt.

Solange Agenten nur Untermieter in einem Browser sind, der für Menschen entworfen wurde, gibt es hier keinen Ausweg. Und ohne Browser kommen Agenten nicht aus, denn das Web wurde für Menschen gebaut, und dass Menschen und Agenten Seite an Seite im selben Browser und auf denselben Websites arbeiten, ist ganz klar die Richtung, in die es geht.

(12. November 2026, Chrome 157.0.8103.51, Erweiterung 1.0.106, je ein Durchlauf.)

5. Die Seite glaubt, jemand sieht zu, aber gezeichnet wird nichts#

Wäre das alles, wäre es schon ein großes Problem. Ich habe aber noch ein subtileres gefunden. Diesmal war die Seite nicht eingefroren, die Timer liefen exakt, und die Seite hielt sich sogar für sichtbar, und trotzdem bewegte sich ihr Bild kaum.

Ich habe eine Seite mit zwei Fortschrittsbalken gebaut. Der grüne bewegt sich mit der Zeit, einen Schritt pro Sekunde. Der rote bewegt sich mit den Frames, die der Browser tatsächlich zeichnet, ein Stück pro Frame. Ich ließ Claude zwei Minuten lang in einem Hintergrund-Tab an dieser Seite arbeiten: einmal klicken, um Musik abzuspielen, dann alle 10 Sekunden eine Liste scrollen und die Seite lesen. Am Ende holte ich den Tab nach vorne.

In dem Moment, als er nach vorne kam, war der grüne Balken voll, und der rote hatte kaum angefangen. Laut Timer waren 184 Sekunden vergangen, gezeichnet worden waren aber nur etwa 620 Frames, wo es bei normalen 60 Frames pro Sekunde rund 11.000 hätten sein sollen. In den ersten 100 Sekunden zeichnete sie nur 387 Frames, im Schnitt weniger als 4 pro Sekunde, was für einen Menschen wie eine Diashow aussieht. Die Seite glaubte, sie werde angesehen, aber der Renderer zeichnete sie gar nicht.

Das Bild wird also langsam gezeichnet, na und? Viele Websites zeigen Zahlen gern animiert. Denk an das „98.765 betreute Unternehmen“ auf einer Firmen-Startseite, das beim Öffnen der Seite von 0 hochzählt und zwei, drei Sekunden später bei der Endzahl stehen bleibt. Öffnet ein Agent so eine Seite im Hintergrund, wo nichts gezeichnet wird, kann die Zahl auf halbem Weg hängen bleiben.

Ich habe eine Seite gebaut, die in 3 Sekunden von 0 auf 98.765 zählt, Claude sie in einem neuen Hintergrund-Tab öffnen lassen, etwas anderes erledigen lassen und 10 Sekunden später zurückgeschickt, um die Zahl abzulesen. Die Ergebnisse:

Dieser Clip zeigt, was die beiden Hintergrund-Tabs gemacht haben, während der Agent anderswo beschäftigt war:

Chrome lieferte in drei Durchläufen drei verschiedene Zahlen, weil die Seite versteckt im Hintergrund lag, ohne einen einzigen Frame zu zeichnen, und die Zahl deshalb bei 0 blieb. In dem Moment, als der Agent zum Ablesen kam, machte die Erweiterung die Seite „sichtbar“, erst dann begann die Zahl hochzuzählen, und der Agent wartete nicht, bis sie fertig war, also las er ab, was der Zähler bis dahin erreicht hatte. Das ist, als würdest du jemanden mitten im Lauf fotografieren: Egal wann du auf den Auslöser drückst, du erwischst ihn irgendwo auf halber Strecke.

Das Schlimmste daran ist, dass der Agent dir nicht sagt, dass die Zahl falsch sein könnte. Es gibt keine Fehlermeldung, und er kann nicht wissen, dass er eine Animation gesehen hat, die noch nicht fertig war. Aus seiner Sicht hat sich die Seite geöffnet, die Zahl wurde abgelesen, alles bestens. Liest er nur einmal ab, reicht er dir die falsche Zahl als Tatsache weiter. Und das ist nur meine eigene Testseite. Stell dir einen Agenten vor, der in einem Hintergrund-Tab versucht, für dich Konzertkarten oder einen Artikel aus einem Flash-Sale zu ergattern.

(12. November 2026, Chrome 157.0.8103.51, Erweiterung 1.0.106.)

6. Schrödingers Tab#

Das alles erinnerte mich an Schrödingers Katze. In dem berühmten Gedankenexperiment kann niemand sagen, ob die Katze lebt oder tot ist, solange die Kiste nicht geöffnet wird. Mit dem Tab eines Agenten in Chrome ist es ganz ähnlich. Solange du hinsiehst, arbeitet er ordentlich. Siehst du nicht hin, bewegt er sich vielleicht einmal pro Minute, oder er ist schon eingefroren. Wenn der Agent in dem Tab etwas tut, ist das, als würde er die Kiste für einen Blick öffnen, und der Tab wacht eine Weile auf. Geht der Agent weg, schließt sich die Kiste wieder, und diesmal kannst du die Kiste sogar sehen: Es ist die Tabgruppe, die sich von selbst zuklappt.

Wenn ein Agent mehrere Aufgaben gleichzeitig erledigt, kann er immer nur einen Tab bedienen, und die übrigen sind in Kisten eingesperrt. Manche sind nur verlangsamt, manche schon eingefroren, und manche sehen normal aus, werden aber nicht einmal gezeichnet, und der Agent selbst hat keine Ahnung, in welchem Zustand welcher Tab gerade ist. Es geht hier also um mehr als darum, ob etwas ein bisschen schneller oder langsamer läuft. Es entscheidet darüber, ob du dem trauen kannst, was der Agent dir zurückgibt.

Um zu verstehen, was dahintersteckt, bin ich den Quellcode von Chromium 156 (er verhält sich genauso wie die getestete Version 157) zusammen mit dem Code der Erweiterung Claude in Chrome 1.0.106 durchgegangen und habe sieben Regeln gefunden, die übereinanderliegen.

7. Was die sieben Regeln tatsächlich sagen#

Dieser Abschnitt geht die sieben Regeln aus der Geschichte oben eine nach der anderen anhand des Chromium-Quellcodes durch. Er ist für alle, die der Sache auf den Grund gehen oder den Quellcode selbst prüfen wollen. Wenn dich nur interessiert, was passiert, reicht „Hintergrund-Tabs werden gedrosselt, eingefroren und nicht gezeichnet“ völlig aus, und du kannst direkt zu Abschnitt 8 springen, „Kann man die Limits von Chrome nicht einfach abschalten?“, ohne später etwas zu verpassen.

1. Verkettete Timer in einer versteckten Seite dürfen nach einer Schonfrist nur noch einmal pro Minute aufwachen. Im Chrome-Quellcode heißt das intensive wake-up throttling, sinngemäß „intensive Drosselung von Aufweckvorgängen“. Was bedeutet das? Es ist der selbst gestellte Wecker von vorhin: Ein Timer feuert, und sein Callback stellt den nächsten Timer. Chrome zählt, wie tief diese Kette reicht, und ab der 7. Ebene dürfen solche Timer, sobald die Seite eine Weile versteckt ist, nur noch einmal pro Minute feuern. Der Countdown ist genau so geschrieben, also wird er erwischt. Ein Timer, der nach der Antwort des Servers gestellt wird, beginnt wieder bei Ebene 1, deshalb sind der Export und die Meldungen der Support-Seite nicht betroffen. Die Schonfrist nach dem Verstecken einer Seite beträgt meist 60 Sekunden, und ein Tab, den der Agent im Hintergrund geöffnet hat und der nie angezeigt wurde, bekommt ebenfalls 60 Sekunden. Zu einem anderen Tab wechseln, das Fenster vollständig verdecken und das Fenster minimieren zählen alle als versteckt. Dazu kommen zwei mildere Limits: Kein Timer wacht öfter als einmal pro Sekunde auf, und nach 10 Sekunden im Versteck dürfen alle Timer-Callbacks zusammen nur 1 % der CPU nutzen, was nur Seiten betrifft, die in ihren Callbacks schwere Arbeit leisten. (third_party/blink/renderer/platform/scheduler/main_thread/page_scheduler_impl.cc; Verschachtelungstiefe in third_party/blink/renderer/core/scheduler/dom_timer.cc)

2. Wenn eine Tabgruppe zugeklappt wird, werden die Tabs darin eingefroren. Sobald eine Gruppe zuklappt, gibt Chrome für jeden Tab darin eine Stimme fürs „Einfrieren“ ab. Tabs, die in den letzten 5 Minuten angezeigt wurden, sind geschützt, Tabs, die nie angezeigt wurden, werden auf der Stelle eingefroren. Eingefroren heißt, dass jedes bisschen Code der Seite anhält. Sie ist nicht langsamer, sie bewegt sich überhaupt nicht, als hätte man der Schublade den Strom abgedreht. (chrome/browser/ui/views/tabs/browser_tab_strip_controller.cc gibt die Stimme ab; components/performance_manager/freezing/freezing_policy.cc entscheidet)

3. Nach etwa 20 Sekunden Untätigkeit klappt Claude in Chrome seine eigene Tabgruppe zu. Das passiert nur, wenn der Tab vorne im Fenster keiner von seinen eigenen ist, und wenn es das nächste Mal etwas zu tun hat, klappt die Erweiterung die Gruppe zuerst wieder auf. Regel 3 plus Regel 2 ergibt das „nach 20 Sekunden tot“, das wir oben gesehen haben: Die Erweiterung klappt die Gruppe zu, und Chrome friert die Tabs darin ein.

4. Die Erweiterung lässt den Tab, an dem sie arbeitet, glauben, „jemand sieht ihn an“. Vor jeder Aktion schaltet die Erweiterung über das Debugging-Protokoll einen Schalter namens Fokus-Emulation ein (Emulation.setFocusEmulationEnabled). Was bewirkt der? Er sagt Chrome „dieser Tab wird gerade angesehen“, also wird der visibilityState der Seite zu visible, und ihre Timer werden nicht mehr so gedrosselt wie die versteckter Seiten, selbst wenn das ganze Fenster minimiert ist. Etwa 20 Sekunden nach der Aktion schaltet die Erweiterung den Schalter wieder aus.

Regel 3 und 4 zusammen erklären auch etwas Merkwürdiges, nämlich warum der Tab, in dem der Agent zuletzt gearbeitet hat, manchmal nicht eingefroren wird, wenn die Gruppe zuklappt. Ich nahm an, die Erweiterung schütze ihn absichtlich, aber der Code zeigte, dass es reiner Zufall ist. Wenn die Gruppe zuklappt, schickt Chrome jedem Tab darin einen Einfrier-Befehl. Der Tab, den der Agent zuletzt angefasst hat, hat in dem Moment noch die Fokus-Emulation an, glaubt, dass er angesehen wird, und verweigert den Befehl. Chrome bemerkt die Weigerung aber nicht, trägt den Tab trotzdem als „eingefroren“ ein und schickt den Befehl nie ein zweites Mal. Wenn die Fokus-Emulation ausgeht und der Tab wirklich außer Sicht ist, kommt nie wieder jemand, um ihn einzufrieren.

Anders gesagt: Im Internat macht der Aufseher abends seine Runde und sagt „Licht aus“, du rufst „hier ist noch jemand“, der Aufseher schreibt „Licht aus“ in sein Heft und geht weiter, kommt nie wieder, und nachdem du eingeschlafen bist, brennt das Licht die ganze Nacht. Dieser Tab bleibt nur wach, weil „die Gruppe klappt zu“ und „die Fokus-Emulation geht aus“ zufällig in dieser Reihenfolge passieren, und weder die Erweiterung noch Chrome hat das so entworfen. Als der Agent vorhin von A zu B wechselte, erwischte A die umgekehrte Reihenfolge: Seine Fokus-Emulation ging zuerst aus, sodass A beim Zuklappen der Gruppe schon außer Sicht war, und das Einfrieren griff, sobald der Befehl ankam.

5. Eine Seite, die nicht wirklich auf den Bildschirm gezeichnet wird, bekommt nur noch einen Frame pro Sekunde. Die Fokus-Emulation kann die Seite glauben machen, dass jemand zusieht, aber den Teil, der das Bild zeichnet, kann sie nicht täuschen. Chrome hat einen Compositing-Dienst namens viz, der jedem Tab im Takt des Bildschirms ein Signal „fang mit dem nächsten Frame an“ schickt (BeginFrame). Wurden 3 Frames eines Tabs hintereinander von keinem Fenster tatsächlich auf den Bildschirm gebracht, fällt dieses Signal auf einmal pro Sekunde, und der Kommentar im Quellcode sagt es ganz unverblümt: „we throttle BeginFrames to 1 per second“ (components/viz/service/frame_sinks/compositor_frame_sink_support.h, kUndrawnFrameLimit = 3). Tabs, die hinter anderen liegen oder in einem minimierten Fenster stecken, können requestAnimationFrame (die Funktion, mit der Webseiten Animationen zeichnen) also nur ein- oder zweimal pro Sekunde ausführen, selbst wenn ihre Timer normal laufen. Das ist wie eine Kamera, die auf eine Bühne gerichtet ist: Die Schauspieler spielen weiter, aber die Kamera merkt, dass niemand den Stream ansieht, und schaltet auf ein Bild pro Sekunde um. Von den knapp 4 Frames pro Sekunde, die ich gemessen habe, entstehen die zusätzlichen zwei, drei wahrscheinlich nebenbei, wenn die Erweiterung Screenshots macht.

6. Ein verdecktes oder minimiertes Fenster zählt ebenfalls als außer Sicht. Unter Windows berechnet Chrome selbst, ob ein Fenster vollständig von anderen Fenstern verdeckt ist, und wenn ja, behandelt es seine Tabs als versteckt (ui/aura/native_window_occlusion_tracker_win.cc, standardmäßig aktiv). Wird ein Fenster minimiert, schrumpft sein gesamter Compositing-Bereich auf 0×0 (desktop_window_tree_host_win.cc).

7. Auch Renderer-Prozesse im Hintergrund werden herabgestuft. Hat ein Renderer-Prozess überhaupt keinen sichtbaren Tab, setzt Chrome ihn auf die niedrigste Priorität und fordert bei Windows EcoQoS an, also den Betrieb mit der sparsamsten Taktfrequenz der CPU und auf den Effizienzkernen, auf Kosten der Geschwindigkeit (base/process/process_win.cc, kUseEcoQoSForBackgroundProcess standardmäßig aktiv). Diese Regel schaut darauf, ob das Fenster wirklich sichtbar ist, deshalb kann die Fokus-Emulation sie nicht täuschen.

Jede dieser sieben Regeln ist für sich vernünftig, aber übereinandergelegt bringen sie den Tab eines Agenten in eine verzwickte Lage. Die Seite hält sich für sichtbar, und doch werden ihre Timer womöglich gedrosselt. Der Agent hat gerade noch darin gearbeitet, und doch ist sie kurz darauf womöglich eingefroren. Sie ist nicht eingefroren, und doch bewegt sich ihr Bild kaum. Welche Tabs wach sind und welche schlafen, könnten womöglich nicht einmal die Leute sagen, die die Erweiterung geschrieben haben. Am Ende läuft es auf dasselbe hinaus: Die Regeln des Browsers wurden für Menschen geschrieben.

8. Kann man die Limits von Chrome nicht einfach abschalten?#

Du denkst vielleicht, wenn Chromes Regeln schuld sind, schaltet man sie eben mit Startparametern ab. Teilweise geht das. --disable-background-timer-throttling, --intensive-wake-up-throttling-policy=0, --disable-renderer-backgrounding und --disable-backgrounding-occluded-windows schalten die Timer-Drosselung und die Herabstufung der Prozesse ab. Die Frame-Regel lässt sich aber nicht abschalten. Ein Tab, der nicht auf den Bildschirm gezeichnet wird, bekommt seine normalen Frames nicht zurück, nur weil du die Timer-Drosselung deaktiviert hast, und so liest der Agent weiterhin halb hochgezählte Zahlen ab.

9. Dieselben Tests in Embiody#

Wir bauen Embiody, einen Windows-Browser für KI-Agenten. Agenten arbeiten darin über BrowserDo, einen eigens dafür gebauten MCP-Server. Claude Code und Codex lassen sich mit einem einzigen Befehl anbinden, Cursor und Claude Desktop mit ein paar Zeilen Konfiguration. Angefangen hat die Funktion KI-Tabs mit jenem Nachmittag im Juli: Ich wollte, dass Agenten mehrere Dinge gleichzeitig erledigen, während ich mit meiner eigenen Arbeit weitermache.

Also habe ich alle Tests oben unter denselben Bedingungen in Embiody laufen lassen und nur den Browser gegen Embiody und das Werkzeug gegen BrowserDo getauscht. Die Ergebnisse:

In Embiody wird Aufgabe B pünktlich fertig, selbst wenn sie unberührt hinter anderen Tabs in einem minimierten Fenster liegt. Die Seite, an der der Agent im Hintergrund arbeitet, wird weiter gezeichnet, die Statistikzahl stimmt beim ersten Ablesen, und der Support-Chat bleibt verbunden. Das gilt allerdings nur für Tabs, die der Agent benutzt. Tabs, die du selbst öffnest, werden im Hintergrund weiterhin nach den üblichen Energiesparregeln gedrosselt, ein Agent im Browser lässt deine eigenen Tabs also nicht mehr Strom verbrauchen. Die Katze in der Kiste bleibt wach. Fairerweise muss ich sagen: Das war ein einzelner Windows-Rechner mit 1 bis 2 Durchläufen pro Test für Embiody, weit entfernt von einem großen Test, aber zumindest in diesen Szenarien ist der Unterschied eindeutig.

Noch etwas, damit es klar ist: Diese Probleme betreffen nicht nur Claude in Chrome. Welche Erweiterung oder welches Automatisierungswerkzeug du auch benutzt, ein Agent, der in Chrome arbeitet, muss sich an Chromes Regeln halten. Im Countdown-Test am Anfang lag der Tab, den ich von Hand geöffnet hatte, nach 8 Minuten genauso mehr als 390 Sekunden zurück wie der von Claude. Zwei weitere Regeln sind mir diesmal nicht begegnet. Wenn der Arbeitsspeicher knapp wird, entlädt Chrome den Hintergrund-Tab, der am längsten nicht angesehen wurde, und er lädt neu, wenn du zurückkommst. Und wenn ein Laptop nicht am Netz hängt und der Akku unter 20 % liegt, werden Hintergrund-Tabs, die einiges an CPU verbrauchen, eingefroren. Ein Mensch, der kurz weggeht und darauf stößt, lädt einfach neu, wenn er zurück ist. Ein Agent, der den ganzen Nachmittag läuft und mehrere Seiten gleichzeitig betreut, wird früher oder später darauf stoßen.

10. KI braucht einen eigenen Browser#

Nach ein paar Jahren, in denen ich meine Arbeit mit KI erledige, bin ich mir einer Sache immer sicherer: KI braucht einen eigenen Browser, und sich mit Chrome zu behelfen, ist eine Notlösung.

Ich sage nicht, dass Chrome schlechte Arbeit macht. Diese Regeln wurden über viele Jahre verfeinert, damit es der Mensch vor dem Bildschirm besser hat: Tabs, die du nicht sehen kannst, sollen weniger verbrauchen, Animationen, die niemand sieht, müssen nicht gezeichnet werden, und Seiten, die lange ungenutzt bleiben, sollen eingefroren oder sogar entladen werden. Eine Erweiterung kann nur eine weitere Schicht über diese Regeln legen, etwa per Fokus-Emulation eine Seite glauben lassen, dass jemand zusieht, oder ihre Tabgruppe zuklappen, damit dir die Tabs des Agenten nicht im Weg sind. Aber die Regeln gehören Chrome, und die Architektur von Chrome wurde für Menschen entworfen. Ohne sie im Kern zu ändern, kann eine Erweiterung nur flicken.

Der Tab von vorhin, bei dem der Aufseher „Licht aus“ ins Heft geschrieben hat, ist das, was beim Flicken herauskommt. Er bleibt nur wach, weil zwei Dinge zufällig in einer bestimmten Reihenfolge passiert sind. Jede neue Chrome-Version könnte diese Reihenfolge ändern, und solchen Zufällen kann man weder ausweichen noch kann man sie vorhersagen, denn Chrome wurde nie für Agenten entworfen.

Wer sich nicht mehr auf Zufälle verlassen will, muss die Regeln des Browsers selbst auf Agenten ausrichten. Für einen Menschen entscheidet die Sichtbarkeit eines Tabs darüber, ob er weiter Ressourcen verbrauchen soll. Für einen Agenten kann ein Tab, den niemand ansieht, gerade mitten in etwas stecken, das er für dich erledigt und das sich nicht pausieren lässt, und er sollte weiterarbeiten, egal ob jemand vor dem Bildschirm sitzt oder nicht. Das lässt sich nur in der Browser-Engine selbst festlegen, und nach diesem Prinzip sind die KI-Tabs von Embiody gebaut.

(Embiody: 1 bis 2 Durchläufe pro Test, 11. bis 12. November 2026, derselbe Rechner.)

Was ich nicht getestet habe#

• Ein Windows-Rechner und eine Chrome-Version. Als ich im Juli von Hand getestet habe, wurde die Verlangsamung nach meiner Erinnerung erst nach 5 Minuten deutlich; diesmal (Chrome 157) war es etwa 1 Minute. Ich weiß nicht, ob Chrome sich geändert hat oder ob ich mich falsch erinnere.
• Kein Mac und kein Linux, und nichts mit eingeschaltetem Arbeitsspeicher-Sparmodus (Memory Saver).
• Das Entladen von Tabs bei knappem Arbeitsspeicher und das Einfrieren von Tabs bei niedrigem Akkustand kenne ich nur aus dem Quellcode, gemessen habe ich beides nicht.

In zwei Minuten selbst ausprobieren#

Öffne https://embiody.com/lab/background-tab/. Die Seite startet einen 15-Minuten-Countdown. Wechsle zu einem anderen Tab (das Fenster zu verdecken oder zu minimieren geht auch), komm nach zwei Minuten zurück und schau auf „Behind by“ (Rückstand): So viele Sekunden hat der Countdown verloren, während du weg warst. 0 s hieße, dass die Seite pünktlich weitergelaufen ist. Die Testseite ist auf Englisch.

Zum Schluss#

Ich weiß nicht, ob Chrome diese Regeln jemals für Agenten ändern wird. Seine Gründe sind gute Gründe: Strom sparen, Speicher sparen und den Vordergrund flüssig halten ist genau das, was ein Browser tun soll. Nur ist der Browser davon ausgegangen, dass ein Mensch vor dem Bildschirm sitzt und sich einen Tab nach dem anderen ansieht, und jetzt sitzt dort vielleicht gar niemand mehr, während hinter den Tabs ein Agent mehrere Seiten gleichzeitig betreut.

Wenn du nicht hinsiehst, arbeitet er nicht. Aber die Arbeit eines Agenten ist genau die, die passiert, während du nicht hinsiehst.