Du drückst Senden und wechselst in den Browser, um etwas nachzuschlagen. Das Hermes-Fenster bleibt im Hintergrund und streamt seine Antwort Zeichen für Zeichen. Zwanzig Minuten später klappst du den Deckel zu, ziehst das Kabel und gehst. Als du zurückkommst, ist der Akku weiter gesunken als er sollte, und der Lüfter war offensichtlich beschäftigt, während du weg warst.

Ein verstecktes Fenster sollte nicht so arbeiten. Niemand schaut hin, trotzdem wurde jedes Zeichen in Vordergrundgeschwindigkeit neu gezeichnet.

Das alte Verhalten: ein streamendes Gespräch, alle Fenster wach

In der vorherigen Implementierung hielt der Zustand „ein Gespräch streamt“ jedes Desktop-Fenster voll wach: Die Paint-Loop lief weiter, und auch Vorschauseiten wurden wachgehalten, damit Automatisierung und Annotation-Capture immer bereit wären.

Mit einem Fenster war das unsichtbar. Mit mehreren Fenstern, lang laufenden Turns und einem Laptop-Akku war es ein ständiger Hintergrundposten.

Die Vorschau-Hälfte war subtiler: Selbst eine völlig untätige Seite erreichte nie Chromiums Background-Throttling, weil Annotation oder Automatisierung sie jeden Moment brauchen könnten.

Jetzt folgt das Zeichnen der Sichtbarkeit

Streaming-Paint ist auf zwei Fenster begrenzt: die sichtbaren und das eine Fenster, das seine eigene laufende Sprachunterhaltung hat (das bleibt auch versteckt wach, weil die Stimme es braucht). Alles andere — minimierte Peers eingeschlossen — darf throtteln.

Beachte, was das nicht ist: „Antworten laut vorlesen“ kauft nicht mehr jedem Fenster eine Aufwach-Ausnahme. Früher implizierte es, dass jedes Fenster wach bleiben musste, um seinen Inhalt zu sprechen; jetzt bleiben minimierte Peers gedrosselt, und abgeschlossener Fortschritt plus die finale Antwort werden trotzdem genau einmal gesprochen.

Gleichzeitig wurden die Dinge, die nicht vom Zeichnen abhängen dürfen, von Animation Frames entkoppelt: Stream-Zustellung, Stop, Turn-Journaling und Crash-Recovery funktionieren alle ohne sie. Ein Fenster wiederherzustellen zeigt den neuesten Zustand, statt einen Rückstau von Paints nachzuspielen.

Teiltext-Updates werden zusammengeführt. Abgeschlossener Fortschritt und finale Antworten werden veröffentlicht, ohne auf den nächsten Frame zu warten — deshalb kann ein verstecktes Fenster noch einmal laut lesen. Haben zwei Fenster gleichzeitig Antworten, teilen sie sich den Besitz des ausstehenden Turns, sodass Narration weder verloren geht noch doppelt gesprochen wird.

Vorschauseiten: untätig heißt untätig

Die zweite Änderung betrifft die eingebaute Vorschau: Eine untätige Seite darf jetzt Chromiums eigenes Background-Throttling nutzen, statt für sich selbst ein Wake zu halten.

Die Gastseite und ihr besitzendes Fenster werden nur für echte Arbeit geweckt, und das Wake wird pro Operation gehalten. Überlappende Operationen behalten jeweils ihr eigenes Hold, sodass das Beenden einer nicht eine andere suspendieren kann. Nach einer Navigation wird das Wake erneut angewendet, selbst wenn eine bestehende Operation noch kein weiteres Skript dispatcht hat.

Mehrere scharfe Kanten wurden gleichzeitig geschlossen:

• Von einer committeten Navigation verlassene Arbeit wird abgebrochen, während Skript-Rückgabewerte, Plugin-Consent, vertrauenswürdige Eingabe, Sandboxing und CSP alle intakt bleiben.
• Das Warten auf Annotation-Paint und Image-Capture teilt eine abbrechbare Acht-Sekunden-Deadline. Das Warten auf die nächste Annotation des Nutzers hält nichts wach.
• Eingereihte Annotation-Installs und Teardown sind pro Session eingefasst, sodass ein Abbruch weder einen unsichtbaren Klick-Blocker hinterlassen noch ein Ersatz-Overlay entfernen kann.
• Plugin-Skripte behalten ihre bestehenden Completion-Semantiken: Ihr Wake-Hold dauert bis zur Abwicklung oder zum Abbruch, selbst bei einem Promise, das nie settled. Plugin-Skripte und lange Tipp-Aktionen erben die Capture-Deadline nicht.

Keine neuen Abhängigkeiten, Berechtigungen oder CSP-Änderungen, und im Transkript oder Scrollback wurde nichts abgeschnitten.

So siehst du es selbst

Der Abnahmepfad ist bewusst manuell:

1. Öffne dasselbe Gespräch in zwei Fenstern, minimiere eines, streame eine lange Antwort. Tippe im sichtbaren Fenster und stelle dann das andere wieder her — beide sollten die vollständige Antwort zeigen.
2. Drücke Stop im sichtbaren Fenster. Die abgebrochene Ausgabe darf nicht weiterlaufen, wenn du den Peer wiederherstellst.
3. Schalte „Antworten laut vorlesen“ in beiden Fenstern an: Minimierte Peers bleiben gedrosselt, abgeschlossener Fortschritt und die finale Antwort werden trotzdem einmal gesprochen.
4. Starte eine Sprachunterhaltung nur in einem Fenster: Das Streaming im Peer darf dessen Capture oder Wiedergabe nicht unterbrechen.
5. Lade während des Streamings neu: Die Recovery behält den neuesten Text, einschließlich des leisen Endes, nachdem der Anbieter aufhört zu senden.

Wann du es wirklich merkst

Drei Situationen: ein Laptop, der eine lang laufende Aufgabe beobachtet, alle, die dasselbe Gespräch in zwei oder drei Fenstern offen halten, um zu vergleichen, und Leute, die Doku in der eingebauten Vorschau lesen und sie dabei annotieren.

Es macht dein Modell nicht schneller und deine Antworten nicht kürzer. Es lässt nur Fenster still werden, in die niemand schaut.

Kannst du es heute nutzen?

Beide Änderungen wurden am 4. November in main gemergt, nach dem Release-Punkt von v0.22.7 — zum Zeitpunkt dieses Textes sind sie also nicht in einem Release; der v0.22.7-Beitrag deckt ab, was tatsächlich erschienen ist. Die Tipp-Latenz im Desktop hat ihre eigene Analyse, und wenn dich eigentlich interessiert, benachrichtigt zu werden, wenn etwas dich braucht, ist der Leitfaden zu Aufmerksamkeit und Benachrichtigungen die Empfangsseite.