Wie wir OWL entwickelt haben, die neue Architektur hinter unserem ChatGPT‑basierten Browser, Atlas.

Von Ken Rockot, Mitglied des Technical Staff, und Ben Goodger, Head of Engineering, ChatGPT Atlas

Letzte Woche haben wir ChatGPT Atlas veröffentlicht⁠, eine neue Art, mit ChatGPT im Web zu surfen. Atlas ist ein voll ausgestatteter Webbrowser und bietet zugleich einen Blick in die Zukunft, eine Welt, in der du ChatGPT mit ins Internet nehmen kannst, um Fragen zu stellen, Vorschläge zu machen und Aufgaben für dich zu erledigen. In diesem Beitrag beleuchten wir einen der komplexesten technischen Aspekte des Produkts: wie wir ChatGPT in einen Browser verwandelt haben, der mit der Nutzung immer hilfreicher wird.

Wir haben Atlas von der Chromium-Runtime getrennt, um die gesamte Browserarchitektur neu zu denken und ChatGPT zu einem echten Copiloten für das Web zu machen. Dafür haben wir eine neue Art der Integration von Chromium entwickelt. Damit können wir unsere Produktziele erreichen: sofortiger Start, hohe Reaktionsgeschwindigkeit selbst bei vielen geöffneten Tabs und eine starke Grundlage für agentische Anwendungsfälle.

Chromium war ein naheliegender Baustein. Es bietet eine moderne Web-Engine mit robustem Sicherheitsmodell, bewährter Leistungsfähigkeit und hervorragender Webkompatibilität. Außerdem wird es von einer globalen Community kontinuierlich weiterentwickelt. Es ist die gängige Grundlage für moderne Desktop-Webbrowser.

Unser talentiertes Designteam hatte ehrgeizige Ziele für das Nutzungserlebnis, mit aufwendigen Animationen und visuellen Effekten für Funktionen wie den Agent-Modus. Dafür musste unser Entwicklungsteam die modernsten nativen Frameworks für unsere Benutzeroberfläche nutzen (SwiftUI, AppKit und Metal), statt einfach nur das Open-Source-Chromium-UX anzupassen. So wurde die Benutzeroberfläche von Atlas zu einem umfassenden Neubau der gesamten Anwendungserfahrung.

Wir hatten auch andere Produktziele, etwa schnelle Startzeiten und die Unterstützung von Hunderten Tabs, ohne die Leistung zu beeinträchtigen. Diese Ziele waren mit Chromium im Auslieferungszustand schwer zu erreichen, da es bei vielen Details, vom Startvorgang über das Threading- bis hin zum Tab-Modell, stark vordefiniert ist. Wir dachten über größere Änderungen nach, wollten aber unsere Anpassungen an Chromium gezielt halten, um neue Versionen schnell integrieren zu können. Damit unsere Entwicklungs­geschwindigkeit maximal hoch bleibt, mussten wir eine neue Methode finden, um die Chromium-Runtime zu integrieren und zu steuern.

Unsere technische Investition musste sich in der Praxis beweisen. Sie sollte nicht nur schnellere Experimente, Iterationen und die Einführung neuer Funktionen ermöglichen, sondern auch den Kern der OpenAI-Engineering-Kultur bewahren: am ersten Tag produktiv zu sein. Jeder neue Ingenieur nimmt an seinem ersten Arbeitstag eine kleine Änderung vor und führt sie noch am selben Nachmittag in den Code ein. Wir mussten sicherstellen, dass das möglich ist, auch wenn Chromium Stunden für das Herunterladen und den Aufbau benötigen kann.

Unsere Antwort auf diese Herausforderungen war der Aufbau einer neuen Architekturschicht namens OWL: OpenAIs Web Layer. OWL ist unsere Integration von Chromium. Dabei läuft der Browserprozess von Chromium außerhalb des Hauptprozesses der Atlas-App.

Das kannst du dir so vorstellen: Chromium hat Browser revolutioniert, indem es Tabs in separate Prozesse ausgelagert hat. Wir haben diese Idee weitergeführt, indem wir Chromium selbst aus dem Hauptanwendungsprozess herausgelöst und in eine isolierte Service-Schicht verschoben haben. Dieser Schritt eröffnet eine Reihe von Vorteilen:

