Building the most efficient Agentic AI Browser

A six-browser engineering study of startup, memory, CPU, navigation, rendering, responsiveness, background tabs, and video performance

When we launched Cortex Discover, we described a dedicated enterprise agentic browser: a familiar browsing environment with native page awareness, selected-tab reasoning, controlled browser actions, visual context, file-aware workflows, and durable task continuity.

That product direction creates an important engineering obligation. An AI browser should not make people choose between intelligence and a responsive computer. It has to support research across tabs, long-running workflows, visual material, files, and enterprise applications while preserving the resources those applications need.

We therefore ran a structured performance campaign comparing Cortex Discover 1.1.0 with five widely used browsers: Google Chrome, Safari, Brave, Microsoft Edge, and Firefox. We measured each browser repeatedly on the same machine with the same deterministic workload. The study covered launch time, idle and active memory, CPU use, navigation, throughput, rendering, interaction latency, background-tab readiness, video playback, and recovery.

The result is not a claim that one browser wins every benchmark. Browsers make different tradeoffs, and some measurements are more portable across browser engines than others. It is a detailed engineering snapshot of where Discover is already strong and where we still have work to do.

The clearest result is resource efficiency. In this campaign, Discover ranked first of six in both the report’s memory-efficiency and CPU-efficiency categories. It used 10.9% less memory than Chrome in the active workload, 36.7% less with one idle tab, and 19.9% less with multiple idle tabs. It also launched 19.3% faster than Chrome in the warm-start scenario and completed the navigation phase in 17.6% less wall time. Rendering and fixture throughput remained effectively at parity.

Those savings did not erase every tradeoff. Discover’s handler-to-frame p95 was 10.5% slower than Chrome, and background-tab readiness p95 was 29.0% slower in the full campaign. Those are visible optimization targets, not numbers to hide. A separate, isolated A/B validation also showed that a focused optimization reduced background-tab readiness p95 by 18.9% and long-task time by 12.7% without a stable memory regression.

Why performance matters more in an agentic browser

A conventional browser primarily loads pages and runs web applications. Cortex Discover also provides an AI workspace beside those pages. It can work with the current page, reason across tabs a user explicitly selects, accept attachments, track task status, and preserve conversation continuity. Through Cortex Connect and the broader Cortex platform, a browser task can also participate in governed enterprise workflows rather than ending with a block of generated text.

That makes the browser a coordination layer. A typical session may include a dashboard, email, documentation, a video, several research tabs, and a side-panel task at the same time. Each part competes for memory, CPU time, and frame deadlines. If the browser consumes too much of the machine at rest, the user’s business applications have less room to work. If it creates sustained background work, fans spin and batteries drain. If it interrupts rendering, the product feels heavy even when a benchmark reports high throughput.

Our performance priorities therefore follow the shape of real knowledge work:

• Keep the idle footprint low when the browser is open but the user is thinking.
• Scale predictably as tabs accumulate.
• Preserve page and rendering throughput during active work.
• Avoid turning browser-integrated intelligence into continuous background load.
• Make startup, navigation, tab switching, and visual work feel immediate.
• Measure regressions openly and optimize them without trading away improvements elsewhere.

The six-browser campaign was designed around those priorities.

What we tested

The study ran on one macOS 26.6.1 x86-64 host with six physical CPU cores, 12 logical CPUs, and 16 GiB of memory. The compared products were:

• Cortex Discover 1.1.0
• Google Chrome for Testing 152.0.7951.0
• Safari 27
• Brave 154
• Microsoft Edge 154
• Firefox 157

Chrome 152 serves as the report’s fixed primary comparison baseline. The other browsers provide wider market context, although their engines, release lines, process models, and operating-system integration differ.

Each browser received one warm-up followed by five measured repetitions. All 36 runs completed successfully: six runs for each of six browsers, with zero failed runs. The workload used ten tabs, 600 operations, 20 scripted interactions, a three-second rendering phase, a 30-second soak, and a five-second synthetic video phase. In total, the harness captured 1,447 browser/phase/metric distributions, including 247 directly shared phase-and-metric keys.

We used a local deterministic fixture so every browser received the same content without internet variability, server changes, advertising, personalization, or third-party scripts changing between runs. Medians in the tables below are taken from the five successful measured repetitions. A percentage shown against Chrome is the raw difference between those medians; lower is better for time, CPU, and memory, while higher is better for throughput and frame rate.

The campaign is engineering evidence, not a universal promise for every website, device, policy configuration, or workload. It did not include BrowserBench suites. The video phase was synthetic and should not be read as a claim about every codec, streaming service, or conferencing application. Those boundaries are important because useful performance work starts with saying precisely what was measured.

