Running AI agents in a headful browser: measured CPU and memory costs

Want to run browser agents on the computer you already own? In our test, ungoogled-chromium with uBlock Origin Lite used the least memory per extra isolated headful profile.

How many agents could that support? Our memory model projects 67 ungoogled-chromium agents or 55 Chrome agents on 32 GB, including a command-line allowance. These are capacity estimates, not demonstrated limits for agents completing tasks simultaneously.

Would those browsers receive the pages they need? We also tested launch settings against Google Search and investigated browsers consuming CPU while their tabs sat idle. All tests ran headful, with windows on hidden displays.

The results favour ungoogled-chromium with uBlock Origin Lite for our Linux agents, and Chrome with the same extension for people. The measurements below explain that choice and its limits.

1Why cheaper inference makes browser hardware matter

Cheaper inference gives you a reason to consider more agents. Each browser-based agent still needs a machine to open pages and perform its work.

Epoch AI estimates that the cost of achieving a fixed level of AI performance has fallen about 47% per quarter since 2023, or 13× per year. That tracks the cheapest available option at each performance level; users who rarely switch models capture less of the saving.

If you use those savings to run more browser agents, RAM and CPU become part of the expansion budget. Our test asks how far existing hardware can go.

2Why test existing hardware before buying more?

Test your existing machine to find out whether you need an upgrade. Our browser tests ran on i7-8700K and i7-9700 systems, giving you a measured starting point for trials on older hardware.

Running more browser agents means budgeting for the machines that perform their tasks. Memory and storage prices add pressure to that decision. On 2 February 2026, TrendForce forecast first-quarter conventional DRAM contract prices to rise 90–95% quarter on quarter. Its forecasts were 55–60% for NAND flash, 53–58% for enterprise SSDs and over 100% for PC DRAM. These were contract-price forecasts, not measured retail increases. TrendForce

Would renting more capacity cost less than upgrading? Check current prices before deciding. Hetzner’s documented adjustment took effect on 15 June 2026 at 08:00 CEST for new orders and cloud instance rescales. Certain changes to legacy-priced servers may move them to current pricing. Hetzner

Bytesized Hosting reports that CPX52 rose from EUR 36.49 to EUR 100.49 a month, while CCX23 rose from EUR 31.49 to EUR 85.99. These plan-specific examples cover Germany and Finland, excluding VAT and an IPv4 address. Bytesized Hosting

Start by measuring one agent performing your actual task, including its browser, runtime and supporting services. Our bench did not test local model inference or establish capacities for 8 GB and 16 GB machines. It did measure the browser memory added by each extra isolated profile, a starting point for estimating how many agents your RAM could support.

3How much RAM does one browser agent need?

Each additional isolated headful profile added 260–352 MB of browser memory in our agent-pattern test. Every profile had uBlock Origin Lite enabled and one page open.

One run per browser, scaling from one to ten isolated profiles on an i7-9700. Each profile had uBlock Origin Lite and one page.

The test ran ten isolated profiles per browser on an i7-9700 running Debian 13. Each profile displayed one page from a six-page set. Browser configurations ran separately.

We measured proportional set size, or PSS: private memory plus each process’s share of shared memory. The root sampler covered the whole browser process tree and agreed with a separate per-tree sampler within 1–2%.

ungoogled-chromium had the lowest marginal memory use. The projections below include a 130 MB allowance per agent command-line process; idle CPU figures came from one run per browser.

Chrome added 92 MB more per profile than ungoogled-chromium. Across 60 profiles, that difference would amount to about 5.5 GB.

These figures describe the browser workload. The 130 MB command-line allowance is a capacity-model assumption, not a universal runtime measurement. Budget separately for any additional application memory, local model, database and other services.

4How many Chrome instances can one server run?

Our memory model projects 55 Chrome agents on 32 GB and 119 on 64 GB. For ungoogled-chromium, the corresponding estimates are 67 and 146.

Memory projections include 130 MB per agent CLI and reserves of 6 GB or 8 GB. These are not demonstrated capacities for simultaneous task execution.

Each agent uses the same browser binary with a separate --user-data-dir. The test measures separate browser instances with isolated profiles, rather than multiple contexts inside one instance.

