OpenAI recently introduced ChatGPT Atlas, a web browser where a Large Language Model (LLM) functions as a co-pilot across the internet. Users can pose inquiries about any web page, delegate tasks to ChatGPT, or allow it to browse autonomously in Agent mode while other work is performed.
Achieving this sophisticated user experience presented significant engineering challenges. ChatGPT Atlas required instantaneous startup and consistent responsiveness, even when managing hundreds of open tabs. To accelerate development and leverage existing robust solutions, the engineering team constructed Atlas upon Chromium, the foundational engine for numerous contemporary browsers.
Nevertheless, Atlas distinguishes itself beyond being merely another Chromium-based browser with a modified interface. Most browsers leveraging Chromium embed the web engine directly within their application, resulting in a tightly coupled relationship between the user interface and the rendering engine. While this architectural approach is suitable for conventional web browsing, it presents substantial hurdles for implementing certain advanced capabilities.
Consequently, OpenAI’s innovative solution involved developing OWL (OpenAI’s Web Layer), an architectural abstraction that operates Chromium as a distinct, separate process. This design paradigm facilitates capabilities that would have been exceptionally difficult to realize otherwise.
This article explores the methodology employed by the OpenAI Engineering Team in constructing OWL and examines the technical complexities encountered concerning rendering and inter-process communication.
Chromium emerged as the unequivocal choice for Atlas’s web engine. This powerful engine offers a state-of-the-art rendering capability, robust security protocols, demonstrated performance efficiency, and comprehensive web compatibility. It serves as the foundation for numerous contemporary browsers, including Google Chrome, Microsoft Edge, and Brave. Moreover, Chromium benefits from continuous enhancements contributed by a global developer community. For engineering teams developing a browser in the current technological landscape, Chromium represents the logical and highly effective starting point.
Nevertheless, adopting Chromium presented notable challenges. The OpenAI Engineering Team harbored ambitious objectives that proved arduous to achieve within Chromium’s conventional architectural framework:
Firstly, the requirement was for instant startup times. Users expected the browser interface to appear without delay, rather than enduring a loading period for all components. This aligns with critical performance metrics for user experience.
Secondly, the implementation of rich animations and sophisticated visual effects for features such as Agent mode necessitated the utilization of modern native frameworks like SwiftUI and Metal, diverging from Chromium’s intrinsic UI system.
Thirdly, Atlas was designed to seamlessly support hundreds of concurrently open tabs without experiencing performance degradation, a critical factor for effective capacity planning and resource management.
Chromium inherently dictates certain operational paradigms for browsers, governing the boot sequence, the threading model, and the methodologies for tab management.
While substantial modifications to Chromium’s core could have been undertaken by OpenAI, this strategy presented significant drawbacks. Extensive alterations to Chromium’s fundamental components would entail the ongoing maintenance of a vast collection of custom patches. With each new Chromium version release, the process of merging these bespoke changes would become progressively more intricate and time-intensive.
A cultural imperative also played a role. OpenAI adheres to an engineering principle termed “shipping on day one,” where every new engineer successfully commits and merges a code change during their inaugural afternoon. This practice fosters high development velocity and instills immediate productivity in new team members. However, Chromium typically requires several hours to download and compile from source. Reconciling this stringent internal requirement with traditional Chromium integration methods appeared almost insurmountable.
OpenAI therefore necessitated an alternative methodology for Chromium integration, one that would facilitate rapid experimentation, accelerate feature delivery, and preserve its established engineering culture.
The definitive solution manifested as OWL, an innovative architectural layer that fundamentally redefines the integration paradigm between Chromium and the browser application.
A foundational principle of this architecture dictates that, rather than embedding Chromium within the Atlas application, OpenAI executes Chromium’s browser process as an external entity, distinct from the main Atlas application process.
Within this architecture, Atlas functions as the OWL Client, while the Chromium browser process assumes the role of the OWL Host. These two integral components facilitate communication via Inter-Process Communication (IPC) utilizing Mojo, Chromium’s native message-passing system. OpenAI engineered custom Swift and TypeScript bindings for Mojo, enabling its Swift-centric Atlas application to invoke Chromium functions directly.
The following diagram illustrates this interaction:
The OWL client library presents a streamlined Swift API, encapsulating several pivotal concepts:
Furthermore, OWL furnishes service endpoints for the management of high-level functionalities, including bookmarks, downloads, extensions, and autofill.
One of the most intricate facets of the OWL architecture is its rendering mechanism.
A fundamental challenge involved displaying web content generated by Chromium in one process within Atlas windows residing in an entirely distinct process.
OpenAI engineered a solution leveraging a technique known as layer hosting. The operational flow is as follows:
On the Chromium component, web content undergoes rendering onto a CALayer, which is a foundational macOS graphics primitive. This specific layer is assigned a unique context ID.
Conversely, on the Atlas component, an NSView, functioning as a window component, embeds this CALayer by employing the private CALayerHost API. The aforementioned context ID instructs Atlas precisely which layer to render.
The interaction is depicted in the following diagram:
The outcome of this process is the seamless appearance of pixels rendered by Chromium within the OWL process directly in Atlas windows. The GPU compositor manages this operation with high efficiency due to the shared graphics memory accessible to both processes. It is noteworthy that multiple tabs can share a singular compositing container. Upon switching tabs, Atlas merely interchanges the WebView connected to the currently visible container.
This methodology is also applicable to specialized UI elements, such as dropdown menus originating from select elements or color pickers. These elements render within distinct pop-up widgets in Chromium, each possessing its own rendering surface, yet they adhere to the identical delegated rendering model.
Furthermore, OpenAI selectively employs this approach to project specific elements of Chromium’s native user interface into Atlas. This proves advantageous for rapidly prototyping features like permission prompts without the necessity of developing complete custom replacements in SwiftUI. The underlying technique draws upon Chromium’s established infrastructure designed for installable web applications on macOS.
The management of user input necessitates meticulous handling across the process boundary. Traditionally, Chromium’s UI layer is responsible for translating platform-specific events, such as mouse clicks or key presses, originating from macOS NSEvents into Blink’s WebInputEvent format. These translated events are then relayed to the respective web page renderers.
Within the OWL architecture, Chromium operates without an active visible window, consequently precluding its direct reception of these platform events. Instead, the Atlas client library undertakes the conversion of NSEvents into WebInputEvents and then transmits these pre-translated events to Chromium via Inter-Process Communication (IPC).
The accompanying diagram illustrates this process:
Subsequent to this transmission, the events proceed through the identical lifecycle they would ordinarily follow for web content processing. Should a web page indicate that it did not process an event, Chromium remits the event back to the Atlas client. In such instances, Atlas re-synthesizes an NSEvent, thereby affording the remainder of the application an opportunity to handle the input. This mechanism ensures the correct functionality of browser-level keyboard shortcuts and gestures, notwithstanding the web engine’s operation in a segregated process.
Atlas incorporates an agentic browsing capability, empowering ChatGPT to control the browser for task completion. This functionality introduces distinctive challenges concerning rendering, input management, and data persistence.
The computational model underlying Agent mode anticipates a singular screenshot of the browser interface as its input. However, certain UI constituents, such as dropdown menus, render beyond the confines of the primary tab within separate windows. To address this, Atlas composites these pop-up windows back into the main page image, precisely at their accurate coordinates, when operating in Agent mode. This methodology guarantees that the artificial intelligence model receives the comprehensive context within a unified frame.
Regarding input events, OpenAI enforces a rigorous security principle. Events generated by the agent are routed directly to the web page renderer, bypassing the privileged browser layer entirely. This design choice maintains the integrity of the security sandbox, even when operating under automated control. The system specifically precludes AI-generated events from synthesizing keyboard shortcuts that could induce the browser to perform actions unrelated to the currently displayed web content.
Agent mode further supports ephemeral browsing sessions. Rather than utilizing a user’s existing Incognito profile, which carries the risk of state leakage between sessions, OpenAI employs Chromium’s StoragePartition infrastructure to establish isolated, in-memory data stores. Each agent session commences in an entirely pristine state. Upon the termination of a session, all associated cookies and site data are comprehensively discarded. This architectural provision enables the simultaneous execution of multiple logged-out agent sessions, each within its dedicated browser tab, ensuring absolute isolation among them.
The OWL architecture confers several pivotal advantages that are instrumental in realizing OpenAI’s product objectives.
Atlas attains rapid startup performance because Chromium initiates asynchronously in the background, while the Atlas user interface renders almost instantaneously. Users observe on-screen pixels within milliseconds, even if the underlying web engine is still undergoing initialization.
The application development process is streamlined significantly, as Atlas is constructed predominantly using SwiftUI and AppKit. This approach fosters a unified codebase characterized by a singular primary language and technology stack, thereby simplifying the development efforts across the entire application for engineers.
Process isolation represents a key benefit: should Chromium’s main thread become unresponsive, Atlas retains its responsiveness. In the event of a Chromium crash, Atlas continues its operation and possesses recovery capabilities. This deliberate separation safeguards the user experience from potential instabilities originating within the web engine.
OpenAI maintains a considerably reduced divergence, or ‘diff,’ against upstream Chromium because the extensive modification of Chromium’s UI layer is avoided. This operational discipline facilitates a more straightforward integration of new Chromium versions as they become available.
Crucially for developer productivity, the majority of engineers are absolved from the requirement to compile Chromium locally. OWL is distributed internally as a prebuilt binary, enabling the complete compilation of Atlas within minutes, rather than the several hours typically associated with Chromium builds.
Every significant architectural decision inherently involves a set of trade-offs:
Despite these considerations, OpenAI concluded that the identified trade-offs were merited. The significant advantages pertaining to system stability, enhanced developer productivity, and inherent architectural flexibility demonstrably outweigh the associated costs. The clear and deliberate separation between Atlas and Chromium establishes a robust foundation capable of supporting future innovations, particularly those centered around agentic use cases.
The OWL architecture transcends the mere objective of constructing a superior browser for the present day.
Instead, it establishes a foundational infrastructure poised to support the future evolution of AI-powered web experiences. This architectural design inherently simplifies the operation of multiple isolated agent sessions, the integration of nascent AI capabilities, and the exploration of innovative interactions among users, artificial intelligence, and web content. The intrinsic sandboxing mechanisms for agent actions ensure security by design, rather than being an auxiliary consideration.
The development of ChatGPT Atlas necessitated a fundamental re-evaluation of established assumptions concerning browser architecture. Through the strategic execution of Chromium external to the main application process and the meticulous creation of the OWL integration layer, the OpenAI Engineering Team concurrently resolved a multitude of complex challenges. This approach yielded instantaneous startup times, sustained high developer productivity, enabled sophisticated UI capabilities, and forged a robust foundation for advanced agentic browsing functionalities.