The result at a glance

The primary comparison in this report is Discover 1.1.0 against the Chrome 152 baseline.

Three themes emerge.

First, Discover consistently left more memory available. Second, it converted that smaller footprint into equal fixture throughput and rendering rather than simply doing less work. Third, the remaining gap was concentrated in interaction-tail latency and background-tab readiness, which gives the team a specific optimization agenda.

Memory: Discover’s most consistent advantage

Memory was the broadest and clearest strength in the report. At one-tab idle, Discover used 2.4% of one CPU core. That was the lowest result in the group and 47.7% below Chrome’s 4.6%. Safari measured 3.7%, Brave 13.2%, Firefox 28.2%, and Edge 32.8%.

At multi-tab idle, Brave led at 1.6%, followed by Firefox at 1.9%, Discover at 3.1%, Chrome at 4.1%, Safari at 4.6%, and Edge at 8.2%. Discover was not first in that individual phase, but it still used 24.6% less CPU than the Chrome 152 baseline.

Our observed pattern across one tab, multiple tabs, active work, browsing, navigation, rendering, video, background operation, and recovery is consistent: Discover maintained a smaller captured footprint than Chrome in every reported memory scenario.

CPU: low at rest, competitive under load

Discover also ranked first in the report’s CPU-efficiency category, but the underlying results are more varied than the memory results and are worth reading scenario by scenario.

At one-tab idle, Discover used 2.4% of one CPU core. That was the lowest result in the group and 47.7% below Chrome’s 4.6%. Safari measured 3.7%, Brave 13.2%, Firefox 28.2%, and Edge 32.8%.

At multi-tab idle, Brave led at 1.6%, followed by Firefox at 1.9%, Discover at 3.1%, Chrome at 4.1%, Safari at 4.6%, and Edge at 8.2%. Discover was not first in that individual phase, but it still used 24.6% less CPU than the Chrome 152 baseline.

During the active workload, the results tightened. Brave measured 32.9%, Discover 34.0%, Chrome 34.8%, Edge 37.4%, Safari 41.3%, and Firefox 58.0%. Discover was second among the six and 2.2% below Chrome. Measured CPU time told the same story: 3.453 seconds for Discover and 3.541 seconds for Chrome, a 2.5% reduction.

Across the full CPU category, the median of Chrome-normalized scenario scores was 109 for Discover, 104 for Brave, and 100 for Chrome. The category result says Discover was efficient across the set; the raw values explain where that efficiency came from and prevent one composite score from obscuring outliers.

Startup and navigation: getting to work sooner

Discover produced the fastest measured launch result among the browsers for which the automated launch measurement was available.

Native launch to page-ready took 948.5 ms in Discover, compared with 1,076.4 ms in Brave, 1,188.2 ms in Chrome, 1,392.0 ms in Edge, and 2,566.4 ms in Firefox. Safari did not expose an equivalent result through this harness. Against the Chrome 152 baseline, Discover was 20.2% faster.

Observed performance distribution is normal: page shape, task scheduling, cache state, and observation boundaries affect individual milestones. The useful conclusion is narrower. Discover launched materially faster in this campaign and completed the aggregate navigation phase faster than Chrome, while page-level paint results remained mixed and continue to be measured.

Throughput and rendering: efficiency without reducing output

A resource-saving result is only valuable if the browser still completes the work. The throughput and rendering phases were designed to check that balance.

All six browsers clustered around 60 operations per second: Discover at 60.056, Chrome at 60.090, Safari at 60.126, Brave at 60.112, Edge at 60.091, and Firefox at 60.096. The difference between Discover and Chrome was one-tenth of one percent. In practical terms, the workload ran at parity.

For users, this matters: lower resource demand is much more compelling when scrolling, visual updates, and repeated operations remain smooth.

Video: lower memory, Chrome-level CPU, no dropped frames

Video was an explicit focus because early quick tests showed it as a potential regression area. The full repeated campaign tells a substantially better story.

During setup, Discover used 37.2% of one core versus Chrome’s 37.5%, a 0.9% reduction. Total setup CPU time was 1.981 seconds for Discover and 2.129 seconds for Chrome, a 6.9% reduction. Once the synthetic video reached steady state, Discover used 33.3% of one core versus Chrome’s 33.9%, and 1.695 seconds of sampled CPU time versus 1.754 seconds. Those are 2.0% and 3.4% reductions, respectively.

Reading the resource-efficiency quadrant