• Eine einfachere, modernere App: Atlas ist fast vollständig in SwiftUI und AppKit aufgebaut. Eine Sprache, ein Technologie-Stack, eine saubere Codebasis.
• Schnellere Startzeiten: Chromium wird asynchron im Hintergrund gestartet. Atlas wartet nicht – die Pixel erscheinen nahezu sofort auf dem Bildschirm.
• Isolation von Rucklern und Abstürzen: Chromium ist eine leistungsstarke, aber komplexe Web-Engine. Wenn sein Haupt-Thread hängt, betrifft das Atlas nicht. Und wenn Chromium abstürzt, läuft Atlas weiter.
• Weniger Merge-Konflikte: Da wir weniger auf der Open-Source-Oberfläche von Chromium aufbauen, ist unser Unterschied zum ursprünglichen Chromium deutlich kleiner und leichter zu pflegen.
• Schnellere Iterationen: Die meisten Entwickler müssen Chromium nicht mehr lokal kompilieren. OWL wird intern als vorkompilierte Version bereitgestellt, dadurch dauern Atlas-Builds Minuten statt Stunden.

Da die meisten Entwickler in unserem Team Chromium nicht regelmäßig aus dem Quellcode erstellen, kann die Entwicklung viel schneller voranschreiten. Sogar neue Teammitglieder können schon an ihrem ersten Nachmittag einfache Änderungen einpflegen.

Auf hoher Ebene ist der Atlas-Browser der OWL-Client, und der Chromium-Browserprozess OWL-Host. Sie kommunizieren über IPC, genauer gesagt über Mojo⁠(wird in einem neuen Fenster geöffnet), Chromiums eigenes Nachrichtenübertragungssystem. Wir haben eigene Swift- (und sogar TypeScript-) Bindings für Mojo geschrieben, damit unsere Swift-App direkt mit den Host-seitigen Schnittstellen kommunizieren kann.

Die OWL-Client-Bibliothek stellt eine einfache öffentliche Swift-API bereit, die mehrere zentrale Konzepte abstrahiert, die von der Service-Schicht des Hosts bereitgestellt werden.

• Sitzung: Den Host global konfigurieren und steuern
• Profil: Browserzustand für ein bestimmtes Benutzerprofil verwalten
• WebView: Einzelne Webinhalte steuern und einbetten (z. B. Rendering, Eingabe, Navigation, Zoom usw.)
• WebContentRenderer: Eingabeereignisse an Chromiums Rendering-Pipeline weiterleiten und Feedback vom Renderer empfangen
• LayerHost/Client: Austausch von Compositing-Informationen zwischen der Benutzeroberfläche und Chromium

Außerdem gibt es eine breite Palette von Service-Endpunkten zur Verwaltung erweiterter Funktionen wie Lesezeichen, Downloads, Erweiterungen und automatischer Formularausfüllung.

WebViews, die sich in der Client-App einen exklusiven Darstellungsbereich teilen, werden in einen gemeinsamen Compositing-Container ein- und ausgeblendet. Ein Browserfenster hat zum Beispiel oft einen einzigen gemeinsamen Container. Wird ein Tab in der Tab-Leiste ausgewählt, wird das WebView dieses Tabs in den Container geladen. Auf der Chromium-Seite entspricht dieser Container einem gfx::AcceleratedWidget, das letztlich durch ein CALayer gestützt wird. Wir geben die Kontext-ID dieses Layers an den Client weiter, wobei ein NSView sie über die private CALayerHost-API einbettet.