The model subtracts reserves and a fixed memory term before dividing by each agent’s cost:

agents = (RAM − reserve − intercept)
         / (marginal browser PSS + 130 MB agent CLI)

It reserves 6 GB on a 32 GB node and 8 GB on a 64 GB node. The intercept represents the fixed term. Each browser’s intercept is absent from the published report, so the displayed marginal costs alone cannot reproduce the exact counts.

Treat the counts as memory projections. The underlying comparison used ten profiles per build and did not establish active throughput at the projected capacity.

Two earlier results were withdrawn after a sampler missed browser processes: Brave at 219 MB per profile and a Chrome 60-profile cross-check at 216 MB. A corrected Chrome ladder was not measured. The process-accounting problem is explained below.

5Why is Chrome using CPU when tabs are idle?

Plain Chrome used roughly one full CPU core after our ten tabs loaded, even with the tabs untouched. Ad blocking reduced that work substantially.

Median idle CPU over a two-minute hold, with observed ranges and run counts. Here, 100% equals one full CPU core.

A separate workload: ten isolated one-page profiles, with one run per browser. Values range from 0.0058 to 0.0319 cores per profile.

The original plain-Chrome runs averaged 101% idle CPU during a two-minute hold. Chrome with uBlock Origin Lite averaged 12% in later runs before router blocking. Here, 100% means one full core.

Page loading needs a separate measure. CPU-seconds add up processor time across all browser processes and cores. Our window ran from the first tab opening until 60 seconds after the last tab loaded.

Plain Chrome recorded 322 CPU-seconds across about 135 seconds, equivalent to roughly 2.4 cores busy throughout. This is processor work, not load time. In a separate same-hour comparison, plain Chrome used 303 CPU-seconds and Chrome with uBlock Origin Lite used 66.

The isolated-profile test found another difference: Chrome used 0.032 idle cores per profile, against 0.006 for ungoogled-chromium. The report extrapolates about 1.9 versus 0.35 idle cores at 60 profiles.

Active agents need their own CPU measurement. Page loads, screenshots and simultaneous interactions were not measured at that scale. Even an idle test needs the network configuration recorded, as our DNS-blocking results showed.

6Does DNS ad blocking replace a browser ad blocker?

Our tested DNS-blocking configuration still needed uBlock Origin Lite because a CNN script repeatedly retried a blocked ad host.

Failed requests observed in the tested DNS-blocking configuration. This screenshot does not establish how other DNS blockers behave.

After the router began resolving selected ad and analytics hosts to 0.0.0.0, a video-ad script retried cdn-media.brightline.tv. The bench recorded 430,000–795,000 failed requests in about four minutes, roughly 2,000–3,300 per second.

Those retries kept about 2–2.6 CPU cores busy while the tabs sat idle. With uBlock Origin Lite, CNN recorded 22 failed requests in total. Brave’s Shields did not block that host in this configuration.

Adding uBlock Origin Lite reduced memory and idle CPU for Chrome and ungoogled-chromium under this DNS profile.

Each configuration ran alone three times, interleaved from 09:38 to 10:48 UTC on 7 October 2026. The router used an ER605 DNS proxy with uBlockDNS over DNS over HTTPS. These figures belong to that blocking profile, which was due to change after 11:00 UTC.

We did not repeat the test with Pi-hole or NextDNS. Measure idle CPU on your actual pages before relying on network blocking alone.

7Which browser uses the least RAM for everyday browsing?

Helium used the least RAM in our default ten-tab test, with much of its lead explained by its bundled ad blocker. Chrome with uBlock Origin Lite came close.

The ten-tab browsing workload differs from the isolated one-page profiles used for agent capacity estimates.

Chrome with uBlock Origin Lite on the same benchmark sites.

Memory sampled 60 seconds after the last load. Each result shows the median, observed range and run count; DNS conditions remain separate.

These single-profile tests are separate from the agent measurements. Each run opened the same ten sites five seconds apart, including BBC, CNN, YouTube, Amazon and Reddit. No Google traffic was included, and no consent banner was clicked.

Chrome with uBlock Origin Lite used 54% less memory and 78% less CPU than the same-hour plain-Chrome control.

