OpenAI Built a New Browser Architecture Called OWL for ChatGPT Atlas

OpenAI has revealed OWL — OpenAI's Web Layer — the architecture that lets its new ChatGPT Atlas browser run Chromium's browser process entirely outside the main application process. Ken Rockot, Member of the Technical Staff, and Ben Goodger, Head of Engineering for ChatGPT Atlas, detailed the design in an engineering post published after Atlas launched last week.

The stakes are straightforward. OpenAI wants ChatGPT to travel with users across the web — asking questions, making suggestions, and completing tasks — and that goal broke the assumptions baked into a standard Chromium-based browser. OWL is OpenAI's answer to three product demands the company says stock Chromium could not meet: instant startup, responsiveness across hundreds of tabs, and a foundation for agentic use cases.

Why stock Chromium wasn't enough

Chromium was, in the engineers' words, a natural building block. It provides a state-of-the-art web engine, a robust security model, established performance credentials, and peerless web compatibility. It is a common go-to for modern desktop web browsers.

But OpenAI's design team had ambitions the stock user experience could not support. Features like Agent mode demanded rich animations and visual effects, which pushed engineering toward modern native frameworks — SwiftUI, AppKit, and Metal — rather than reskinning the open source Chromium UX. Atlas's UI is a comprehensive rebuild of the entire application experience.

Performance goals compounded the problem. The team wanted fast startup and support for hundreds of tabs without performance penalties. Chromium out-of-the-box is opinionated about many details, from the boot sequence and threading model to tab models. OpenAI considered substantial changes but wanted to keep its patch set against Chromium targeted so new Chromium versions could be integrated quickly.

There was also a cultural constraint. OpenAI ships on day one: every new engineer makes and merges a small change on the afternoon of their first day. That ritual collides with a codebase that can take hours to check out and build. OWL, the authors write, was the litmus test for whether the technical investment would accelerate development velocity rather than slow it.

What OWL actually is

OWL is OpenAI's integration of Chromium, and it runs Chromium's browser process outside the main Atlas app process. The authors frame it as an extension of Chromium's own founding idea: "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."

The shift delivers concrete benefits, according to the post:

• 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. If Chromium's main thread hangs, Atlas doesn't. If Chromium crashes, Atlas stays up.
• Fewer merge headaches. Because Atlas doesn't build on much of the Chromium open source UI, the diff against upstream Chromium is smaller and easier to maintain.
• Faster iteration. Most engineers never build Chromium locally. OWL ships internally as a prebuilt binary, so Atlas builds take minutes, not hours — which the authors note means even new team members can merge simple changes on their first afternoon.

The mechanics: client, host, and Mojo

At a high level, the Atlas browser is the OWL Client and the Chromium browser process is the OWL Host. They communicate over IPC using Mojo, Chromium's own message-passing system. OpenAI wrote custom Swift — and even TypeScript — bindings for Mojo so the Swift app can call host-side interfaces directly.

The OWL client library exposes a public Swift API that abstracts several key concepts from 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, including render, input, navigation, and zoom
• WebContentRenderer — forward input events into Chromium's rendering pipeline and receive renderer feedback
• LayerHost/Client — exchange compositing information between the UI and Chromium

A wider range of service endpoints manages high-level features like bookmarks, downloads, extensions, and autofill.

Getting pixels across the process boundary

The rendering model is where the architecture gets intricate. WebViews in the client app share a mutually exclusive presentation space and swap in and out of a shared compositing container. Selecting a tab in the tab strip swaps that tab's WebView into the visible container. On the Chromium side, the container corresponds to a gfx::AcceleratedWidget ultimately backed by a CALayer. The client exposes that layer's context ID, and an NSView embeds it using the private CALayerHost API.

Special cases — <select> dropdowns and color pickers, which Chromium renders in separate popup widgets — use the same delegated rendering approach. They lack a content::WebContents but have their own content::RenderWidgetHostView with its own gfx::AcceleratedWidget.

OWL internally keeps view geometry in sync with the Chromium side so the GPU compositor always produces layer contents of the correct size and device scale. The team also reuses this technique to selectively project elements of Chromium's native Views UI into Atlas, which the authors say is useful for bootstrapping features like permission prompts quickly without rebuilding them from scratch in SwiftUI. The technique borrows heavily from Chromium's existing infrastructure for installable web apps on macOS.

Input events, cracked and forwarded

Input required its own workaround. Chromium UI normally translates platform events — macOS NSEvents — into Blink's WebInputEvent model before forwarding them to renderers. Since OWL runs Chromium in a hidden process, the Swift client library does that translation itself and forwards already-translated events downstream.

From there, events follow the same lifecycle real input would follow, including being returned to the client when a page indicates it didn't handle the event. In that case, OWL re-synthesizes an NSEvent and gives the rest of the app a chance to handle the input.

Agent mode changes the rules

Atlas's agentic browsing feature — the flagship capability that motivated the whole architecture — poses unique challenges for rendering, input forwarding, and data storage.

OpenAI's computer use model expects a single image of the screen as input. But some UI elements, like <select> dropdowns, render outside the tab's bounds in separate windows. In agent mode, OWL composites those popups back into the main page image at the correct coordinates so the model sees the full context in one frame.

Agent input follows a strict security principle: agent-generated events route directly to the renderer, never through the privileged browser layer. That preserves the sandbox boundary even under automated control. The authors give a concrete example — they don't want this class of events synthesizing keyboard shortcuts that make the browser do things unrelated to the web content being shown.

Agent browsing can also run in an ephemeral, logged-out context. Rather than sharing the user's Incognito profile, which could leak state, OWL uses Chromium's StoragePartition infrastructure to spin up isolated, in-memory stores. Each agent session starts fresh, and when it ends, all cookies and site data are discarded. Multiple logged-out agent sessions can run simultaneously, each in its own browser tab and each fully isolated from the others.

Why it matters

The OWL disclosure is a rare look at how a major AI company rebuilds foundational desktop software around an agent-first product thesis. Every major browser vendor ships Chromium, but most embed it conventionally. OpenAI's decision to decouple the engine from the app — keeping the web platform while discarding Chromium's application shell — signals that AI-native browsers may demand architectures where the agent's constraints, not human UI conventions, drive the design. The isolation guarantees for agent sessions, in particular, show how browsing automation is being engineered with sandbox boundaries and state hygiene as first-class requirements.

The authors credit the global Chromium community for building the foundation, and frame OWL as a new way to build on it: "decoupling the engine from the app, blending a world-class web platform with modern native frameworks, and unlocking a faster, more flexible architecture." They close by pitching the work as an ongoing challenge, pointing to openings for Software Engineer, Atlas and Software Engineer, iOS roles in San Francisco. The subtext is clear: OpenAI treats the browser itself, not just the model inside it, as a long-term engineering bet.