The report combines the memory and CPU scenario scores in a resource-efficiency quadrant. Chrome sits at the center as the 1.0× reference. Moving left means a lower memory ratio; moving down means a lower CPU ratio. Because both axes use a symmetric logarithmic scale, using half as much has the same visual distance from parity as using twice as much. The lower-left quadrant is therefore the desirable better on both region.

What the results mean for Cortex Discover

The performance profile aligns with the product model described in our launch announcement.

Discover is designed to keep assistance close to the work. The native side panel can use the current page, selected tabs, attachments, task state, and conversation history. Users can move through research, comparison, drafting, and controlled execution without continually copying context between a web page and a separate AI application.

That proximity is valuable only if the underlying browser remains a good host for the work. The measured memory advantage means Discover left more capacity for the pages and desktop applications around it. Lower idle CPU helps when a task pauses for review or user confirmation. Faster startup reduces friction when a user opens a dedicated work context. Chrome-level throughput and rendering show that the resource gains did not come from lowering the fixture’s output rate. Video results show that a common mixed-media workload can remain smooth without the large CPU gap seen in earlier diagnostics.

Performance also supports the product’s control model. Discover is built around bounded context and governed actions: the current page can refresh as navigation changes, cross-tab reasoning is limited to tabs the user selects, and consequential actions can require confirmation. Those boundaries are primarily safety and usability decisions, but disciplined scope has a resource benefit too. The browser can focus on the context relevant to the task instead of treating every open surface as permanently active.

The same principle applies across the Cortex platform. The Cortex AI Model Ensemble, Model Routing, Search Routing, Skill Routing, Cortex Connect, and Cortex Cloud are intended to match work with the appropriate capability and preserve continuity across surfaces. In Discover, that orchestration must coexist with ordinary browsing. Resource efficiency is what makes the AI layer feel native rather than bolted onto an already busy application.

What we are, and are not, claiming

Performance writing becomes unhelpful when a controlled result is stretched beyond its evidence. These are the boundaries we use when interpreting this campaign:

• The results describe one repeated campaign on one macOS Intel machine. Hardware, operating systems, enterprise policies, extensions, and sites can change the outcome.
• Chrome 152 is the fixed primary comparison baseline for this campaign. The wider six-browser comparison remains valuable, but cross-browser results include architectural and measurement differences.
• Process-summed resident memory can double-count shared pages. It is best used as a repeatable diagnostic signal, especially when comparing browsers with multiprocess architectures, and should be supplemented with native memory tools for release qualification.
• Safari process attribution and automated startup coverage are less directly comparable than the other browser measurements.
• Five repetitions support a useful median and variability check, but p95 values derived from five run-level observations are exploratory. They identify optimization targets; they are not population-level service guarantees.
• The 30-second soak produced volatile extrapolated memory slopes, including positive and negative values too large to support a credible leak-rate claim. We therefore do not use that phase to claim superior long-duration memory growth. Longer soak runs are the right follow-up.
• The synthetic video phase verifies this fixture, not every media stack. Production video qualification requires longer runs and a broader codec, resolution, and conferencing matrix.
• The campaign did not run BrowserBench suites and should not be presented as a replacement for Speedometer, MotionMark, JetStream, or application-specific performance testing.

Within those limits, the repeated medians support a clear conclusion: Discover’s strongest differentiator in this campaign was its resource profile, with faster measured startup and navigation, essentially equal workload and rendering output, Chrome-level synthetic-video CPU, and specific interaction-tail gaps that are already moving under isolated optimization.

A resource-efficient foundation for agentic work

Cortex Discover exists because enterprise work already happens in the browser. Research, communication, analysis, approvals, files, dashboards, and operational systems converge there. Bringing Cortex into that environment creates a more direct path from context to reasoning to controlled action.

The browser still has to earn its place on the desktop.

In this six-browser campaign, Discover did that most convincingly through efficiency. It ranked first in the report’s memory and CPU categories, landed in the better-on-both resource quadrant, recorded the lowest active-workload memory of the group, started faster than every browser with an available automated result, matched the field at roughly 60 operations and 60 frames per second, and played the synthetic video without dropping a frame.

The report also gave us a precise challenge: reduce interaction-tail and background-tab latency. We have already validated a focused improvement in that area without a stable resource regression, and we will keep measuring the whole system as the product evolves.

An agentic browser should help people do more without demanding more of their machine than the work itself requires. These results are an encouraging foundation—and a transparent baseline for the next release.

Our Cortex Discover Efficiency whitepaper provides more information, extensive performance metrics and detailed charts. Be sure to write to us to get the full access to the whitepaper.