With blockers disabled, six of the seven builds clustered between 2,569 and 2,706 MB. Chrome remained higher at 3,638 MB in the same-hour control. Comparing browsers at their defaults therefore mixes browser differences with ad-blocking differences.

Chrome had a larger main browser process and more renderers in the measured runs. The cause of the remaining gap is unverified. We did not isolate the contribution of individual Google services.

Our team recommendation is Chrome with uBlock Origin Lite. It retains Safe Browsing, sync, Widevine and Chrome’s update channel. Managed policy installs the extension, which also works when laptops leave the office router.

For agent nodes, the remaining per-profile difference deserves closer attention, alongside the features each build keeps.

8How do browser architectures affect the choice?

Architecture identifies features and rendering options, but our measurements establish the resource ranking. We did not measure which individual component caused each browser’s memory or CPU cost.

The following comparison covers the seven benchmarked browsers plus Firefox, Vivaldi, Zen and Lightpanda. Those four additional browsers have no memory or CPU result from our bench. “Not specified” means the supplied project evidence did not name a separate implementation.

Chromium uses Blink for rendering and V8 for JavaScript. Sharing that base does not establish identical resource use. Our agent test still measured 260 MB per extra ungoogled-chromium profile and 352 MB for Chrome.

Interface technology also needs careful interpretation. Chrome uses Views and WebUI, Vivaldi uses a React interface, and Firefox uses web technologies with some XUL. We did not measure the memory attributable to those interfaces.

Ad-blocking design is directly relevant to the tested configuration. Brave Shields is built into Chromium rather than relying on an extension manifest version. uBlock Origin Lite filters declaratively without a permanent filtering process. Our results show the total browser cost with the specified blockers, not the isolated cost of either blocker.

The graphical-rendering boundary matters for task selection. Lightpanda has no graphical rendering engine, so it cannot supply a painted desktop window. Its architecture makes it a different option from the headful browsers measured here; it does not give us a measured resource comparison.

9Which browser should AI agents run?

For our tested Linux agent workload, we recommend ungoogled-chromium with uBlock Origin Lite. It had the lowest marginal memory and idle CPU use.

Every profile in the agent-pattern comparison included uBlock Origin Lite.

The Flathub build worked with our clean-browser launcher, a reachable debugging port and the real GPU. Google served three of three paced searches in that configuration. An earlier tarball-build check served ten of ten quick searches.

The feature trade-offs need a decision. ungoogled-chromium removes Safe Browsing and Google sync, and our Widevine probe returned NotSupportedError. A Web Store helper restored an “Add to Chrome” button, but installation required a person to confirm the browser prompt.

Flathub provides automatic updates. The measured median Linux update lag of 2.5 days applies to the tarball channel across the last 15 releases. We did not measure a Flathub update schedule.

Chrome stable moved to version 155 on 6 October 2026. At the time of the bench, ungoogled-chromium had no version 155 build.

Brave is another option. It added 284 MB per profile, receives apt updates, and served ten of ten quick Google searches through clean-browser. Our agent configuration still includes uBlock Origin Lite because Shields missed the host involved in the DNS retry storm.

Choose Chrome with uBlock Origin Lite when its retained features justify the higher per-profile cost. Before applying any of these figures to a fleet, check that your memory measurement includes every browser process.

10How should you measure browser memory on Linux?

Measure the complete browser process tree, including processes that leave the original launch scope.

Directly sampled runs only. For plain Chrome, one run recorded 14,053.7 MB RSS and 3,866.6 MB PSS.

In this environment, all seven Chromium-based builds moved their main process into a separate systemd scope after starting. Later utility processes followed it. A sampler reading only the launch scope missed them.

With five Chrome profiles, the per-tree sum measured 2,002 MB while the launch scope alone showed 1,450 MB. In a ten-tab Chrome run, the moved main process held 653 MB.

Our replacement root sampler located the moved processes and included their descendants. It matched the per-tree measurement within 2%. Root access also addressed renderers hidden from a user-level reader by Brave’s setuid sandbox on Ubuntu.

The memory metric matters too. In a clean ten-tab Chrome run, summed resident set size, or RSS, was 14,054 MB. PSS was 3,867 MB, a 3.6× difference. Summing RSS counts shared memory repeatedly across processes.

