How we built OWL, the new architecture behind our ChatGPT-based browser, Atlas

How we built OWL, the new architecture behind our ChatGPT-based browser, Atlas | OpenAI

October 30, 2025

How we built OWL, the new architecture behind our ChatGPT‑based browser, Atlas

Inside our new process architecture, which ​​gives you a faster, smarter way to use the web.

Loading…

Share

By Ken Rockot, Member of the Technical Staff and Ben Goodger, Head of Engineering, ChatGPT Atlas

Last week, we launched ChatGPT Atlas⁠, a new way to browse the web with ChatGPT by your side. In addition to being a full-featured web browser, Atlas offers a glimpse into the future: a world where you can bring ChatGPT with you across the internet to ask questions, make suggestions, and complete tasks for you. In this post, we unpack one of the most complex engineering aspects of the product: how we turned ChatGPT into a browser that gets more useful as you go.

Making ChatGPT a true co-pilot for the web meant reimagining the entire architecture of a browser: separating Atlas from the Chromium runtime. This entailed developing a new way of integrating Chromium that allows us to deliver on our product goals: instant startup, responsiveness even as you open more tabs, and creating a strong foundation for agentic use cases.

Shaping the foundation

Chromium was a natural building block. It provides a state-of-the-art web engine with a robust security model, established performance credentials, and peerless web compatibility. Furthermore, it’s developed by a global community that continuously improves it. It’s a common go-to for modern desktop web browsers.

Rethinking the browser experience

Our talented design team had ambitious goals for our user experience, including rich animations and visual effects for features like Agent mode. This required our engineering team to leverage the most modern native frameworks for our UI (SwiftUI, AppKit and Metal), instead of simply reskinning the open source Chromium UX. As a result, Atlas’ UI is a comprehensive rebuild of the entire application UX.

We also had other product goals like fast startup times and supporting hundreds of tabs without penalizing performance. These goals were challenging to achieve with Chromium out-of-the-box, which is opinionated about many details from the boot sequence, threading model and tab models. We considered making substantial changes here, but we wanted to keep our set of patches against Chromium targeted so we could quickly integrate new versions. To ensure our development velocity was maximally accelerated, we needed to come up with a different way to integrate and drive the Chromium runtime.

A litmus test for our technical investment was not only that it would enable faster experimentation, iteration and delivery of new features – it would also enable us to maintain a core part of OpenAI’s engineering culture: shipping on day one. Every new engineer makes and merges a small change in the afternoon of their first day. We needed to make sure this was possible even though Chromium can take hours to check out and build.

Our Solution: OWL

Our answer to these challenges was to build a new architectural layer we call OWL: OpenAI’s Web Layer. OWL is our integration of Chromium, which entails running Chromium’s browser process outside of the main Atlas app process.

Think of it like this: Chromium revolutionized browsers by moving tabs into separate processes. We’re taking that idea further by moving Chromium itself out of the main application process and into an isolated service layer. This shift unlocks a cascade of benefits:

• A simpler, modern app: Atlas is built almost entirely in SwiftUI and AppKit. One language, one tech stack, one clean codebase.
• Faster startup: Chromium boots asynchronously in the background. Atlas doesn’t wait — pixels hit the screen nearly instantly.
• Isolation from jank and crashes: Chromium is a powerful and complex web engine. If its main thread hangs, Atlas doesn’t. If it crashes, Atlas stays up.
• Fewer merge headaches: Because we’re not building on as much of the Chromium open source UI, our diff against upstream Chromium is much smaller and easier to maintain.
• Faster iteration: Most engineers never need to build Chromium locally. OWL ships internally as a prebuilt binary, so Atlas builds take minutes not hours.

Because most engineers on our team aren’t regularly building Chromium from source, development can go much faster—even new team members can merge simple changes on their first afternoon.

How OWL works

At a high level, the Atlas browser is the OWL Client, and the Chromium browser process is the OWL Host. They communicate over IPC, specifically Mojo⁠, Chromium’s own message-passing system. We wrote custom Swift (and even TypeScript) bindings for Mojo, so our Swift app can call host-side interfaces directly.

The OWL client library exposes a simple public Swift API, which abstracts several key concepts exposed by the host’s service layer:

• Session: Configure and control the host globally
• Profile: Manage browser state for a specific user profile
• WebView: Control and embed individual web contents (e.g. render, input, navigate, zoom, etc.)
• WebContentRenderer: Forward input events into Chromium’s rendering pipeline and receive feedback from the renderer
• LayerHost/Client: Exchange compositing information between the UI and Chromium

There’s also a wide range of service endpoints for managing high-level features like bookmarks, downloads, extensions, and autofill.

Rendering: Getting pixels across the process boundary

WebViews, which share a mutually exclusive presentation space in the client app are swapped in and out of a shared compositing container. For example, a browser window often has a single shared container visible and selecting a tab in the tab strip swaps that tab’s WebView into the container. On the Chromium side, this container corresponds to agfx::AcceleratedWidget which is ultimately backed by aCALayer. We expose that layer’s context ID to the client, where anNSView embeds it using the privateCALayerHost API.

Special cases like dropdowns or color pickers, which Chromium renders in separate popup widgets, use the same approach. They don’t have acontent::WebContents, but they do have acontent::RenderWidgetHostView with their owngfx::AcceleratedWidget, so the same delegated rendering model applies.

OWL internally keeps view geometry in sync with the Chromium side, so the GPU compositor can be updated accordingly…