Sonderfälle wie -Dropdowns oder Farbwähler, die Chromium in separaten Popup-Widgets rendert, verwenden denselben Ansatz. Diese haben kein content::WebContents, aber sie verfügen über ein content::RenderWidgetHostView mit ihrem eigenen gfx::AcceleratedWidget, sodass dasselbe delegierte Rendering-Modell gilt.OWL hält die Ansicht-Geometrie intern mit der Chromium-Seite synchron, sodass der GPU-Compositor entsprechend aktualisiert werden kann und stets Layer-Inhalte in der richtigen Größe und Geräteskalierung erzeugt.Wir verwenden diese Technik auch, um gezielt Elemente der nativen Chromium-Views-Oberfläche in Atlas zu projizieren. Das ist beispielsweise hilfreich, um Funktionen wie Berechtigungsabfragen schnell zu übernehmen, ohne sie in SwiftUI komplett neu zu entwickeln. Diese Technik baut stark auf Chromiums bestehender Infrastruktur für installierbare Web-Apps unter macOS auf.Eingabeereignisse: Aufschlüsseln und WeiterleitenDie Chromium-Oberfläche übersetzt Plattformereignisse (z. B. macOS-NSEvents) in Blinks WebInputEvent-Modell, bevor sie an Renderer weitergeleitet werden. Da OWL Chromium jedoch in einem versteckten Prozess ausführt, übernehmen wir diese Übersetzung selbst innerhalb der Swift-Client-Bibliothek und leiten die bereits übersetzten Ereignisse an Chromium weiter.Von dort folgen sie demselben Lebenszyklus, den reale Eingabeereignisse normalerweise für Webinhalte durchlaufen würden. Dazu gehört, dass Ereignisse an den Client zurückgegeben werden, wenn eine Seite signalisiert, dass sie das Ereignis nicht verarbeitet hat. In diesem Fall erzeugen wir ein neues NSEvent und geben dem Rest der App die Möglichkeit, die Eingabe zu verarbeiten.Agent-Modus: SonderfälleDie agentische Browserfunktion von Atlas bringt besondere Herausforderungen für Rendering, Eingabeereignis-Weiterleitung und Datenspeicherung mit sich.Unser Nutzungsmodell für den Computer erwartet ein einziges Abbild des Bildschirms als Eingabe. Einige UI-Elemente, etwa -Dropdown, werden jedoch außerhalb der Tab-Grenzen in separaten Fenstern gerendert. Im Agent-Modus fügen wir diese Pop-ups wieder in das Seitenbild an der richtigen Position ein, sodass das Modell den vollständigen Kontext in einem Frame erfassen kann.

Für Eingaben gilt dasselbe Prinzip: Von Agenten erzeugte Ereignisse werden direkt an den Renderer weitergeleitet, nie über die privilegierte Browser-Ebene. So bleibt die Sandbox-Grenze auch bei automatisierter Steuerung erhalten. Zum Beispiel sollen diese Ereignisse keine Tastenkombinationen erzeugen, die den Browser Aktionen ausführen lassen, die nichts mit den angezeigten Webinhalten zu tun haben.

Das agentische Browsen kann auch in einem flüchtigen, „abgemeldeten“ Kontext ausgeführt werden. Anstatt das bestehende Inkognito-Profil des Benutzers zu teilen – was Zustände preisgeben könnte – nutzen wir Chromiums StoragePartition-Infrastruktur, um isolierte, im Speicher laufende Umgebungen zu erstellen. Jede Agent-Sitzung beginnt neu, und sobald sie endet, werden alle Cookies und Website-Daten verworfen. Du kannst mehrere „abgemeldete“ Agent-Sitzungen gleichzeitig ausführen – jede in einem eigenen Browser-Tab und vollständig von den anderen isoliert.

All das verdanken wir der globalen Chromium-Community. Sie hat mit ihrer beeindruckenden Arbeit das Fundament für das moderne Web geschaffen. OWL baut auf diesem Fundament auf, auf neue Weise: durch die Entkopplung der Engine von der App, die Verbindung einer erstklassigen Webplattform mit modernen nativen Frameworks und die Erschließung einer schnelleren, flexibleren Architektur.

Indem wir neu denken, wie ein Browser Chromium integriert, schaffen wir Raum für neue Arten von Erlebnissen: schnellere Starts, reichhaltigere Oberflächen, engere Integration mit dem Betriebssystem und einen Entwicklungszyklus, der sich mit der Geschwindigkeit von Ideen bewegt. Klingt das nach einer spannenden Herausforderung für dich? Dann sieh dir unsere offenen Stellen an – zum Beispiel als Software Engineer, Atlas⁠, Software Engineer, iOS⁠, und viele weitere⁠.

Probiere Atlas unter chatgpt.com/atlas⁠⁠(wird in einem neuen Fenster geöffnet) aus.