That comparison does not establish an overcount for every Task Manager metric. It shows why the accounting method must accompany the number.

The first ten-tab repetitions required correction after the scope problem was found. Direct fourth-run totals were within 0–3% of the corrected earlier runs for ten of eleven configurations. ungoogled-chromium’s fourth run had a larger main process and a wider range.

Memory accounting tells you what fits. Page-access tests tell you whether the browser receives the content needed for the task.

11What did the Google launch test establish?

Launch settings changed whether Google returned results or its /sorry page in our headful tests. We measured access outcomes, not Google’s internal checks.

Recorded outcomes total 62 served searches, four /sorry responses and one unclear result. They do not reveal Google’s internal checks or guarantee future access.

A served result from the tested fixed-port configuration.

A recorded refusal after a Playwright-launch search. The outcome alone does not establish what Google detected.

On Chrome 154, a plain launch and a fixed debugging port both left navigator.webdriver false and received results. Playwright, Puppeteer and Patchright connections to the fixed-port browser also received results.

Pipe and port-zero launches set the property true and received /sorry. Adding --disable-blink-features=AutomationControlled made the property false, and those configurations received results.

Tests used fresh profiles on one home IP. After each block, a plain-browser control received results following a ten-minute wait. Helium and Brave showed the same plain-launch, pipe-launch and flag-change pattern.

These observations do not guarantee future access. All tests were headful, so they also do not establish whether the window itself affected the outcome.

Our clean-browser launcher starts the browser on a fixed port derived from the profile path. Agents connect using connectOverCDP, puppeteer.connect or agent-browser --cdp. A follow-up run served ten of ten searches each for Chrome, Helium and Brave.

12Can an older computer run these browser agents?

Our tests ran these browser configurations on i7-8700K and i7-9700 systems. They support a trial on existing hardware, rather than a universal minimum specification.

Browser-based research, page checks and screenshot-driven work are tasks to assess. Use your actual workflow. A single profile with ten tabs and ten separate one-page profiles are different workloads.

Measure the complete browser tree while one agent performs its work. Record peak memory, active CPU and idle CPU, then repeat with more concurrent profiles. Include the runtime and other services.

The 32 GB and 64 GB projections can guide that trial. Capacities for 8 GB and 16 GB machines remain untested, and the missing fixed memory terms prevent exact recalculation.

Locally hosted inference needs a separate assessment. No local model ran in these browser tests.

Can a headful browser run without a monitor?

A headful browser can open its window on a virtual Xvfb display without a physical monitor.

Our bench used hidden Xvfb displays and ANGLE/EGL flags to render through the Intel UHD 630. Cromite had WebGL disabled by default, and no browser returned a WebGPU adapter in this environment.

Display connections can limit scale before the projected memory capacity is reached. Each Chromium instance held about six X connections, and the bench reached the default 256-client ceiling at around 45 profiles. Starting Xvfb with -maxclients 2048 removed that ceiling for the bench.

Ubuntu setup also affected whether browsers started. Helium, ungoogled-chromium, Cromite and the tested xtradeb Chromium build initially failed with “No usable sandbox” on Ubuntu 24.04. Our installer added a userns AppArmor profile for each real binary.

13When should an agent use headful instead of headless?

Use headful when the task needs a desktop window, human takeover or the rendering environment you intend to test. Screenshots alone do not require it.

Modern Chrome headless can render pages and take screenshots. This benchmark measured headful configurations only.

Chrome’s modern headless mode shares the headful browser implementation and can render pages and take screenshots. Unified headless arrived in Chrome 112. From Chrome 132, the old implementation is available only as chrome-headless-shell. Chrome for Developers

Anthropic’s computer-use reference setup uses screenshots and a virtual X11 display through Xvfb. Playwright MCP reads the accessibility tree by default, with vision optional, although it runs headed by default. The agent’s input method and browser mode are separate choices. Anthropic documentation, Playwright MCP

Assess headless for unattended extraction or automated checks, and headful for desktop interaction or human intervention. Check GPU rendering in either mode.

Our bench measured headful browsers only. It cannot quantify headless memory savings or compare detection between modes. The separate headless vs headful browser article covers that decision.

Back to Top: Running AI agents in a headful browser: measured CPU and memory costs